Tyson

That sounds good. I think the system tasks should appear under the system automation settings.

This is fixed in CORE-2553 for v4.2.0-b2.

This is not a behavior I encounter with the WYSIWYG editor. However, I recall you had mentioned updating the editor in the past (e.g. as mentioned here) and I wonder if those updates led to this issue. You might want to try removing your changes temporarily and retesting this behavior in Blesta to see if you still encounter it with the default Blesta WYSIWYG.

I haven't been able to duplicate this issue either using: A fresh install of v4.1.2 cPanel module v2.5.0 Two cPanel servers setup One that has reached its account limit One that has not yet reached its account limit Both assigned to a single server group "A" The server group set to an Add Order of "First Non-Full server" "Force Server Limits" checked A package that uses the cPanel module Package module options set to use the cPanel server group "A" (i.e. not a specific cPanel server) "Standard" Account Type Creating a new service set to "Provision using the cPanel module" always creates the service on the server that has not reached its account limit. Questions: Are you creating the service via the API, via cron, or via the client UI as opposed to the admin UI I tested with? Have you checked the module rows (servers) to ensure they contain module row meta information for the account limit and account total? This is what's shown on the table in cPanel server listing under the "Accounts" column, e.g. "150/250" Values would be stored in the `module_row_meta` table where there should be a `key` for "account_limit" and "account_count" each with an integer `value` for a particular `module_row_id` from the server group.

No, I don't think those tasks will make it into v4.2.0 due to time constraints and task priority. We'll see what we can do at getting them into v4.3.0.

I don't think the timezone should have an effect on this issue since the time comparison is relative to UTC. This type of issue usually arises because the server time is no longer synced with the current actual time. For example, if the time is currently 08:00 but your server time is 07:55, the server time is 5 minutes slow, so while clients will generate a OTP based on 08:00, it will be compared against a different OTP from 07:55 by the server. This time drift will cause the OTP to be rejected if it is more than +/- 3 minutes from current time.

If you're sure the API user and key are correct, it may be that your web server is run in CGI and certain variables for HTTP authentication are not available, like PHP_AUTH_USER/PHP_AUTH_PW, HTTP_AUTHORIZATION, or REDIRECT_HTTP_AUTHORIZATION. In that case you will likely need to update your .htaccess file to include a rewrite rule to set HTTP_AUTHORIZATION. Take a look at this post for an example.

The browser's default option is the first item in the list, which for an alphabetical list of states in the US is Alabama. You can override it by specifying a state in the AdminClients controller: Open /app/controllers/admin_clients.php Find: $vars->language = $company_settings['language']; Add beneath that line: $vars->state = 'MO';

Queued service changes won't cancel themselves if left unpaid. I think manual action would be required to cancel the upgrade if the customer decides he does not want to have it after all.

There is no way to have a state pre-selected without updating the source code to add in that option yourself. But to save yourself from some scrolling, you could select the field (or hit TAB until you get to it) and then begin typing on your keyboard to change the selected value, (e.g. begin typing out "Missouri").

Is your server time accurate? If it's off by even a couple minutes the one time password will not be accepted.

Is the API user set to connect to the right company? It sounds like the API user or key cannot be found in the system.

