Paul

If your post is gone, it's because I moved the marketplace discussion to http://www.blesta.com/forums/index.php?/topic/1046-the-markeplace-discussion-split/. Please take any discussion on the markeplace there and let's keep this thread focused on the knowledge base.

Thanks for the suggestion, CORE-763 has been added for forcing staff to use two-factor authentication.

CORE-494 for clients resetting cPanel password in the client area. Will take a look at client access to email log.

This is something that we would either simply implement, which would be similar to v2.5, or we would add a list of "on action" items that are configurable. I'm leaning toward the latter.

Does it show up in your phpinfo?

That's what I was worried about, glad you got it working!

We have no plans for Blesta to become a full fledged accounting system. Quickbooks can be used in conjunction with Blesta to handle the accounting, we use it internally ourselves. The shorter term question would be about getting some type of integration between the two. You should write an accounting plugin.

Does in include the ioncube loaders in it?

I just wanted to chime in on the module / marketplace discussion. I'll admit that I only read about 75% of the responses, as they were quite lengthy but I think I have a good understanding. If there's anything you want me to clarify, or think I overlooked, please let me know. 1. We want to support 3rd party developers as best as we can. We can't build everything for every niche. We are also aware that these developers have a financial incentive to build modules that we won't turn around and build ourselves. We can't guarantee this will never happen, but if there is any question, we encourage developers to ask us. We'll be as honest as possible about our future plans. Using ModulesGarden as an example, it's highly unlikely we'll develop an extended cPanel module anytime soon with the functionality they have built in because a) it already exists at a reasonable price, it fills the demand, and c) there are other areas of demand we can focus our efforts to move forward. Us building a cPanel extended module now would be a lateral move, and take away from much needed forward momentum. 2. We have partially built "The Marketplace", which is intended to be a marketplace of extensions for Blesta by 3rd party developers, and, at times, ourselves. When this is ready, 3rd party developers will be able to list their free and paid extensions in the marketplace. 3. There are 3 types of extensions we will develop. a) free and included in the core, free and available through the marketplace, and c) paid. We will never take our free modules, and start charging for them on an a-la-cart basis. If they start out included, they will stay that way. (Unless for example the company or panel we've integrated with disappears and we simply remove it altogether.) 4. An example of a paid extension that we will be releasing is the Licensing Module / Licensing Manager Plugin combo. This is the same system we use to license Blesta, and we will be releasing it as a paid extension. The reason this will be a paid extension is because it serves a smaller market segment. Not many people need it. There will be other paid extensions like this down the road that either serve a particular niche, segment, or enterprise, but we will not be moving to an everything a-la-cart system. We will also not be moving to a limited feature module, pay more for extended feature model to upsell people. I hope this helps clarify our position.

Ioncube may not be running via CLI. Can you SSH in and run.. php -i | grep IonCube .. and see if there is any output? If there isn't, maybe it's running off a different php.ini file. Alternatively you can run it with GET or wget. for example: GET -t 15m https://www.yourdomain.com/blesta/install/path/cron/?cron_key=CRONKEY where CRONKEY is your cron key as displayed under "Update Cron Key" (From http://docs.blesta.com/display/user/Installing+Blesta)

There are a few reasons.. Working over an API can be slow, it can take a long time for the hosting account (or whatever) to be provisioned. The user should not have to wait for this. The request could time out. If a module fails, for whatever reason, it shouldn't prevent the order from being placed. Orders can be approved automatically or manually approved. If an order is set for automatic approval, and the customer pays with PayPal or another non-merchant gateway, the service cannot be activated while the user is present, and it's not a good idea to do it when payment comes in from the gateway for the same reason as #1 above. If adding a primary service as an admin via the client profile, the service is provisioned immediately. The system for approving "pending" services via cron doesn't need to take into account any special circumstances, such as whether the order should be approved automatically, or manually, or whether payment has come in at the time of order or after order, or anything else. The system is autonomous. On average, with a 5 min cron, the user has to wait 2.5 minutes. Separately for trouble tickets, 5 minutes is a long time to wait (2.5 min on average) for an update to be reflected in the system. Where this matters, we recommend using ticket piping. There may be a case for 1 minute crons, but we feel a 5 minute cron lends more to stability. Blesta is very careful about not running the same task in duplicate, which is critical to prevent issues. A 1 minute cron may push up against this feature frequently, with mixed results. A change to the cron is something we may consider in the future, but the last thing we want to do is introduce any issues so it's an area we will tread lightly. Stability is more important.

The term "Default" is planned to be configurable, ie -- give it your own label other than Default.

Beta will be open to customers only. Configurable options are top priority for 3.1, and will be the biggest new feature.

We are aiming for 8-12 weeks (closer to 8 preferably) between minor releases, however since Blesta 3 is new there have been a lot of little things taking up our time out of the gates. So, 3.1 is likely to take a little longer than say 3.2 or 3.3, but we will make a beta version available as soon as we have something feature complete. We'll know more in terms of time frame in the next few weeks of when this will be.

The license module is used to generate licenses, and the license manager plugin serves as the license server. These will ship together. We have not yet made this available, but are planning to do so before long, and it will be a paid extension. Do you have a project you're looking to set up licensing for?

Overall what do you think of the module Mike?

There will be an official KB, and depending on when we do it it will either start out simple and receive a subsequent update to add more tight integration, or be released with tight integration to begin with.

Thanks for the offer, though we do have a cPanel server we can test it on. I'll see what we can do.

Hi Bob, This is corrected in 3.0.3 I believe, and a patch should be out next week. When a user registers, they will be directed to the client Dashboard.

Contact logins with ACL permissions is actually on our list, CORE-627 and is tentatively schedule for 3.2. We will considered sponsored development for core features, however we will only do those if we already agree that we want to include it. Same really goes for extensions too. We try to prioritize development based on demand, and in all honesty someone willing to part with some cash says a lot about how serious they are about throwing their support behind something. It's possible to have 100 votes for a feature that nobody will really even use but sounds cool. We would rather build the feature that 10 people would actually use than the one 100 people voted for but wont use.

Mike, just FYI the verify Blesta script is for v2 and will not be a completely accurate picture for compatibility with v3, though many of the requirements are the same.

I read that at 90% my normal speed, pretty amazing actually that we can do this -- unless you're a kid and reading still requires careful consideration.

I can see this working well in your case. If you don't need the automatic-ness of using a module, you could use the recurring invoice option in the interim. Price overrides would probably be better suited long term though.

If he puts up a PayPal donate button someplace, I'll chip in a few bucks.

I suggest trying to run the cron command via a shell if you have shell access. If there are any errors, like missing Ioncube loaders, they should be displayed. If that's not an option, you can alternatively use GET or wget. See http://docs.blesta.com/display/user/Installing+Blesta step 4 Cron. So, from this example, something like this may alternatively work for you.. GET -t 15m https://www.yourdomain.com/blesta/install/path/cron/?cron_key=CRONKEY