jwogrady

More great news! Looking forward to 3.6 for sure!

Yes, I understand usernames are unique. My immediate concern is usability. Login asks for Username not email address.... Ideally the actual userid would be an random unique integer. Username, phone numbers, email addresses, twitter, google, and facebook would be the unique identifiers that can be linked to the userid that the customer may never even see. Now the user can sign in with either an email address or username with their account password.... Or via facebook, google, or twitter via Third Party Authentication. TPA increases sales because it streamlines account creation and prevents users from having to remember yet another password. It's also inherently more secure. (no everyone agrees on that last point though)

This is really great news!

My original thinking was somewhat flawed. Here is perhaps a more elegant approach. First, Payments methods are unique to users.... not companies... Right now they are managed at the account level which is not PCI best practice. Changing this set the stage for making a more flexible billing system. Now we can accurately model the real world relationships. --- users belong to one or more company accounts --- users signup for products and services for one or more companies. --- user have varying roles in companies. --- Depending on their role, users can manage their service configuration and payment accounts at the universal, company, and service levels. This elegantly solves my scenarios. Senario 1 --------- IT manager pays for hosting, ssl. Marketing manager pays for PPC marketing services Scenario 2 ----------- dallas.website.com - dallas franchise owner la.webstie.com - la franchise owner ny.webstie.com -- ny franchise owner Scenario 3 ------------ - Company admin can see all company manager activity within their account. - Company managers only see the services and billing activity on the services they provision and/or assigned to manage. - Company admin can add and resign services to company managers as they enter and exit the company thereby improving service continuity. - Company admin can disable manager payment accounts altogether. They are then responsible for paying for all services as they become due.

I get a lot of calls from clients asking me for their username because they forget the username is their email address. Compounding the issue....' - Login prompt on askes for "Username" - There is no username recovery feature. My suggestion is that every user have a unique username, and that thier username can be referenced by one or more email addresses and even phone number. This way the prompt can ready "Username or Email Address". You can recover the email by providing a email address and phone number. Even better..... Google, Facebook, and Twitter authentication options.

cPanel now supports 16 character usernames, but trying to add an existing account with more than 8 characters results in Blesta error. The username must be between 1 and 8 characters in length. Per Cpanel, https://documentation.cpanel.net/display/ALD/Create+a+New+Account Proposed fix: Extend the field to accept up to 16 characters, but validate the first 8 are unique. In the meantime, is there a hotfix so I can override the 16 character limit? I need to start billing those accounts.

I reached a settlement agreement with a customer where he agreed to pay part of the outstanding invoices if I credited the reset. Why is Blesta counting in store credit as revenue?

Here are some ideas to improve the ticketing system in future releases... SPAM Handeling We like to run an open system. As a result we get a lot of spam. These features would help Add senders to blacklist. Easy delete spam. (prefer to move them to spam/junk disposition, with auto deletion after X days) Opening Tickets For Customer We tend to open a lot of tickets for our customers. Forward Emails - I get a lot of direct requests, I want to be able to forward emails customers send me to support@ and the system generate the ticket and confirm the same. The ticket owner should be the originator. The assigned agent should be the forwarder. Registered agent should be able to send an email to support with the customer CC'd. The CC is made the owner of the ticket and gets a confirmation message with instructions for tracking the ticket. Something like, "Joe at Status26 opened a ticket on your behalf. You can track progress and add comments using this link. If an address isn't recognize, the agent should be able to append an email address to an existing account, or create a new one. Support Operations Change Ticket Ownership - Registered Agents should be able to change the ownership of tickets. The use case is opening a ticket for the wrong person, and needing to make a change without loosing the thread. Loop In Staff / Ticket Agents - Need to be able to cc Staff / Agents so they are aware a ticket is open. Would be nice if they can contribute to the comments thread. Agents Should be able to change Assignment - If during the course of the ticket the person assigned is no longer the best person to manage the ticket. In that case, Agents should be able to transfer assignment and know the appropriate notifications will be sent. CRM Features Would be helpful to assign Account Managers to accounts so they get notified of all activity on their accounts, and be able to contribute to tickets submitted by their customers. Account Owners should also be able to open tickets for their customers similar to Ticket Agents.

Writing credentials to the database doesn't mean the credentials worked. Would be nice to have a test script that sends and confirms SMTP authentication.

Yep, that was it. Thanks so much.

This of course helped a lot.... http://www.blesta.com/forums/index.php?/topic/1945-how-to-move-blesta-installation-to-another-server/ But assuming the versions are the same as the target, can't you simply copy over the blesta.php key code?

I installed a clean copy of Blesta and moved over the database. Everything seems to be running, but none of my passwords work on the new system. Do I need to copy over a password hash or something?

My maintenance view page isn't showing... Files does not exist: /home/{user}/public_html/portal/app/views/client/status26/client_maintenance.pdt on line 120 in /home/{user}/public_html/portal/lib/view.php #0 /path/to/home/user/public_html/portal/lib/controller.php(277): View->fetch('client_maintena...', NULL) #1 /path/to/home/user/public_html/portal/lib/dispatcher.php(128): Controller->render() #2 /path/to/home/user/public_html/portal/index.php(21): Dispatcher::dispatch('/portal/client/...') #3 {main}

If source was maintained on Bitbucket or Github you would get a lot of valuable feedback from the community. I'm sure there are issues related to your development stack that makes this easier said than done; especially if you are using private development source files to generate the production source files we see. That all said, the more people contributing feedback and developing add-ons the better. I would like to see Blesta optimize around that goal over anything else.