You would have to update the Billing Overview plugin source code in order to set those dates. If you change them, they will be overridden when you upgrade Blesta so you will need to remember to re-add your changes back in afterward. Open /plugins/billing_overview/controllers/admin_main.php Look for the following toward the top of the file: $dates = [ 'today_start' => $this->Date->cast($datetime, 'Y-m-d 00:00:00'), 'today_end' => $this->Date->cast($datetime, 'Y-m-d 23:59:59'), 'month_start' => $this->Date->cast($datetime, 'Y-m-01 00:00:00'), 'month_end' => $this->Date->cast($datetime, 'Y-m-t 23:59:59'), 'year_start' => $this->Date->cast($datetime, 'Y-01-01 00:00:00'), 'year_end' => $this->Date->cast($datetime, 'Y-12-31 23:59:59') ]; Replace that with: $month = $this->Date->format('n'); $new_fiscal_year = ($month >= 4); $datetime_last_year = $this->Date->format('c', date('c', strtotime('now -1 year'))); $datetime_next_year = $this->Date->format('c', date('c', strtotime('now +1 year'))); $dates = [ 'today_start' => $this->Date->cast($datetime, 'Y-m-d 00:00:00'), 'today_end' => $this->Date->cast($datetime, 'Y-m-d 23:59:59'), 'month_start' => $this->Date->cast($datetime, 'Y-m-01 00:00:00'), 'month_end' => $this->Date->cast($datetime, 'Y-m-t 23:59:59'), 'year_start' => $this->Date->cast(($new_fiscal_year ? $datetime : $datetime_last_year), 'Y-04-01 00:00:00'), 'year_end' => $this->Date->cast(($new_fiscal_year ? $datetime_next_year : $datetime), 'Y-03-31 23:59:59') ]; Save

The custom report system allows you to select any data system-wide, so you can retrieve data for other companies as well if you see fit. Any tags, like one for :company_id, would have to be implemented yourself in the custom report. Even if a :company_id tag were available by default, your custom query would still need to define the appropriate joins in order to filter on it. Because of this, it is still best to define your query and all filters, including company_id, yourself. This also avoids unnecessary coupling between custom reports and current user session information of someone exporting the report. Note as well that reports can be generated via cron, and in the future there will likely be the addition for custom reports to do generated via cron, and in that case there would be no session information available to the report during creation.

Configure::set('Blesta.csrf_bypass', array('client_login::index', 'client_login::reset', 'signup::index'));

I see you include custom CSS at the bottom of your HTML. That CSS uses open/close braces (i.e. "{" and "}"), which are reserved characters used for tag replacement by the template parser, so your CSS rules are conflicting with it. See my post here for a work around.

I think that's just the style of those radio/checkbox options in the new Firefox theme. I suspect they are difficult to see on every website you visit. There's not much we can do about that besides adding an image to represent the radio/checkbox options, but I think either Firefox will update their default radio/checkboxes because they are too light or people will end up getting used to this change soon.

There is no stored value for the date Blesta was installed, but the closest approximation would be the date the first staff user account was created, yes.

Very nice! Just FYI on the HTML-in-JavaScript where you mention adding plus-signs--the plus-sign is the JavaScript concatenation operator which appends the string before it with the string after it. You could just have one large string (contained in single-quotes or double-quotes) without any concatenation, but I think the original template is written that way for readability. I'm sure those familiar with JavaScript will already recognize that.

That language is now available on the translator.

I would recommend taking a look at their documentation. All of the CKEditor source code is available in /vendors/ckeditor/ of your Blesta installation. Most of the configuration is set in the *.js files in that directory.

The BCC notices you configured for the staff group makes them available to any staff in that group, but each staff user still must set whether they want to receive BCC notices from their [My Info] > [Notices] page by subscribing to them.

You need to update your configuration file to set specific controller methods that should bypass the CSRF check. You can update /config/blesta.php, then find and update Configure::set('Blesta.csrf_bypass', array()); to: Configure::set('Blesta.csrf_bypass', array('client_login::index', 'client_login::reset')); That will disable the CSRF check on the client login and client reset password pages. The ISO-3166 for Bangladesh includes multiple districts and divisions, and some of the divisions have the same name as the district, hence why "Chittagong" appears duplicate--one refers to the division and the other refers to the district. If you need to update the States in Blesta to better represent provinces in your area more specifically than the ISO-3166 can represent, you can try the States&Countries plugin to update them.

The services added are useful for keeping track of what is being added to the system, either from orders or otherwise. I agree it would be useful to also know of services that were activated today, but there is currently no criterion available to make that determination.

The Billing Overview stat of "Services Added Today" represents the total number of service records that were created today based on the service's add date. That does not necessarily mean that the service was activated today or even that it's active at all. It sounds like you are expecting it to mean Services Activated Today, but there is no criteria available for it to determine the date the service was made active.