Leaderboard

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

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.

Make sure the uploads directory is writable, as defined under [settings] -> [system] -> [General] -> [basic]. It should contain the absolute path to that directory.

The remaining untranslated definitions are not included in English for language packs. Blesta automatically defaults to a English definition if your language pack is missing it, so It would be redundant to include untranslated definitions from the translator. And as Cody mentioned, translating the files manually can lead to other issues, like BOM. It also becomes very easy to create syntax errors, especially if you're not familiar with PHP and escaping characters, as well as sprintf-style variable replacement.

I'm not aware of a problem with service listings. Can you create a new thread about that issue? I'd like to keep this topic focused on the "customer-id" issue.

Firstly, I STRONGLY RECOMMEND AGAINST DOING THIS. Adjusting a cron task to run more frequently than once every 5 minutes can be dangerous as it increases the likelihood of a race condition, the results can be unpredictable. Find the ID for the "poll_tickets" key in the cron tasks table (SELECT `id` FROM `cron_tasks` WHERE `key`='poll_tickets') Take the ID from #1, and search for the entry in the cron_task_runs table (SELECT * FROM `cron_task_runs` WHERE `task_id`=TASK_ID) Change the cron_task_runs.interval from 5 to 1. Update line 1983 of /app/controllers/cron.php from: $last_run_date = date("c", floor($this->Date->toTime($last_run->start_date)/(60*5))*(60*5)); to: $last_run_date = date("c", floor($this->Date->toTime($last_run->start_date)/(60*min(5,$cron_task->interval)))*(60*min(5,$cron_task->interval))); Set your configured cron to run once every 1 minute, OR (more preferably) create a new cron task that runs every 1 minute at /usr/bin/php /path/to/blesta/index.php cron/pluginTasks/

For those of you who may be seeking a temporary work-around: In the file /plugins/order/views/templates/standard/main_configure.pdt On line 171 change <div class="heading options">to<div class="heading options" style="display:none;"> and on line 174 change <section class="pad content">to<section class="pad content" style="display:none;"> This will hide the portion of the checkout process in question from being displayed in the browser. It's not true solution but it works if you just want to temporarily hide the "Available Add-Ons" section from the configuration page of checkout.

This is a good question for Cody or Tyson, I'll ask them to take a look.

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.

Fair enough. Don't get me started! I'd be more likely to extend Blesta into an accounting system than integrate it with QuickBooks.

Thank you for all the feedback! We will check where is the problem. Your ticket will be answered very soon.

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

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.

I'm hoping they'll add this functionality soon. I've already abandoned WHMCS, didn't think about this until now. And now it's a problem.

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.

I agree. I get enough people calling me to order on the phone let alone figuring that out online. It needs to be as easy and intuitive as possible.

Hopefully they'll see this. It's seems overly cumbersome to have to make multiple orders for an add-on item.

That's what I was afraid of. Many of the clients I cater to don't know that much and wouldn't know to order a domain first. It should be a conditional question in the hosting order form.