Tyson

Performing database queries from a template negates the purpose of the MVC design pattern. You're better off making an AJAX request as Licensecart mentioned to fetch currency balances from existing controller methods. Alternatively, you can update the controller to fetch the balances and set them as variables to the template you want to display them in.

That's interesting. How about disabling service change queuing via the "Queue Service Changes Until Paid" setting and then updating a service with prorate checked? This and the service queuing perform the same validation checks, so I would expect you to receive the same error. That error is caused by one of the following: The config option does not exist with the given value at the given pricing The option is a quantity type and the given quantity is less than the minimum allowed The option is a quantity type and the given quantity is more than the maximum allowed The option is a quantity type and the given quantity does not follow the Step of allowed quantity values If possible, it would be useful to compare the POST data of a successful edit (without queuing/proration) versus the queued data stored in `service_changes`.`data` of the same service to see what information is different.

What 'invoices generated by pro rata actions' are you referring to? Things like service upgrades don't queue invoices for delivery.

Thanks, this is fixed in CORE-1710 for v3.5.

The service could be failing for any of several reasons, usually related to service validation at the time of processing. It would help for validation to occur before a service change is queued so that it can be refused due to error, but that is currently not possible. And there is not yet an interface from which to manage service changes, so I can only suggest to log the service errors in the meantime to identify the errors causing those changes to fail. In the ServiceChanges model (/app/models/service_changes.php), find the reference to the service validation errors: $errors = $this->Services->errors(); Below that add your logging (e.g. to a file). I might simply add echo "\nCHANGE #" . $service_change_id; print_r($errors); ..then disable the Process Service Changes cron task from the Company Automation settings for a few minutes such that the task has not run within its set interval. Then re-enable the cron task and immediately run the cron manually from the System Automation settings before it is run via cron automatically. The paid pending service changes should be processed, and any errors should appear in the cron output. Note that you would need to update some records from the `service_changes` table from status "error" back to status "pending" to attempt to process them again.

As serge mentioned, you should include an instruction message for the Offline Payment gateway, such as an address to send money to. You can do this under [settings] -> [Payment Gateways] -> (click Manage for the Offline Payment gateway). The issue you are having with updating a client because "that username has already taken" is a bug that is fixed for the next release of Blesta (v3.5). However, the issue does not prevent clients from updating their information. You are an admin that is also logged in as a client, which is why you experience this issue. If you logout as an admin, and login directly as a client, then you will not experience this problem, so your clients will not either. A description of this issue is available from its assigned task in CORE-1699.

Check the Module logs for more information under [Tools] in Blesta. Under [Tools], each record in the table contains raw data regarding API communication to and from the Multicraft server. Click the table row for a Multicraft entry to see the logs for that particular request (e.g. when creating a Multicraft server). Look for the response that ended in an Error, and the raw output should contain some data that may help determine the cause of the failure. Feel free to include the problematic logs in this thread if the issue is not apparent to you.

The Interworx module in Blesta doesn't send email. If you're referring to the invoice due notice sent when the service renews, that is sent via the "Create Invoice" automation task. You can check to ensure that it is enabled to run via cron under [settings] -> [Automation]. Sending an invoice by checking a box next to it from the client's Invoices table and emailing it to a specified email address will send it immediately. You can view the email that was sent under the client's mail log. You can check the company email logs under [Tools] -> to see if the email you're referring to has been sent. You can also send an invoice to your email address to check that it is working.

Instead of logging in as a client, you can just add a contact for the client in the admin interface.

Look under [Tools] -> . If an email was to be sent, it will appear there with a status of whether it was delivered. If it's not there, then it was never attempted to be sent.

