Tyson

They may have the same transaction number, but are they identical? I would need to see a set of logs to tell for certain. The log times appear to be off anywhere from 6 to 30 seconds. I wonder if the payment status was first pending, then 6-30 seconds later it was approved by PayPal.

Create a Contact of type 'Billing' for each person (email address) you want to receive client invoices, as Licensecart mentioned. Go to [settings] -> [system] -> [staff] -> [staff Groups] -> (Edit your staff group). Make sure all of the checkboxes under "Email BCC Notices" are checked. If not, check them and save. Then go to [My Info] -> [Notices] and check all of the email templates you wish to be BCC'd on.

The log table doesn't say much without clicking on the rows to view the Input/Output. Compare two records of logs you think are identical and find the difference between them. My thoughts are duplicate payments are being made, or PayPal is responding more than once about the payment.

If you are able to test the email template by having it sent to yourself, you can use the {% debug %} tag in the template to list all the fields you can use as tags. Make sure the email doesn't get sent to anyone else other than you though, as it can contain sensitive information.

A module's addService method is called when the system determines the service is being added using the module, whether or not a pending/draft/etc. service already exists in Blesta or if it's being added concurrently. The module is not given enough information to make a distinction on this difference, and it is out of the module's scope to do so. So what does your module do that you think it needs to make this distinction?

The fact no logs exist in Blesta suggests the callback URL is either incorrect or PayPal is unable to communicate with it. This might happen, for instance, if you're testing payments from your local machine @ localhost.

What's the callback URL?

Are you asking for a tag in the email template that contains client information? I suppose that would be possible to include, but would require you to use conditional statements in the template since the client will not always be known.

If there is no log about the cPanel module attempting to create the account, then cPanel never attempted to do so. Once an order is placed, the invoice needs to be paid before the system will attempt to activate the service and create it in cPanel. Even if it is paid, you may have the order form configured to require manual approval of orders before they can be activated, and you simply haven't manually approved the order.

I believe you need to be using the cPanel module v2.2.1+ that comes with v3.4.2+ of Blesta.

This is fixed for v3.5. See CORE-1718 for a comment on the task that describes how to resolve it in the meantime.

Is your staff user subscribed to the "Service Creation" email subscription notice under [My Info] -> [Notices]? If so, the system will send you an email using the "Creation Error" email template, which lists each error, when the cron fails to update the service.

The update is rather simple, requiring another octet to be set for validation. Instead of validating 2+ octets, it's 3+.

This will be updated in 3.5 as apart of CORE-1716.

This will be in 3.5 as apart of CORE-1717.

I'm not able to duplicate that behavior. Are you sure the payment account is set for autodebit? If the client profile shows Auto Debit as "ENABLED" with a strike-through, then a payment account is not set for auto debit.

Does the client that received that email have autodebit enabled? Under their profile, the "Auto Debit" section in the sidebar would say "ENABLED". Does the client have a payment account setup? If so, is a payment account set for autodebit? Under the client's payment accounts page, a radio button exists in the table next to each row. Auto debit is enabled for the payment account that is selected. Is the invoice an active or proforma invoice? If autodebit is enabled, the invoice is active, and a payment account exists for autodebit, then they should see this in the email: Auto debit is enabled for your account, so we'll automatically process the card you have on file on {invoice.autodebit_date_formatted} unless payment has been applied sooner. Otherwise: If you would like us to automatically charge your card, login to your account at https://{client_url} to set up auto debit.

The invoice autodebit date is an override date. If an override date is not set, the auto debit date is determined from the invoice due date and the setting Auto Debit Days Before Due Date. How are customers prompted to setup auto-debit? Is this in an email template?

I'm going to close thread this as not a bug with Blesta. However, it would be useful to avoid this problem altogether by (CORE-1677) validating service fields before queuing them, which would be an improvement for sometime in the future.

If you want to fix this yourself, Open /app/models/services.php and find: $module->changeServicePackage($package_from, $package, $service, $parent_package, $parent_service); if (($errors = $module->errors())) { $this->Input->setErrors($errors); return; } Replace with: $service_info = $module->changeServicePackage($package_from, $package, $service, $parent_package, $parent_service); if (($errors = $module->errors())) { $this->Input->setErrors($errors); return; } elseif ($service_info && is_array($service_info)) { $this->setFields($service_id, $service_info); $service = $this->get($service_id); }

The cron adds the service from a pending state. If you haven't already, you could create a pending service in Blesta manually, then activate the pending service from the admin interface to see if you encounter the same issue. If you think it is related to your module, you can check your module's addService method to see how it is validating fields, and compare that with the $vars it should receive. If your module uses config options, you may want to try with and without config options of the quantity type, as there is a known issue with quantity-based config options described in CORE-1715 that may result in a service failing to be added.

I believe the problem is an upgrade (change of package) to a different plan (SSD-5) that updates the plan with the module but does not update the service in Blesta to the new plan. The plan is then out of sync with SolusVM, accounting for the discrepancies in values like extra memory that rely on the plan for proper calculation. The larger issue here is described in CORE-1669.

Sample: class MyController extends AppController { ... public function method() { // Load the model to use to query the database $this->uses(array("Clients")); // Fetch client ID 1 $client = $this->Clients->get(1); // Make the client available to the template in the variable "$client1" $this->set("client1", $client); } ... }

This may be the problem. Make sure that the plan set on the service is the correct plan it is set to in SolusVM. It's possible if you upgraded the service to use a different plan that the plan on the service in Blesta no longer coincides. You would need to check the database. Run the following query to determine the service's plan. Replace SERVICE_ID with the ID of the service: SELECT * FROM `service_fields` WHERE `key` = 'solusvm_plan' AND `service_id` = 'SERVICE_ID';

That would make sense.