Tyson

Since there's not a way to remove the name server fields just for clients from the interface, you will need to update some code to accomplish this change.
 
Here's what will likely work:
Find /components/modules/namecheap/namecheap.php from your Blesta installation. BACKUP this file somewhere Open that file in a text editor and search for:
$fields = array_merge(Configure::get("Namecheap.nameserver_fields"), Configure::get("Namecheap.domain_fields")); Replace that line with:
$fields = array_merge(Configure::get("Namecheap.domain_fields")); Save the change and overwrite the file at /components/modules/namecheap/namecheap.php
 
Now when a client goes to order a domain, they should not have any option to set name servers. However, you can still set them yourself when managing the service from the admin interface, or updating them on the package. The name servers you have set on the package will be used for services by default.

It sounds like the hierarchy you would want is a package group of package groups. However, packages groups cannot nest each other in Blesta. You could only have one level of nesting, which is the package group and the packages inside that group.
With that said, you can accomplish the behavior from your example (i.e. 1 level of nesting) using the way some templates display package groups on the order form.
For example:
Create an order form Choose the template "Wizard Boxes". You could also use "Wizard Slider", or the respective AJAX equivalents. Assign 3 package groups to the order form: "Beginner" "Intermediate" "Advanced" Each of those package groups should have multiple packages assigned to them, respectively, so the customer can choose the package they want to order from that group. Visit the order form (e.g. /order/main/index/orderformname) You will have 3 package groups to choose from: "Beginner", "Intermediate", and "Advanced" Once you choose one, you will then see a list of all packages you can order from that group I think that will be the closest native support for your use case.

Does the currency appear twice on the Order form, or everywhere else in the system too?
It looks to me like you are using the currency code as the suffix for the currency as defined in Blesta. You can double check under Settings > Currencies > Active Currencies > Edit (USD and CAD currencies). Do you have "USD" and "CAD" set as the "Suffix" value? Both of those currencies shouldn't have a suffix set, so leave them blank. You would just keep the setting "Show Currency Code" under Settings > Currencies > Currency Setup checked.

Linking to a product as described in the documention is what adds a product to the cart. Blesta's services have more options than I think WooCommerce products allow for, so there is additional configuration typically necessary for products, (e.g. config options, module options, addons, etc.) and what appears and where also depends on the order form used, but you can preselect most of those options and have them set in the cart per a link to the product, then the customer can fill out anything else and proceed with checkout.

Blesta comes with an .htaccess file in the root web directory and you should use that one. There is already a rule in it to force HTTPS and all you need to do is uncomment it to make it active.

Take a look at using the Order plugin's Embed Code field to add HTML to the footer. You can specify your JS there (i.e. Packages > Order Forms > Settings tab) and add a conditional to display content only when on the checkout/complete page. There are fields for order number and total price that you can use too, but there is no coupon code field. You could try to parse the coupon code field from the {{invoice.line_items}} if you really needed it, via other custom JS.
e.g.
{% if order_page == 'checkout/complete' %} <p>Total: {{order.total}}</p> <p>Order #: {{order.order_number}}</p> <p>Currency: {{order.currency}}</p> {% endif %}  

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.

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.

I just tested this and didn't encounter that issue. One thing to consider is that if you are an admin whose language is set to English, you will see English even when you log in as a client whose language is set to Spanish. The client will see Spanish when they explicitly log in to their account (i.e. when you are not an admin masquerading as a client).
Another thing to consider is that when the language has not been completely translated in Blesta, there may be definitions that do not exist in Spanish, and so they will fallback to English.

You mentioned in a ticket with us that you were able to resolve this issue by deleting extraneous ACL permissions set from the stats plugin by @Blesta Addons, so I'm just posting that here in case anyone else has a similar issue.

I'm sorry to see upgrading isn't going very well for you today. Normally there aren't so many issues.
It looks like the database server is rejecting a query attempting to add a new date column to the support_tickets table without being null because it's running in strict mode.
I suggest restoring and reattempting the upgrade again, but before you do, update your config file (/config/blesta.php) and change the sql_mode to a blank string.
i.e. find and change:
'sqlmode_query' => "SET sql_mode='TRADITIONAL'", to
'sqlmode_query' => "SET sql_mode=''", (remove the word "TRADITIONAL")
After the upgrade completes, revert this config file change.

Neither Blesta nor the gateway requires an update to support TLS 1.2. This is server-related. You should contact your hosting company and tell them you need them to support TLS 1.2.

There are two tabs at the top of the Themes page, "Admin" and "Client".  Make sure you are on the "Client" theme tab, then edit the client theme you're using.

See the documentation for reference.
Don't delimit the values with new lines, but pipe characters: |
SG:Singapore|UK:London  

The restricted packages are currently only orderable by admins from the admin interface. However, v4.3 addresses both of your concerns via CORE-718. That is, clients will be able to order restricted packages through the order plugin, and the order plugin will only display the package group if it contains at least one restricted package the client can order.

The 'd' is the problem. Something like a module, as @Blesta Addons mentioned, is likely the culprit. It is printing out the 'd' character causing the JSON to not be parsed and displayed in the UI. You'll need to find where the 'd' is being printed and remove it.

Moving an install typically requires 3 major steps:
Upload your current Blesta files from their old location to their new location Create a new empty database on the new database server Import your existing database tables onto the new database If your new database credentials differ from the old one, update them in /config/blesta.php After that, you should be able to use Blesta as you normally would at the new location.
If you have reinstalled Blesta, you have not moved Blesta properly. Reinstalling Blesta generates a new system key that is used for all encryption and hashing. All existing encrypted and hashed data, such as credit card numbers, user passwords, settings, package meta, service fields, etc. have been lost.

Make sure those email templates are enabled under Settings > Email > (Edit a template). For reports, those are only sent to staff that are subscribed to receive them. Each staff can opt-in to receive those emails by enabling them under their My Info > Notices section. You can make emails available to be opted-into by your staff by first enabling them on each staff group under Settings > System > Staff > Staff Groups > (Edit a staff group).

@Paul, I think he wants to apply the $45 paid offline toward the $80 owed so that $45 would be paid but $35 is still owed.
It sounds to me like you are attempting to record the $45 payment but you are trying to APPLY $80 of it to the invoice, hence the error. If I'm correct, you should make sure you are only applying a maximum of $45 to the invoice from the $45 payment. Make sure both Payment Amount and Amount to Pay are set to 45 for the invoice.

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.

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

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.

Session values are stored in the database as TEXT types, so they are limited to (2^16 - 1 = 65535) bytes.

It sounds like your Universal Module product has a Package Option called "windows", and when you went to edit the price on the package that uses it, you didn't have a value set for the "windows" field under the Module Options section.

There will be options for 12, 12.5, and 'Latest' in the updated module for v4.1 but the Plesk API is backward-compatible with older versions, so it should work just fine selecting 11.5 on the module when you're using Plesk Onyx.