Tyson

I believe some searches already remove extra white-space. Which search type is problematic for you?

Canceling a service is a detrimental unrecoverable action. Perhaps in the future when additional functionality is added to allow for (partially) uncanceling a service this can be revisited. The Auto Cancel plugin, however, will perform the action you're looking to accomplish. Ideally, the core should be an extensible framework which supports integrating additional features via plugin. Simply adding everything to the core is the approach we want to avoid. From our experience, most customers that have a suspended service for several days end up coming back to reactivate it, and canceling it instead can be much more of an inconvenience for them than keeping it suspended. A VPS service, for example, could be removed and all content deleted on cancelation, and its data may not be recoverable if the customer needs it afterward.

What did you do to fix it?

Removing extra white space at the beginning or end of fields is a fine request. However, this is not something we would necessarily want to have for every input field.

The database schema is fine. I think you mean the values stored for states and countries? The problem is that many values are subjective and that there is no perfect world-wide solution of acceptable values. Some countries, states, or provinces may recognize certain values while others do not, and it is not possible to accommodate all possibilities by default. The ISOs are the best values to use by default because they are standardized. We can re-update the states and countries to reflect any changes in the ISO since it was last updated, but for more granular changes I'd still recommend using the plugin.

The translations you made today are not immediately available for download, and do not affect the overall statistics until the page cache is updated. It will say 94% until the page cache is updated, but will not be available in the download until the language files are updated with them, which usually occurs every week or so. I can have them updated later today or tomorrow, at which time you can download the updates and you'll see it increase from 94%.

The error returned is converted from UTC to the server's current time. If you are 13 hours ahead of UTC then it's possible you could see the date in the error "off by a day" depending on the time of day you encounter the error. At other times it may appear the same. This discrepancy is fairly minor, as it only affects the date shown in the error message. It looks like the renew date in the field is shown correctly, which is more important. The database stores all dates in UTC, and since you're 13 hours ahead, most of the date values will appear to be yesterday, because it is yesterday in UTC. And this is the expected normal behavior.

The code you provided shows what is set to your gateway's view. I see you set a $redirect_url that is unused, though. What is the content of the process.pdt view? This is where your form is being generated.

If you've updated the cron key from the admin UI, you can double-check that it has been saved by checking the database as you did before. PHPIDS usually redirects you to another page if it blocks a request. It might have been that updating the cron key is a request it blocked, which would explain why the cron key was not updating for you earlier.

From what I recall, this has always been supported by the Support Manager. As LicenseCart mentioned, you should check your Support Manager email templates to ensure the subject contains the {ticket_hash_code} tag as described here.

I suspect the slowness may be due to your MySQL server on another computer. What is the network speed between the web server and this MySQL server? It may not be able to keep up with the requests from the web server, or just takes too long to respond over the network. If you want automated actions to take place, you'll need to have a cron job setup to do them. Blesta doesn't setup a cron job automatically, as it depends on your environment. You wouldn't be able to subvert the 'pending' status of services, as they are pending often because they are unpaid or awaiting moderation and thus not ready to be activated.

That might be something we can fix. Note that it does not occur when setting up a server in the admin UI, but from the order form instead. The error I receive is "Please set a name for the server." CORE-1967

You would either need to manually cancel the service, or use the Auto Cancel plugin to control when suspended services should be canceled.

It sounds like you upgraded v3.4.0 -> 3.4.2 via CLI, but a further upgrade to v3.6.1 is not possible because you are using v3.4.2 of the Blesta files still. The footer will always show the latest version of the files, so it is clear that they have not yet been overwritten to those from v3.6.1. Once you overwrite those files, then you should be able to run the upgrade.

I replied to your ticket in our system. Feel free to reply here if you need any other clarification.

The database_version may not be the same as the version shown in the footer of the admin UI. The database_version of '3.6.0-b1' is the latest version. Don't change this value or you won't be able to upgrade. The exchange_rates_auto_update setting from the `settings` table is not the value you would want to look at for your cron as the value from the `company_settings` table is used instead. Be careful making modifications to the database if you're unsure how it will affect the system. I'm not sure why the cron key would fail to update from the UI. Are you using the PHPIDS plugin by chance? If so, you might try disabling it and then trying to save the cron key to see if it works then.

Where are you posting the request to? What is contained in the request?

Blesta v4 will work with php7 if it doesn't already work in Blesta v3. I haven't tested it.

What you've described is normal. I believe the 0.02% statistic you are referring to represents YOUR personal contribution to the Spanish language. The 94% statistic means that 94% of the entire Spanish language has been translated from all contributors, while 6% still remains untranslated (i.e., no Spanish definitions at all). If your account has the setting Show Terms set to either In Order or Randomly, then you will automatically be asked to translate terms from the untranslated 6% first. After there is at least 1 translation for every definition in the entire language (i.e. 100% translated), then any additional translations provided will be accepted to improve the quality of the translated definitions.

What is the purpose of having two fields? You would need to give each field a different "Name" in the Universal Module.

Thanks for listing the data. No, that's not necessary. I believe you. The problem is that company 6 is set to allow inheritance of the tax_id field. Once that is disabled, clients without a tax ID will no longer inherit the company tax ID. mysql> SELECT * FROM `company_settings` WHERE `key` = 'tax_id'; +--------+------------+-----------+-----------+---------+ | key | company_id | value | encrypted | inherit | +--------+------------+-----------+-----------+---------+ | tax_id | 1 | | 0 | 0 | | tax_id | 2 | | 0 | 1 | | tax_id | 3 | | 0 | 1 | | tax_id | 4 | | 0 | 1 | | tax_id | 5 | | 0 | 1 | | tax_id | 6 | 123456789| 0 | 1 | <--- should be 0 +--------+------------+-----------+-----------+---------+ 6 rows in set (0.00 sec) The issue should be resolved once you run this query: UPDATE `company_settings` SET `inherit` = 0 WHERE `company_id` = 6 AND `key` = 'tax_id'; The inheritance may not be set correctly when you create a new company by cloning the settings of another, and that's something we can look into and resolve for the next release as apart of CORE-1942.

Update it under [settings] -> [system] -> [Companies].

Thanks for the information. However, I'm not able to duplicate that behavior. Could you run the following query and let me know the results? SELECT * FROM `company_settings` WHERE `key` = 'tax_id'; Assuming you only have one company, there should be one record found. What data is contained? Feel free to omit the `value`.

In which case(s) do you see the tax ID being inherited from the company for a client? Is this shown in the interface (what pages), or via some API queries (what queries)?

That sounds like an error attempting to process the order with the module. Your module may be misconfigured, as Blesta is unable to determine the appropriate module row from which to provision the service. You should re-check your module settings and make sure your package is setup correctly to use an available module row from that module.