Tyson

The Google processor Blesta uses is no longer available, so don't use it. It will be updated to another processor.

The service would be suspended according to the setting Suspend Services Days After Due.

Thanks for the report. The issues are fixed in CORE-2150 and CORE-2151 for version 4.0.

Is this a feature request for a setting regarding the invoice due date when a service is created? An invoice for a new service is due when it is created. Typically, services should be paid for before their service term, but that's not necessarily possible when the service is created. In some cases it wouldn't make sense to have it due any later, such as services with a term of 1 day. In this case, the service could expire before the invoice is ever due.

I think that illustrates the expected ticket status work-flow, but it doesn't address the UI ambiguity I mentioned above.

The issue is more of a usability one than of back-end logic. If statuses for "Awaiting Client/Staff Reply" both existed, automatically changing to them is where ambiguity arises, particularly in the admin UI. Consider: 1. Admin updates a ticket to add a note about something the next admin should be aware of. - If the ticket status is "Open", we could auto-select it as "Awaiting Client Reply". This gives the admin the illusion that the status is already "Awaiting Client Reply" since they did not change the status themselves. This can be confusing. - Additionally, when saving the note, the note gets added and the ticket status gets changed to "Awaiting Client Reply". The client may look at the ticket and see the status changed but there is no reply. This can be confusing to them as well. 2. Admin updates a ticket to reply to a client. - If the ticket status is "Open", we could show it's status as "Open", and only when the admin replies to the ticket do we automatically change the status to "Awaiting Client Reply" in the back-end. This can be confusing too, however, since the status change may not be expected considering it was shown to be set to "Open" by the admin, but it was changed anyway. Additionally, automatically changing the status in the back-end can effectively remove the ability for statuses to be changed. You would essentially have three statuses: Awaiting Client Reply when an admin responds, Awaiting Staff Reply when a client responds, and Closed when the ticket has been closed. The other statuses, i.e., Open, In Progress, would only ever be used when an admin specifically changes the status but does not reply to the ticket. What behavior do you prefer? If one of the above, how do you propose to rectify the ambiguity?

You're updating the services model? I mentioned in your other thread that a check on suspended services with past due invoices will be a very slow operation. You can write a subquery to fetch all service IDs for invoices that are past due and add a where condition to your existing query to fetch services that are not in that list. The subquery will be very slow, so you should limit the size of the result set as much as possible.

The behavior of checking that option is also described in the docs. The service will not renew, and therefore will not generate an invoice for its renewal.

Blesta v3 is much different than v2 due to the complete rewrite and redesign, so it's to be expected that some details would function differently because of the updates. I looked at Blesta v2 to check how it unsuspends services, and I see that it simply fetches all suspended services in the system excluding those assigned to an invoice that is past due. The problem with doing this in Blesta v3 is that a service and any of its options can be set on an invoice at any time, and paying any one of those invoices could potentially cause the service to be unsuspended, which is not ideal. The system would have to check that all invoices associated with the service are either paid or not past due. This would be a very slow operation, and there are a lot of different things to consider as well since Blesta v3 does so much more with invoices and services than it did in v2.

If the service has not been suspended, adjust the invoice due date. If the service has been suspended, adjust the invoice due date and unsuspend the service. The staff that (un)suspended a service is logged in the `log_services` table in the database. It is not shown in the interface. However, you can always write a custom report to export them if you want.

You don't find that automatically changing the 'awaiting' status could cause some confusion? If the ticket status is "Open" and I am adding a note to the ticket, why should it automatically change from Open to Awaiting Client Reply? In this case, I have not replied to the client.

If a service is already suspended because of an unpaid invoice, changing the invoice due date will not affect the service status. The service will only be unsuspended via cron if it has been paid and if it was previously suspended by cron. In your case, the service should be unsuspended manually.

cPanel allows servers to be placed in server groups, and then you can select the server group on the package, as I mentioned above.

Did you save the currency settings before clicking the "Update Now?" link? The exchange rate processor has to be saved before it can be used.

The error in your first post shows that Blesta asked for information on a user in Logicboxes and received an error. That may be due to a configuration issue. If Blesta cannot connect to Logicboxes, it cannot provision any services. Blesta will provision it if it is paid and pending according to the automation policy for the "Process Service Renewals" task under [settings] -> [Automation].

