Tyson

You may want to create a feature request for the "PDF Receipt" after payment. As for the OP's feature request to attach the invoice PDF to the notice emails, I think that would be a fairly simple addition.

The email template uses conditionals to make this determination: {% if autodebit %} {% if invoice.autodebit_date_formatted %} ... {% endif %} {% endif %} When you look at the client profile page, does the "Auto Debit" section say "ENABLED" without a strike through it? If so, then the first conditional is met {% if autodebit %} The second conditional is passed when an autodebit date is set. An autodebit date is only set if there exists an active ACH or CC payment account, the payment account is set for autodebit, the autodebit setting is enabled, the invoice is either active or proforma, and the setting exists for the number of autodebit days before renewal.

If you're using Blesta's login controller to handle logins, it's going to render its set template. If you want to redirect to your page you would need to update the client_login controller.

You'll have to give more info as described in How to Report a Bug, such as the dates you're changing from/to, the service term/period, any coupon/discount on the service, what you expect the result to be (credit/invoice), version of Blesta (I assume 3.5), etc. I'm able to see an invoice being created for a renew date change into the future, however, based on the date you choose and the price of the service, the prorated amount can still come out to be $0 where no invoice/credit would be created. And yes, it can only be prorated if there is no set price override. The price preview is for service term/package and option changes, but not for renew date changes. Renew date prorated price changes aren't currently previewable.

If proforma-141 was removed (as you say, it became #149), then it is possible for the next proforma number to generate proforma-141 because it is no longer in use. For duplication, I am wondering whether you can consistently create a new proforma invoice that turns into a normal invoice by itself. If you can consistently replicate that behavior, then I will be able to test this issue myself to confirm whether it is a bug. As it stands, however, I am not able to duplicate that behavior. I agree the issue appears odd, but there may have been more to it than what you've described. A proforma invoice normally changes to a normal invoice when it has been paid and closed. Perhaps knowing the values you set when creating the invoice would help, and whether it was first saved as a draft.

If the proforma invoice really is now invoice #149, can you duplicate this behavior? If so, can you detail the steps necessary to duplicate it? I don't see any way that creating a proforma invoice would list it as a normal invoice, especially when the proforma number is shown in the success message.

I think the issue you're describing was fixed in beta v3.5.0-b2 apart of CORE-1489.

Proforma invoice numbers can be used again if the previous one was paid. You may want to read up on the discussion from this thread.

v3.5 introduced new price calculations, but they only affect queued service changes and not yet the rest of the system. The coupon system needs to be refactored to keep up with the updating features, which unfortunately has not been possible yet.

That looks like a SolusVM error. You may want to log into your SolusVM account and check the disk space allocation for the plan you're trying to use and compare that with the node's disk space availability.

The client interface and the order form are effectively "the client area". There is no option to make a custom field available to the client, but also limit where in the UI it is available to the client. Not sure if this would work for what you're doing, but you could make it visible to clients and also make it read-only. They'll see it, but they can't change it.

Yes, I'm not sure the point of the KVM ISOs, but in any case, this is fixed for the next patch in CORE-1722 for v3.5.1.

Open /language/en_us/client_main.php, find "ClientMain.myinfo.link_editclient" and change it there. This is a core file, so you would need to maintain this change through any upgrades to Blesta you perform in the future.

Thanks for the info. Can the ISOs received for the templates be used for KVM (from $response->templates), or only the KVM templates (from $response->templateskvm)?

Are you trying to activate the pending service as an admin from the Manage Service page? If so, are the fields (e.g. game ID, machine location, etc.) shown on this page? If not, that would be why they are missing from $vars. Your module should define these fields in its ::getAdminAddFields method so that a service can be added/activated manually by an admin.

Take a look at this post. There is not a way to perform unique checks on service data at the time it is being added without updating the core to support it. I'm not sure your unique domain rule is a very good one though. If a service is canceled in Blesta that uses a specific domain, your rule would not allow that same domain to be ordered again for a subsequent service.

What's contained in $vars and how does ::getFieldsFromInput modify the data? Fetching the service fields from the database is not necessary, and in some cases may be incorrect anyway. You should check both for the service field in $vars and the package meta fields to determine which value to use.

After checkout, an order is setup in Blesta. However, the service may still be in pending status because it has not yet been paid, approved, or both. Is your order form set to Require Manual Review and Approval of All Orders? If so, the order doesn't get provisioned until you manually approve it from the Orders widget under the [billing] -> [Overview] page. You may also find this information useful about how to create services: http://www.blesta.com/forums/index.php?/topic/4181-how-to-create-packages-no-module-and-put-into-recurring-invoices/?p=31392

Something like this I presume <?php $this->Form->fieldSelect("tlds[]", $this->Html->ifSet($vars->tlds, array()), $tld)); ?>

We really could use more information. This is not descriptive enough for me to offer any specific advice: Can you elaborate?

What version of the SolusVM API are you running, and what do the module logs contain for that request?

Why do you expect the total to be 4 euros? The review page shows a prorated package price (3.73) for the remainder of the term + tax (19%) which equates to 4.4387 euros.

The Blesta Translator has also been updated to include language terms for v3.5.0. It also resolves a couple bugs mentioned here and here.

Service info is not available for the Universal Module because the module doesn't know what fields should be displayed there. You would need to configure this on a per-product basis, which is a task (CORE-710) we have yet to implement.

I'm not sure what data being cached you're referring to. If the staff navigation, simply re-save your staff group settings to reset.