Tyson

Yes, you should set the timezones after you load the Date helper. It will not set the timezones itself because it is not aware of the timezone of the dates you are working with or what you want to convert them to. You could set the timezones on load (via the constructor), or via ::setTimezones. Loader::loadHelpers($this, ['Date' => [null, 'Africa/Casablanca', 'UTC']]); or Loader::loadHelpers($this, ['Date']); $this->Date->setTimezones('Africa/Casablanca', 'UTC'); Then, you can convert dates: $this->Date->format('2019-05-01', 'Y-m-d H:i:s'); It's also useful to include timezone information in the date if it differs from the set timezones: // Specify the date provided is in UTC $this->Date->format('2019-05-01 00:00:00Z', 'Y-m-d H:i:s'); // Specify the date with the full timezone information for the current timestamp $this->Date->format(date('c'), 'Y-m-d H:i:s'); Does setting the timezones fix the date issues you were having?

Where are you doing the date formatting at in your plugin? In a controller, a model, or somewhere else where you loaded the Date helper? The Date helper maintains two timezones. The "from" timezone and the "to" timezone. When formatting a date, it will cast the date from the "from" timezone to the "to" timezone. you can set this with Date::setTimezones(from, to) AppController loads the Date helper and sets the "from" timezone to UTC and the "to" timezone to the company timezone since it typically casts dates to the company timezone from UTC. (i.e. formatting a date will change the date from UTC to the company timezone when any child classes use the inherited $this->Date) AppModel loads the Date helper but does not set the timezones. (i.e. formatting a date will change the date based on whatever the given date timezone is set to, or otherwise fall back to what the server timezone is set to) AppModel::dateToUtc will convert a date from the company timezone to UTC. If you use the Date helper to format dates in a model that inherits from AppModel, you should set the "from" and "to" timezones accordingly.

Only package options with a matching term to the package can be set. So if you have a 3 month term package, only package options that are 3 month terms can be ordered with it. I'm not aware of ordering multiple domains for a single WP package, I think that has more to do with parking domains on a web hosting account. The package's welcome email contains the "service" object, and the package options are available in a list of "service.options". You would have to loop over the "service.options" and then evaluate the specific option to display the option name and value (e.g. "Admin Password: abc123"). For example: {% for option in service.options %} {% if option.option_name == 'admin_name'}{option.option_label}: {option.value}{% endif %} {% if option.option_name == 'admin_pass'}{option.option_label}: {option.value}{% endif %} {% endfor %} The above would look over all service options, and display admin name and password if those are options on the service: Admin Name: myname Admin Password: mypassword

I just tested that myself using the UTC timezone, and my system generates the dates as expected: 2019-05-01 2019-05-01 00:00:00 2019-05-01 2019-05-01 00:00:00 2019-05-18 2019-05-18 00:00:00 2019-05-18 2019-05-18 00:00:00 Under Settings > Company > General > Localization, is your company set to the timezone "(UTC +00:00) UTC", the option at the very bottom? Your dates appear to behave as if your timezone crosses over daylight savings sometime between May 1 and May 18, which might be the case if you use a different timezone that varies between UTC +0 and UTC +1. What do you get when you load the Date helper and format the time yourself? Loader::loadHelpers($this, ['Date']); $dates = ['2019-05-01', '2019-05-18']; foreach ($dates as $date) { $this->Date->setTimezone(Configure::get('Blesta.company_timezone'), 'UTC'); echo $date . ' to UTC: ' . $this->Date->format('Y-m-d H:i:s', $date) . "\n"; }

CORE-3156

Thanks for finding that. This is CORE-3155. The fonts will be moved to /fonts/bootstrap/

Not currently. The pay link is only generated when the invoice is being sent by email.

In your screenshot for the package option "Script", I notice that the "Name" is capitalized as "Script" rather than "script" as mentioned in the documentation. I believe that is case-sensitive, so it may be why WP does not get installed. I would update that and retest first. The package has 1 and 3 month terms, but the package options are only setup for 1 month, so it would only be installed if the 1 month package was ordered, not the 3 month package.

Search by the `invoices`.`id` field? It should already search by the friendly invoice ID shown in the interface.

