Tyson

The Plesk API in v12+ still supports everything that the Plesk module does in v11.5, so you should be fine. There is probably some misconfiguration with API connection details or with permissions for Plesk products in Plesk.

Validation is done in batches. First, attempt to create the user, then attempt to create the client. A user requires a username and password, without which, we cannot continue to create the client, so error checks stop. It could certainly be more user friendly to run all checks, but logically unnecessary because of the dependency.

I understand the request for a 64-character key length, but I'm not convinced by the argument that it is necessary. I explained more in your parallel feature request.

That error is unrelated to Blesta source. The error refers to a file that Blesta doesn't come with. The variable $contact is used when not set.

I'd recommend using an acronym. These keys are meant to be short and concise. 64 characters isn't very short

And `support_attachments`, the files of which would need to be deleted too.

I don't encounter that issue myself on 4.0.0-b5, but the error you receive is very generic, shown when no known error is available. This means there is a wide range of possible reasons for the error, from server or web server configuration, php configuration, htaccess configuration, to custom code that may interfere with the it. It would be useful to know exactly what information you're using to create the recurring invoice, what URL you are sent to on error, what version of Blesta you're using, if you have any custom code/plugins in your installation, and what versions of php, MySQL, web server, and OS you're using.

Developers, note: Previously deprecated methods have been removed. Stop using these immediately: Controllers: AdminBilling::reports (/app/controllers/admin_billing.php) API/Models Companies::validateCompanyInUse (/app/models/companies.php) PackageOptions::getValueProratePrice (/app/models/package_options.php) Packages::getDaysToProrateBetween (/app/models/packages.php) Packages::getProrateAmount (/app/models/packages.php) Services::setOptions (/app/models/services.php) Components WidgetClient::renderSubHeader (/app/components/widget_client.php) Additional classes/methods have been deprecated. You should stop using these ASAP: API/Models Invoices::getItemTotals (/app/models/invoices.php) ServiceChanges::getItems (/app/models/service_changes.php) Services::getItemsFromData (/app/models/services.php) Components PricingPresenter (/app/components/pricing_presenter/*) Helpers Areyouahuman (/app/helpers/areyouahuman/*) Recaptcha (/app/components/recaptcha/*) More deprecations will likely follow.

You might get some responses (if no one PMd you already) if you include the layout you expect. Config options have a many-to-one relationship with a service/order, so you would either need to list the same order multiple times (once for each config option) or group them all into a single cell.

It is expected staff would subscribe to plugin emails from functionality within the plugin itself. The Support Manager, for instance, lets staff subscribe to receive ticket emails for tickets of a specific status and is sent to a specific email (e.g. mobile email). It wouldn't make sense for a staff member to receive BCC notices about ticket emails sent to another staff member that subscribed to them (or possibly sent to the same staff member twice). Plugin emails are custom and conditional as far as the core is concerned.

Canceling a service at the 'end of term' will set the cancel date to the service's renew date. The service wouldn't be renewed, and instead will be updated by the cron to be canceled on that date. I'm not aware of the cancelation date getting updated automatically anywhere in the system. Is it possible the cancelation date was changed manually or updated via the API from custom code/extensions?

Take a look at the source docs. There is a ::getAll method that accepts a client_id rather than a user_id you have in your example.

It would be good to have some steps to duplicate the issue, but I think your last post illustrates the problem--the currency has to be the same for the service/options otherwise they can't be represented on an invoice.

Has anyone else been able to duplicate this issue with PayPal?

Does the debugger have a setting to show warnings? That may be why it shows up. You may want to see if there is a way to disable that. The point of the code you referenced above is to fallback gracefully on failure so that you don't receive errors like the one you did.

It sounds like they entered their bank info during an order, correct? A charge would have been attempted, and should appear in the Gateway logs. You can take a look at those logs' Output to see what the issue was. You may see something like: 3|1|9|The ABA code is invalid||P|0|3690||0.53|ECHECK|auth_capture||John|Doe||1 Main St|City|CA|90001|US|||||||||||||||||8539E64391FDE8BC22418AC46D054E04|||||||||||||XXXX6789|Bank Account||||||||||||||||| The error message would be the after the 3rd delimiter, i.e., "The ABA code is invalid". Are there any similar messages for your client?

A one-time link assumes the user clicked it and actually changed their password. This would require that we log all user password changes, which is another feature in itself. The current TTL would still have to apply regardless.

Does it occur when your debugger is disabled? What type of error is it? A Warning, or Exception? It seems odd the error would not be caught and handled properly in php5.6.

Is this a bug report? It would be useful to have some additional information on an issue you're having.

Thanks for the report. We'll take a look at the page title. The password reset link included in an email is only accessible for a short period of time. By default, it is available for 4 hours and can be changed in the config file for 'Blesta.reset_password_ttl'.

Blesta passes all necessary arguments to language definitions that are required. We weren't able to duplicate this issue with that language definition in the current beta. My only thoughts are that there could have been custom changes made in your installation, where that definition is called, to not pass all of the required language replacement arguments as expected. Either that, or there is something else affecting it, perhaps third-party code.

What is the issue here exactly? I'm a bit confused as to the concern. If blesta-new.php is not writable, the error appears to be valid. If you then updated permissions for your user and ran the install, then all should be good. Attempting to run the install a second time when it's already been installed should fail.

The translator doesn't include v4 language yet.

Just to reiterate Licensecart's point, a different 'value' must be set for each option. HTML forms distinguish between labels (what you see on the page next to the radio button, or as a select option), and the value (which gets submitted). Since each radio option had no value, they were all an empty string, which is not useful because you cannot distinguish which option was checked.

Do you have an $invoice->id_code for that invoice in /app/controllers/admin_clients.php, AdminClients::editInvoice? The language definition AdminClients.editinvoice.page_title is set there and passed the client ID code and invoice ID code, and only two arguments are expected. You only have 1 argument set, so it looks like you may have bad data set for the invoice (e.g. no id_code).