The "Starting At" price is from the /plugins/order/views/templates/wizard/main_packages.pdt template. It currently shows the lowest numeric price, however, it would require several changes to show the lowest price per month. It becomes more complex if you have non-monthly terms in the mix as well. As an example, I will only show changes for the Wizard Boxes template, and ignore non-monthly terms for simplicity. Find: foreach ($package->pricing as $price) { if ($lowest_price === null || $lowest_price->price > $price->price) $lowest_price = $price; } Replace with: $lowest_monthly_price = null; $lowest_monthly_currency = null; foreach ($package->pricing as $price) { if ($lowest_price === null) { $lowest_price = $price; } if ($price->period == "month" && $lowest_price->period == "month" && $price->term > 0 && $lowest_price->term > 0 && ($price->price/$price->term) < ($lowest_price->price/$lowest_price->term)) { $lowest_monthly_price = ($price->price/$price->term); $lowest_monthly_currency = $price->currency; } } Find: <div class="package panel-blesta <?php echo ($this->Html->ifSet($package_id) == $package->id ? "selected" : "");?>" data-group-id="<?php $this->Html->_($package_group->id);?>" data-pricing-id="<?php $this->Html->_($lowest_price->id);?>"> Replace with: <div class="package panel-blesta <?php echo ($this->Html->ifSet($package_id) == $package->id ? "selected" : "");?>" data-group-id="<?php $this->Html->_($package_group->id);?>" data-pricing-id="<?php echo $this->Html->safe($this->Html->ifSet($lowest_monthly_id, $lowest_price->id));?>"> Find: <h4><?php echo $this->CurrencyFormat->format($this->Html->ifSet($lowest_price->price), $this->Html->ifSet($lowest_price->currency));?></h4> Replace with: <h4><?php echo $this->CurrencyFormat->format($this->Html->ifSet($lowest_monthly_price, $lowest_price->price), $this->Html->ifSet($lowest_monthly_currency, $lowest_price->currency));?><?php echo ($lowest_monthly_price !== null) ? "/month" : "";?></h4>

The renew date change validates the current service fields that already exist while the upgrade/downgrade evaluates the options submitted from the page. It seems that some old records existed that probably shouldn't have, but I'm not sure why they weren't removed automatically. Based on what you described, it sounds like you should indeed have 5 config option records for that service, and it's odd that you had 10/9/8 before you removed them manually. 3 dropdowns + 1 (of 7) checkboxes checked + 0 (of 2) quantity sliders + 1 (of 1) quantity input = 5 records

configoptions are only included if they are given when the service is created. The same is true for other fields as well. You shouldn't assume that every field will be given. vars - An array of input data which may include: ... configoptions - An array of key/value pairs of package options where the key is the package option ID and the value is the option value (any other service field data passed to the module) ...

All of the invoices are in the same attachment PDF file.

The service event includes information specific to the service, but does not include package info. See the Event Handlers docs for data that may be included.

If you set an upper limit for that option, can you then change the renew date without error?

Thanks, this is fixed for the next beta in CORE-1704.

for each service $i Service ID: $services[$i]->id Client ID: $services[$i]->client_id endfor

This fix will be in v3.5 beta 5

I think that field is shown because that entire section is re-used from other pages where a Company field actually is used. But I'll remove it from payment accounts in CORE-1702.

Sounds like an interesting issue. Can you check the database to see if there are some out of place config option records on that service? Fetch all config options on the service by service ID: SELECT * FROM `service_options` WHERE `service_id` = 'SERVICE_ID'; Do the number of records listed match the number of config options on the manage service page? New config options and config options of quantity 0 would still be shown on the page, but would not have a record.

Yes, I believe saving the service again with its config options would perform the same validation check (on the given config options rather than the current config options) if the upgrade is not being queued. Then the config options for the service would be updated to remove any that are invalid. Do you experience this issue on any other services, or just one in particular? Is it possible to create a new service and encounter this issue?

Which version are you using? If it's v3.5, upgrading cannot be done again if an upgrade is already queued, so the buttons to change package/term would not be available. Otherwise, the buttons should appear if: Both packages use the same module (You said they do) Both packages have similar terms (e.g. both are recurring, as you said each is 12 month term) The client group setting "Allow Clients to Change Service Package" is checked. The service is active. The service has no cancellation date The service does not already have queued changes waiting to be processed

Have you checked the server's error logs?

The cancellation date is included because it's in the same form, but it is ignored when changing the renew date. The POST data looks normal. I think the issue may then be related to what I mentioned before with old service config options still being set on the service. Does that service happen to have a config option that no longer exists as a Package Option, or that may have changed term/currency to one that no longer coincides with the service term/currency?