Tyson

Make sure you are passing in all of the required parameters to Invoices::edit(). Also, line items that do not contain 'amount' or 'description' are set to be deleted.

Tax can be enabled/disabled per client, invoice line item, or package, so tax does not always necessarily encompass the entire invoice subtotal.

Surely they realize how difficult (if not impossible) it is to prove that something didn't happen. It is much easier to prove what has happened, and in your case, I think that would be for them to prove that after you made a payment to your account, that they posted the data to the notification URL (notify_url field) that was set. The notify URL is the URL to your Blesta installation followed by the callback URL, company ID, and payment gateway. By default, this is http://yourdomain.com/callback/gw/paypal_payments_standard/ If the sandbox works fine, then I suspect that there is some configuration issue different between your live and sandbox accounts which leads to PayPal not posting data back to Blesta, although nothing else comes to mind that hasn't already been mentioned.

You said you would like to have the customer click a link to signup and make a purchase, which is what happens when you set your General order form as the default order form as I described. Based on how I understand your explanation, this is exactly what you want. You'll need to describe your issue more clearly than "when the order link is clicked does not work". We cannot provide support if we do not understand the problem. What happens when you click the order link? Are you redirected back to the portal? If so, then double-check your default order form.

Attached is the TheSSLStore module for Blesta. Special thanks to Alex at Full Ambit Networks for creating the module and giving us rights to it. For now, we'll be considering it a beta module, and would appreciate any feedback you can provide. You can upload the contents of the attached zip to your Blesta installation directory, and then head into Blesta's admin interface to install the module under [settings] -> [Modules] -> [Available]. thesslstore.zip

Attached is the GoGetSSL module for Blesta. Special thanks to Alex at Full Ambit Networks for creating the module and giving us rights to it. For now, we'll be considering it a beta module, and would appreciate any feedback you can provide. You can upload the contents of the attached zip to your Blesta installation directory, and then head into Blesta's admin interface to install the module under [settings] -> [Modules] -> [Available]. gogetssl.zip

Your Client Registration order form only handles client registration, as its name suggests. It does not forward clients to a separate order form upon completion. But it sounds like what you want to do is remove the Client Registration order form, and set the General order form (with your products) as the default order form. When clients try to order products from this order form, they will be presented with an option to either login or create an account.

When you create a custom client field, you select the client group it should apply to. Since you only have one, that's the only option. If the responses are in the database, then what do you mean when you say: What info are you expecting? You can view the custom fields when you edit a client.

You'll need to give us some more information. Custom fields are set per client group, and may or may not be required, per your settings. If your clients are in a different client group than your custom field is setup for, or if those custom fields are not required to be entered, then you may not get any custom field info from clients.

Yes, you can set a staff signature that appears when replying to tickets in v3.1. This is interesting, but I'm not sure how many customers would actually use it. But since Blesta already has record of the more pertinent information like company name or a list of phone numbers, this could be automatically populated in the ticket.

I can see how it would appear easier for the Universal Module to send emails, as per your example, but it would increase the complexity of the module beyond its scope, and would interfere with how the rest of the system handles emails and events already. We have to keep functionality abstracted as much as possible per proper OOP design, or we would end up with a huge mess.

Most emails cannot be regenerated, but you can resend them if you have done so already. Check the client's mail log for the email and click to resend it.

You may want to take a look at what is included in /vendors/phpseclib/, but I presume you'd like to make use of SSH2 in /vendors/phpseclib/Net/. The Security component wraps phpseclib, so you can simply use that to instantiate an SSH2 object: Loader::loadComponents($this, array("Security")); $this->Net_SSH = $this->Security->create("Net", "SSH2"); ...

Based on the lack of output in the module log, Blesta likely either did not receive a response from cPanel or does not understand it. Does the domain actually get setup in cPanel?

This is intended. You can't have an inclusive amount discount. Attempting one would create an error and not apply it. I'm surprised you were able to even create such a coupon, but that would be the only bug related to this. The OP's original issue was already resolved. Anything else should be described in its own thread.

Not yet, no.

Non-merchant gateway payment requests are not logged until a response is received from the gateway since the user initiates the payment request in their browser. PayPal needs to send information regarding a payment to Blesta first, and then Blesta will ask PayPal to verify that payment afterward. It sounds like Blesta never gets notified of a payment.

Update /language/en_us/client_main.php. Be sure to maintain the syntax and format of variable replacements. Also note that since this is a core language file, subsequent versions of Blesta will overwrite it, so you will need to save and merge your custom changes back in.

They could potentially edit the form attached to the PayPal Pay button to change the amount, or other values. Similarly, someone could construct such a form elsewhere and submit payment to you in any amount to pay for invoices. What Cody is saying is that there is no guarantee that you will only be paid the expected invoice amount when you pay with a non-merchant gateway because such a requirement is unenforceable.

Fantastic. Closing this thread as fixed in CORE-921 for v3.0.7.

I'm not sure what you're asking. All of the details (package, module, service fields) related to a service is available in the welcome email that is sent out when the service is provisioned.

Basically, that's what happened. When you paste HTML into the WYSIWYG, HTML tags can interweave with tags you pasted, so you might end up with something like {<span>package.name</}span> or such.

This is probably due to the output buffer not closing after downloading the CSV, but we're not able to duplicate this issue. However, the fix should be simple. If you're comfortable updating a file, I'd appreciate your feedback on whether this fixes the problem for you. Update /app/models/report_manager.php (line 231): // Download from temp file $this->Download->downloadFile($path_to_file, $new_file_name); @unlink($path_to_file); and change it to: // Download from temp file $this->Download->downloadFile($path_to_file, $new_file_name); @unlink($path_to_file); exit();

You can delete an addon company in upcoming v3.1.

Do you have a "/" character inside of braces? e.g.: {/} It could be in the HTML or text version of the email, and might even be in an HTML link, if you're using tags there.