Tyson

While the payment was verified with PayPal, Blesta could not determine whether the payment went to your account because the given "business" or "receiver_email" from PayPal did not match the account ID (PayPal Account Email) you have set in Blesta for PayPal Payments Standard. The same logic is checked for non-subscription payments, so if this only happens for subscriptions, it may be that PayPal is not sending the "business" or "receiver_email" fields, or they do not match your PayPayl Account Email.

Maintenance mode in v3.4 will allow for Markdown, and be displayed on its own page. CORE-1395

There are instances where tabs from a module would be useful to clients, such as when a service is suspended. And simply removing the name of the tab from the list of client tabs would not stop clients from viewing the content if they chose to. The content displayed in the tab, however, can be changed by the module. So instead of listing statistics, it could simply show a message that "No statistical information is available at this time."

Ah, yes, the pricing had been refactored into the pricings table a while after those source doc comments were written. Sorry for the confusion.

Your issue sounds like a misconfiguration with MySQL. You've already looked into the documentation on that error?

Thanks for the reminder. I forgot about that caveat with Plesk. You can find that previous thread here.

What part is misleading from the docs? Glad you were able to figure it out. You should be using POST rather than GET for that request, though. But as you're probably aware of now, the third parameter to each of the API SDK methods (get/post/put/delete) is $args: an array containing each of the methods' arguments, as described in the docs.

I suppose you would need to select a different Type to set a default value. Maybe another improvement could be to allow default values to be set/selected for each type. I like the idea of adding in more improvements to custom fields, like making a field read only only after it has been added once, but that is beyond the scope of the current "Read Only for Clients" option. I wouldn't want to tie this feature into that setting because it would add unnecessary complexity. A setting should only handle a single, specific, use case. I wouldn't want users to be confused because "Read Only for Clients" would then be conditional on whether a client is being created or edited. Of course, you could update the Order registration form to update this behavior--and by all means, feel free to do that--but we have to consider how this would affect everyone that uses custom client fields, and provide the best simple and general solution for all. I believe the simplest solution here would be to create a new setting to handle that case.

I think this falls into 4º- Setting configurations that can contradict each other in some contexts (i.e. misconfiguration) But there are two main kinds of bugs: Functionality that does not work as intended A program that causes an unexpected error or flaw (basically #1) Both of those would be determined from the perspective of the software developers. I would say this is not a bug because "Read Only for Clients" is clear that the field is read only. If it should also be a required field, then you should set a default value, because read only fields cannot be written by clients. It sounds like you want an option for clients to set a value once, but never again (i.e. add but never edit). And I think that might be a good feature request.

Why would the first invoice have services from Oct 1 to Nov 1, but not the prorated days from Sep 12 to Oct 1?

Maybe I'm a little confused as to what the issue is exactly. If you have pro rata setup for the packages in your first screenshot, and the customer ordered those 4 services, then it looks correct in that it's billing the partial month between Sept 12 and your pro rata day (1st of the month) --i.e. Sept 12 - Oct 1. In the second screenshot, since you have a pro rata cut off day set to the 23rd of the month, and they ordered it on the 27th, they are charged the partial month (Sept 27 - Oct 1) plus the full term for the next interval (Oct 1 - Nov 1). Both seem correct to me. How do these orders differ from what you're expecting?

Since you are requiring manual review of orders, then you should head over to [billing] -> [Overview]. If you don't have the Orders widget available on the page, click "Manage Widgets" to add it (drag it to the left). The page will reload with the Orders widget shown, and you can check the box next to the pending order that you want to approve, and mark it as accepted by clicking the "Update Orders" button. Afterward, go to activate the service.

Could you clarify this issue? Node groups are only loaded after a Type (e.g. Xen, KVM) has been chosen.

If you have your cron setup to run on your server, and you have the Provision Paid Pending Services cron task enabled (it is by default), then paid services will be provisioned by the cron as often as the cron task interval allows (default is 5 minutes). e.g. Customer orders domain from the order form Customer pays the invoice created for that service <within 5 minutes> Cron provisions the domain with the registrar Service is active

Have you checked whether Plesk is sending a response back to Blesta at all (by monitoring outgoing packets from Plesk)? It might be that Plesk is simply not sending a response or a firewall is blocking the response, and the connection times out for that reason. It's sounding more like the issue I mentioned above about Interworx--that the server may be restarting before it sends an API response back to Blesta.

The one created by cron looks like a set of the same services (2 orders) added separately, pro rata only (no cut off). Can you confirm?

A new email template will be in v3.4 that will be used to send these non-merchant gateway payment receipts.

The Refunded status will be in v3.4

Definitions for v3.3.0 have been added to the Translator.

We don't want to delete data that can have adverse effects on other areas of the system, so we prevent its deletion, and it should be marked inactive instead. We may revisit this in the future to allow packages to be deleted if we can avoid the data loss for attached services in an acceptable manner. As for finding the services, you should be able to use the Smart or Service search in the admin interface to search by the package name in order to receive a list of services, or clients that use that service, respectively.

Are there any IP addresses available in Plesk for the client's subscription to be assigned to? Perhaps the Subscription (Webspace) ID could not be set for that reason? In any case, I think you should be able to fix that issue by entering and saving the Subscription (Webspace) ID in Blesta, as shown in your screenshot. You will need to find that Subscription ID number in Plesk, or create it if it does not already exist (possibly due to no IP addresses being available).

Are you receiving the OP's original timeout error ("The connection was reset")? I'm not sure if this applies to Plesk or not, but some modules can perform actions without responding to Blesta. For example, Interworx might receive a request to create an account--and it will create the account-- then restart the server immediately. However, Interworx never notifies Blesta that it created the account (because it restarted immediately), thus causing a timeout. The end result is that the account exists in Interworx, but is not activated in Blesta. If that sounds like what may be happening, there could be a setting in Plesk, similar to Inteworx, which allows for graceful restarts so that an API response is sent back to Blesta before Plesk performs another action.

The event is triggered after the transaction is created. No payments are applied (to invoices) when a transaction is added. That would happen afterward. The amount due is the unpaid amount for invoices, so yes, not applying transactions to invoices would be considered unapplied (credits). A payment received for an account is a transaction. But there is currently no event for when a transaction is applied to an invoice.

I'll close this thread as not a bug. But create a new one if you are able to replicate this behavior in beta 2.

"Module email"? You mean the package welcome email? That is included in the Service Creation email template when a service is created, manually or otherwise. However, you can disable it from being sent manually by unchecking "Send order confirmation email" when creating an active service.