I assume you mean this.... http://www.blesta.com/forums/index.php?/topic/1078-vqmod-for-blesta-now-available/ Not crazy about adding what appears to be a third party module to do the updates; especially when git is so widely used. I've also notice this has never worked....

It would really make updates a lot easier if you guys made the current release available via either Bitbucket or Github. This way users will simply need to to do a git update to upgrade to the latest version, and I could easily see the change history in my local code.... and roll back if I need too. Right now I - make sure everything is pushed to my private report. - copy over the update files. - test the application - update my private source. that's easy enough I guess, but it would be even easier if I can fork off an repository.... Then i simply pull down changes to the production server instead of having to copy files over... The other benefit is the community could make pull requests.... :-)

The option I decided to pursue is to create a wrapper site around Blesta using Python and Flask. If there is any interest out there on this approach please get in touch. Would love to collaborate.

Paul's solution provides enough of the workaround to solve the most pressing need. My actual needs are actually much greater. Here are my actual use cases with business justification. Scenario #1 Acme Inc. has two subsidiary companies (Alpha Co. and Beta Co.) who need to be billed separately. Each subsidiary company wants to pay for "IT Services" (i.e. hosting) by credit card to reduce the chance of service interruption.... They want to pay marketing service by check. The Ideal Scenario one account for Acme Inc. sub accounts for Alpha Co. and Beta Co. Inside the sub-accounts there are two buckets.... Marketing and IT Services Marketing Services Bucket Paid monthly by check... We can add or delete SEO, PPC, etc. service bundles throughout the month. The bucket figures it out and submits the consolidated invoice. IT Services Bucket Paid by card - We can add hosting accounts, vps servers, etc. throughout the month and the invoice shows all the credits and debits to that bucket. Keep in mind the each sub-account has it's own billing contact, checking and credit card. Scenario #2 Primco Inc. is a nationwide company with 30 locations. Each location has a point of contact for IT Services. Primeco Inc. pays the bill, but they need to itemize for each location. Ideal Scenario. sub-account for each location. bucket for IT services within sub account. Roll up bill for Primeco Inc. to pay. When Primco Inc. Pays the bill each of the sub accounts is credited. Business Justification I understand these are true enterprise billing scenarios. However, these billing practices are rather common for marketing agencies who do a lot of ad hoc work in addition to subscription services (i.e. retainer services) for both national and local level accounts. If Blesta were to position themselves as an agency billing system I think they fill a gap marketing companies desperately need. All of them have reseller accounts, but they can't really use Blesta because it's not a total solution for them. If you can position yourself as an agency platform for technology and marketing services you expand the market by filling a gap. Ultimately I think the host billing market is mature. Agency billing is a progressive step and ultimately a larger market with few competitors. PM me if this is something you want to consider further. I'm happy to help.

@Licensecart, ModulesBakery is a good lead. A google searched also turned up these guys who are trying to build a WP bridge.... http://www.alltoolkits.com/toolprofile/wordpress-blesta-bridge I'm really trying to get off WP and the cPanel/php stack. Developing WP plugins for WP seems to me to be a step in the wrong direction... but may indeed be faster. Do you see any substantial differences or advantages to #3? I'm looking for you Python/Django, Python/Flask, Ruby on Rails, or perhaps even you Meteor guys that figured out how to coexist in php/whm/cpanel world.

I'm exploring my options for integrating Blesta into a website. Here are the options I've considered. OPTION #1* WordPress Integration - A wordpress standalone site acts as a gateway to the Blesta Portal. What's needed to do it right? - Ability to pull product categories, products, and payment links out of Blesta. - Ability to share WordPress and account data for Single Sign-on and account management. Possible Approaches: - Create a Single Sign On Bridge - Create Wordpress Catalog Module * I assume this would work for any "off the shelf" CMS package. OPTION #2 Create a fully featured CMS Plugin for Blesta What's needed to do it right? - ability to build a navigation and page structure within Blesta. - perhaps a separate module for a blog OPTION #3 Create a custom Blesta Wrapper site. - assumes blesta is used for user management and permission roles. - assumes blesta is the product database What's needed to do it right? - need a non-customer user role. (I'm sure this already exists) - perhaps use OAuth account creation and authentication so folks can create an account and sign in with Twitter. I'm not sure #3 is substantially different from option #1. These are the options I'm exploring. Would love to hear feedback on what's out there already and strategies that are working for you.

Okay, I understand the issue much better now. Still working on a solution... but at least I understand the use case we are talking about which is Blesta as standalone site. I think my larger question is how to integrate Blesta into the rest of the site. I'll post that as separate topic.

@paul, I agree with your immediate solution. That would solve at least 90% of the problem.

@Tyson, thanks so much. I'm working on invoices today or tomorrow. Promise to report back my findings.

Thanks for the replies, but I'm still not exactly clear on this issue. The suggestion of using subdomains is indeed clean but, I don't understand why domain name routing is insufficient. Will this work? https://example.com/portal https://test.com/portal From a marketing perspective, the only real option is to 301 everything to www or non-www.

With multi-company support, I'm trying to understand with multi-site why I can't do this.... https://storeone/portal/..... https://storetwo/portal/..... I've read this http://www.blesta.com/forums/index.php?/topic/3969-multi-company-questions/?p=29175 and this... http://docs.blesta.com/display/user/Creating+Companies We suggest when using multi-company, you use subdomains for your Blesta installation, otherwise it will not be possible to have different website content at each hostname. That statement, if true, may be a multi-site deal killer.. The reason is I need my product discussion to be on the main domain to support long-tail SEO. Having the catalog on a subdomain really hurts SEO indexing. I guess I could use www. but man I hate www. John