Tyson

This will be in v3.2.1

Does this path exist, and is it writable? /home/user/blesta/uploads/1/support_manager_files/

PayPal explicitly prohibits you from charging the customer a surcharge to cover the PayPal fees. You agreed not to impose such a surcharge when you signed up for PayPal. 4.6 No Surcharges. You agree that you will not impose a surcharge or any other fee for accepting PayPal as a payment method. You may charge a handling fee in connection with the sale of goods or services as long as the handling fee does not operate as a surcharge and is not higher than the handling fee you charge for non-PayPal transactions. Any charges that you make the customer pay has to be on the invoice and shown in a transaction, following the law in your region with respect to this. Blesta doesn't create invoices in one amount, accept payment in another, and then hide the overages.

Have you tried the link that was sent to the client in that notice? If it doesn't take them to the pay page, there may be an issue with the company hostname, encryption key (unlikely), or routing customization that causes Blesta to redirect somewhere else or otherwise deem the payment link invalid. Make sure you're using the {payment_url} tag. The notice emails don't generate and send off PDF invoice attachments to the email. That might be a nice feature request though. Since the notice email supports the {invoice} that is late, you should be able to reference the amount due on the invoice with the {invoice.due} tag. Of course, you'll want it to be formatted nicely in the currency, so you can set a filter as I described here. e.g. Amount due: {invoice.due | currency_format invoice.currency} The output in the email would then be something like: Amount due: $56.25

Example of setting/displaying variables: /order/controllers/checkout.php public function complete() { ... $account = array('user' => "username", 'email' => "me@mydomain.com"); $this->set("account", $account); } /order/views/templates/{type}/checkout_complete.pdt <div class="col-md-12"> ... Username: <?php $this->Html->_($account['user']);?><br /> Email: <?php $this->Html->_($account['email']);?> <?php // Auto-populate a form field $this->Form->create(); $this->Form->fieldText("username", $this->Html->ifSet($account['user']), array('id' => "username")); $this->Form->fieldText("email", $this->Html->ifSet($account['email']), array('id' => "email")); $this->Form->end(); ?> </div>

Setting manual review and approval of orders applies to all packages assigned to that particular order form. If you want some of those packages to be manually reviewed while others are not, then you would need to setup a second order form that doesn't require manual review.

Go to [settings] -> [Company] -> [Emails] -> [Mail Settings] -- the link in the left sidebar below the Email Templates.

I think that data only updates when Use Module is checked. It probably should do it either way, though. Daniel probably has it right with your Permission Denied error. You should check your account permissions to ensure your user is granted the "modifyacct" and "passwd" API actions if it is more than a login credentials issue.

Security through obscurity is generally a bad idea. You can't assume because a user has a random username that they are any more secure than someone that uses the first 8 characters of their domain name. As the wiki article states, "It is analogous to a homeowner leaving the rear door open, because it cannot be seen by a would-be burglar." Beef up the requirements for your customers' passwords. I think cPanel requires at least an 8-character password, which is too short. If you let Blesta generate one, it'll be 10-14 characters. Of course, users can change it themselves in their cPanel account, but it's ultimately their choice on how secure they want to be with their logins. You can also educate them on this importance to deter them from bad security practices, kind of the give-a-man-a-fish/teach-a-man-to-fish argument.

This has been brought up a few times before, but it is not a bug. The SolusVM API does not support fetching the friendly name of the templates. I'd suggest asking them to update their API to support it.

This is the actual fix.

Thanks, this has been resolved in CORE-1298 for v3.2.1.

No, it doesn't automatically set your card for auto debit on order. You might already have an account setup for auto debit, and that account may be associated with a different gateway in a different currency than you're using at checkout, and the auto debit account may be stored offsite. Maybe the client wants to keep that other account for auto debit.

A few things need to be setup to have auto debit work: Auto Debit needs to be enabled for the client (it is by default, and is togglable from the client profile page) The client must have a Payment Account (under Actions on client profile page -> Payment Accounts) One of the client's Payment Accounts must be selected for use when auto debiting (use the radio button next to a payment account to select it, then click to Use for Auto Debit. The client can do this as well) There should be no Passphrase set under [settings] -> [Company] -> [General] -> [Encryption]. The Auto Debit task must be Enabled under [settings] -> [Company] -> [Automation]. You need to have setup a cron job on your server for use with Blesta Auto Debit will run following the settings under [settings] -> [Company] -> [billing/Payment] -> [invoice and Charge Options]. If the client group overrides the company settings, then you can edit the client group to set them instead.

This issue has been fixed in the GoGetSSL and TheSSLStore modules for v3.2.1.

Congrats! That looks pretty good. You'll be a little disappointed to hear this, but your SSL cert order form doesn't work properly. When you enter your domain, the Approver Emails don't get populated. Someone brought this up a few days ago, and I fixed it earlier today for both GoGetSSL and TheSSLStore. Blesta v3.2.1 will contain the fixes. In the interim, you can work around it by not using the AJAX Boxes/Wizard templates for that order form.

You mentioned it has worked before. What since has changed? It sounds like a web server misconfiguration. Blesta doesn't link to pages that don't exist (unless you change the routes), and if you didn't have permission to access those pages, they would show an error stating that fact rather than 404.

If you encounter an issue with the module, you can open a bug report where we can discuss it. If you do not set a daemon ID, nor a dedicated IP, then Multicraft determines how to setup the server, sets the IP, etc., and notifies Blesta of that information. There are some Multicraft configuration files that you may need to update if you're having a problem with starting a server. There may also be an error in the Module Log that can shed some light on possible API-related issues.

Have you modified Blesta's routes, or setup different htaccess redirects?

I only experience this with the AJAX order form templates, but I'll take a look at it in CORE-1283.

The mail log shows the text version of the email, and will convert the HTML version of the email to text otherwise. I don't experience this issue either way, but you may want to check that your text version is correct if you haven't already. If you have custom styles like word-spacing:-3px; then that could lead to the appearance of no spaces.

The error may be correct, in that a client already exists in Plesk by that name. If you are trying to add a Plesk service into Blesta that already exists in Plesk, then uncheck "Use Module" when adding/editing the service.

What does the module log contain?

It is the intended behavior for attachments to not be sent out via email, and instead users should login to view the ticket and download them. A new email template tag may be useful to determine whether there are any attachments, and the template can be updated to indicate that the user should view the ticket in the UI to download the attachments. CORE-1274

Steps to duplicate?