I suggest re-uploading the Blesta files to your web server. It seems like you are missing some files (e.g. a JavaScript file and perhaps CSS). Be sure to keep a backup of your /config/blesta.php configuration file.

Under Settings > Company > Client Options > Required Client Fields you can specify which of the optional fields to require. Phone is not available since there could be multiple phone numbers of different types.

I'm not sure if you took a look at JavaScript errors in your web browser as I mentioned above, but it sounds like there is a JavaScript error one some pages that is causing the page to break and actions not to work correctly.

Blesta enforces permissions for user access to pages, but not access to specific actions/data that may be displayed on those pages, which sounds like your requirement. If you wanted to restrict access to certain staff groups, you could update the system to determine the current user's staff group, check whether they are in the list of groups that are allowed access, and hide/show those fields based on that.

That can occur if there are errors trying to fetch those options from the module (i.e. NOC-PS). There could be something misconfigured, or Blesta may not be able to connect to the NOC-PS API. Check your module logs under Tools > Logs > Module tab and see if there are any logs stored for NOC-PS. Click the table row to expand the section to see the raw input/output communication Blesta does with the NOC-PS API. There may be an error mentioned that could lead you to the problem. After looking at your screenshot, I see that the Text/HTML description is not loading properly, so there must be JavaScript errors on the page. That could also be causing your module options to not be retrieved. You should check your web browser's developer panel to see what JavaScript error was encountered.

Hosting services need to know what domain the hosting plan is for, so the domain is a prerequisite and is determined first. The Domain and Other order form flows: Enter domain to purchase/transfer Configure domain Choose hosting plan Configure hosting plan Complete purchase This flow requires a hosting service to be partially configured, then a domain service to be completely configured, followed by a return to the original hosting service to complete its configuration. However, this flow would not work with Blesta since it requires the completion of one service configuration at a time. The customer does not need to go back to order a domain with the current order flow because they start with the domain and move on to the hosting plan from there.

You should be using the "Domain and Other" order form for domain+hosting purchases. The customer can choose to purchase/transfer a domain and then order the hosting for it.

That's correct.

Yes. You can change the package price to what it should be for new customers and customers that should renew at that new price. For existing customers that should have a separate price, you can update the service and set an Override Price which will override the package price on renewal.

Our builds don't produce an unminified version at this time, so I don't have a copy of one for v4.1. You could try running it through a beautifier though.

You could change the JS if you'd like, but it's minified to reduce file size. We also don't include a "blesta-version.min.js" anymore, it's app.min.js.

In any order form, when you Empty Cart, the product is removed from the cart and the customer is redirected back to the main order page (i.e. /order/main/). If nothing happens for you, then I'm curious whether there are errors generated on the page that results in no request being performed. Do you have any custom code integrated into the system? It would be useful to have additional information as described in How to Report a Bug so that we can understand your environment configuration and how to reproduce the issue you're having ourselves. Currently, my order system functions as I would expect when emptying the cart.

This is CORE-3112.

I agree that we should be looking at calendar day. I think we can achieve your result by keeping the setting "Suspend Services Days After Due" at "1 Day". Here's what I would propose: Update the Suspend Services cron to evaluate all services that were due at any time of day yesterday This would mean that if today is 11-4-2019 00:00:00 and the cron is now running the Suspend Services task, it will see that an invoice was past due at 10-4-2019 23:00:00 (an hour ago) and suspend it now instead of waiting until tomorrow (25 hours after due).

Created as CORE-3111.

I just tested this myself and it looks like a bug. We'll have to fix it for v4.6. In the meantime, you could comment out a few lines of code in one of the files to work around the issue: In /app/controllers/client_pay.php, toward the top, find: if (!empty($payment) && isset($payment['client_id']) && $payment['client_id'] != $blesta_client_id) { $this->Session->clear('payment'); $payment = null; } add 2 slashes at the beginning of each line, i.e.: //if (!empty($payment) && isset($payment['client_id']) && $payment['client_id'] != $blesta_client_id) { // $this->Session->clear('payment'); // $payment = null; //} Save that, and customers should get to the confirm page now.