Tyson

The docs list each email template, which includes tags available to each of them.

That's correct. The gateway doesn't set errors to the view. It can set errors, but it is the caller that sets the view and determines whether to set any of the gateway's errors to it, which would be the case here.

I think something like this would work (untested): public function success(...) { ... $this->Input->setErrors(array( 'error' => array( 'type' => 'Error!' ) )); ... }

If your gateway supports a 'cancel URL', determine the cases where the gateway would redirect the customer to it. You can set errors on your gateway's success() method in those cases. The only page that is currently used for customers returning from making a payment is the /client/pay/received/ page. So if you redirect there and set an error message and an empty return array on your success() method, then the client will see an error message. It may not be ideal in some cases, but it is an alternative to the normal success page.

You would have to show more of your code. I've never looked at the Support Manager PRO plugin, but your example URL suggests that $id = $this->get[0]; // 1

There would likely be a feature to limit (or not) coupons however you please (e.g. by date/uses), as the OP suggests, once we have refactored the coupon system.

A contact needs to have a name, even if it's blank, so I don't see any issue with having a blank name. You just won't see it where it is used and might end up with areas where it may say something like "Hello ,". The system will prevent the entry of a blank name, though, so you would need to work around that.

Plugins define navigation language during installation, and they get stored to the `plugin_actions` table of the database. The names are currently stored is translated text, so the text will only display in the language the plugin was installed in.

Make sure the Provision Paid Pending Services cron task is enabled under [settings] -> [Automation] and that it doesn't have a spinning icon next to it indicating that the task has stalled. Check that the invoice the service belongs to is fully paid and closed. Check the module logs under [Tools] to see if any recent log entries are for SolusVM. Click the table row of the log to show raw information, which may contain an error if it failed to provision the service. To attempt to activate the service manually, view the pending service in Blesta (either under the client profile's service widget, or under [billing] -> [services] -> (Pending). Click to Manage the service and then click the Activate button to attempt to provision it manually. If you receive an error, check the module logs again, as it may contain more error information to help debug the problem.

The SolusVM module will include ISOs along with templates in the 3.5.1 patch.

A task hasn't been created to address the coupon/setup fee issue specifically. The new pricing structure I was referring to is back-end logic for handling all pricing (package, discounts, taxes) calculations, which is not yet fully integrated into all other areas of the system where pricing is determined. An epic exists for that integration in CORE-1684.

Attaching additional modules to tabs sounds like a nice addition, but I can see limitations in it. We can't assume a secondary module only needs to have its own tab where it can make calls from the tab (or something of that nature). The next step after that is a need for multiple tabs for a single secondary module, then service field manipulation, and so on. Ideally, we'd like it to be as open as possible, but like I said, it's something we need to discuss more.

I can see the inconvenience. The alternative would be to change it to something else with Use Module unchecked, then change it back with Use Module checked, which most people probably wouldn't figure out.

In the past, we have received numerous complaints about plain-text password fields. While I would normally agree a password field is not really necessary in the back-end of the system for something like you described as it can be just as easy to look at someone type on their keyboard to determine their password, many seem to disagree, needing the password to be a password field.

The controller method should return boolean false. Record has not been instantiated in Main. The Record object is only available automatically to models that extend AppModel. If you want to run a query from your controller, you should call a model that does it instead. Assuming "main" is your controller and "activity" is your method, then $month = $this->get[0]; // month $number = $this->get[1]; // 7

We've had a password generator on our radar for a while (CORE-552), but more demanding tasks have been taking precedence over it. Ideally, a generator will exist that lets you configure the characters for the password, and optionally lets you view the password before saving it.

The "Type not found" error looks to be caused by the "listtemplates" call because it does not have a VPS type set. Was the service created from Blesta using the module to provision it? It looks like it is missing some data, particularly a value for the "solusvm_type" service field. That field is only used internally, so it is not available in the UI. You can check all of the service fields with the following query: SELECT * FROM `service_fields` WHERE `service_id` = '1'; Just replace the service ID (1) with the ID of your service. The "solusvm_type" should have a `value` of "xen", "xen hvm", "kvm", or "openvz". If it is missing, set it to the appropriate value.

Good to hear you were able to find a work-around. We don't release information, like an ER diagram, for commercial/IP reasons.

An if/else might work more succinctly: {% if contact.first_name %} Sehr geehrte/r {contact.first_name} {contact.last_name}, {% else %} Sehr geehrte Damen und Herren, {% endif %}

It sounds like KVM and HVM templates should also show ISOs, correct? Any thoughts from those of you that use KVM or HVM?

Blesta wouldn't currently support a feature that allows you to invoice a service for the next term at the click of a button unless you made several updates to Blesta to ignore the current behavior of invoicing a certain number of days before renewal, and you created the invoice line items for the service yourself. You would need to look into, at least, Invoices::createFromServices, Invoices::getallRenewingRecurring, Services::getAllRenewing, and probably some others methods as well.

The service didn't create an invoice when you added the service? Are you sure you didn't select the "Do Not Invoice" option when you created it? Is the service free? If it doesn't cost anything, an invoice could have been created and closed immediately because nothing is due. Or are you saying that you expect an invoice to be created for the service renewal?

Using 2+ modules on a single service adds an additional layer of complexity to the module system for services and invoices which poses several design and backward compatibility issues. It's something we will need to discuss internally more before we would have anything more specific to share about it.

What updates are you looking for specifically? Are you waiting on something in particular?

CORE-1736 for stripping "www." from SolusVM. The original FQDN issue is resolved, so I'll close this thread as completed.