You can't decrypt user passwords in Blesta because passwords in Blesta are not encrypted. They are one-way hashes. There is no valid case where you should know someone else's password. If a user cannot login for some reason, they should change their password to something else.

You'll have to setup a redirect to the order page in that case. You can do so via .htaccess on the web server.

The server used to provision services based on your package depends on your module settings. If the module supports grouping module rows (i.e. servers), then you can put them in a group when you manage the module. Then, on the package, instead of selecting a specific module row (i.e. server) for the package, you select the package group instead, and the servers will be provisioned on any of them based on the Add Order defined for the module. Currently, there is only a "First non-full-server" Add Order, so services will be provisioned on the first server until it's full, then continue on to the next server. In version 4.0, modules like cPanel will have another option to evenly distribute services to each of the module rows in the module group.

You didn't mention any details on a service that should be suspended. What is it's due date? Is there an active unpaid invoice that the service belongs to? A pending service must be at least 24 hours old to be suspendable if you have the setting Suspend Services Days After Due set to "1 day". So if the cron runs on March 28, 2016 at 00:00 (midnight), then only services on or before March 27, 2016 00:00 could be suspended. If the service is due on March 27, 2016 00:01, it would not be suspended at that time.

There are no event handlers for the Order plugin. Unless you defined your own event handlers for updating/removing from the cart, those methods you wrote would never be called.

Normally, the error would appear on the page, but the system is not able to find the template to use to display the error. It generates the error to the current known view, which happens to be a plugin view, for a plugin that does not have a message template. You'll have to either disable CSRF token validation as I mentioned above, or pass the CSRF token along with the POST request.

Blesta uses version 1.6.2 of Stripe's API. I'm not sure how that correlates to the date July 28, 2015. The error you received indicates incorrect information was given about the card. See here. It doesn't sound like an issue with the API.

You can determine if it is ordered, but not if it has been paid. If it has been ordered, it will appear on the service. Package options are not directly related to an invoice. Yes, the option will appear on the service or input fields passed to the module when a service is added, updated, or renewed. If the package option exists on the service, it will be used during renewal. Yes, a client could order a package option for a service that already exists. An invoice would be created just for the package option they ordered. If an option is added to an already-active service, then your module will be notified about it via it's editService method. On renewal, your module will receive a call to it's renew method, and options will be available as apart of the second argument, $service. When the package option is added to the service, the service will be updated. This will cause the editService method to be called on your module, as I mentioned above. The package options are included in the third parameter, $vars, apart of $vars['configoptions']. The module has to return without error in order for the service to be updated in Blesta with the fields passed back from the module. Here's a work flow: Customer orders a new service. The addService method is called on the module. The module creates the domain remotely, and returns without error to Blesta. Blesta adds the service. Later, the customer orders a package option for the service. The editService method is called on the module. The module evaluates the configurable options in $vars['configoptions'] in comparison with the service fields already set on the service in $service. The module determines that the privacy option set on the service is "false" (default) and has been changed to "true" with new option change. The module makes a remote request to "purchase-privacy()" to change the privacy setting for the domain. On success, the module updates the service fields that it returns to Blesta to indicate the privacy option is now "true".

The {client_url} tag links to the client dashboard if they are already logged in, or otherwise shows them the login page. If you want to link them to the portal page, you don't want to use the {client_url} or {client_uri} tags, but the {base_uri} tag instead. See the documentation on email tags.

Short answer is you cannot make this determination based on whether a package option has been "selected and paid". You cannot tell from the option itself whether it has been paid. Whether a package option has been "activated" can be determined by the fact the package option is set on the service as I described a couple posts above. The issue is that you cannot reliably determine whether a package option has been paid. If a client orders a service and the package option was added when the service was added, and the service is active, you can assume the package option has been paid. If an admin created the service, they can make it active even if it's unpaid. Your module will be unaware of this difference. If the service was added, and later a package option was added, then: - if the setting "Queue Service Changes Until Paid" is checked, the package option will not be added to the service until it has been paid, so you can assume that if it is on the service, it has been paid. - if the setting "Queue Service Changes Until Paid" is unchecked, the package option will be added immediately, even if not paid. You couldn't determine if it has been paid.