Tyson

What do you mean 'no pricing is in use on the packages'? Every package should have at least one term/period/price/currency set. The error the OP mentioned is caused by failing to submit a valid currency when adding/editing a package. You could view the source of the page and search for "pricing[currency][]", and make sure that there are currency options set as valid 3-character codes. The system pulls these from the `currencies` table in the database. You can update your currencies under [settings] -> [Company] -> [Currencies] -> [Active Currencies]. Make sure the currency you're trying to set on the package is available in that list.

Glad to hear you were able to figure it out. As a general solution, anyone encountering this issue should make sure that each *.php file does not start or end with white-space.

Could you be more specific to your use of the config option? Module log input/output? You added the fields as described in the config options overview for Multicraft?

Proper use of WHERE IN using the Record component: $this->Record->select("service_fields.*")->from("service_fields")-> innerJoin("services", "service_fields.service_id", "=", "services.id", false)-> where("service_fields.key", "=", "hostname")-> where("service_fields.value", "=", $hostname)-> where("service_fields.status", "in", array("active", "suspended", "in_review"));

The module's addService method, as you probably discovered, is called before a service is created in Blesta (Services::add), or when activating an existing pending service (Services::edit), so it may not always be known. This extends and overrides the Module abstract class used by all modules, and was not designed at that time with a need to support passing the service on add. If the main reason you have needed to at this time was to perform a unique validation check on some service fields, then it may be more of a special case. But this is something we would have to discuss internally. On a side note, I see your query passes variables directly to Record::query. You should revise this, as it is currently vulnerable to SQL injection.

"...rendering content without a table box"? How do you mean? Perhaps you are missing a container div? Take a look at the Support Manager plugin, ./plugins/support_manager/views/default/client_tickets.pdt. Notice that $render_section is used to also set a container div. Is that missing from your template?

I assume you've setup a widget on the Client Main page (ticket widget?), and all of those widgets are loaded from that page via AJAX. Other locations where the plugin is not directly accessed, depending on events, are loaded in the same way.

Each module may implement specific methods extending the Module class, and Blesta will call them after specific actions occur in the system. The module may also add additional methods to handle further support functionality custom to the module. Most of those you mentioned are defined in the module methods docs.

I agree it looks like an output buffering issue that is handled differently between those versions of Ubuntu. However, I don't see anything obvious in Blesta that might cause two lines to be output before the logo image. Did you try my alternate suggestion to resolve the TCPDF error? Does that resolve the issue as well?

The AJAX templates have a different flow through the order process than the other templates since they handle everything from, essentially, one page. This design doesn't allow for universal support for that feature across all templates. Not every template can, or should, support all features from other templates. For instance, neither the Wizard nor AJAX templates support Client Registration order types.

Namecheap is a module, so it would appear under the Module logs. Information is only logged for request/response data during communication between Blesta and Namecheap. If you're not using the module to provision a service, for instance, then no log data would be created.

What is at the end of the controller that renders your page? It sounds like you're submitting an ajax request for the widget and not specifying 'whole_widget', or you're viewing paginated or sorted results, and each of those actions only returns widget content to display rather than the whole widget again.

These tags are available. There is no {% elseif %} tag, so that wouldn't be a valid statement anyway.

You can set data to the structure with $this->structure->set("var", "value"); as long as your plugin controller is extending AppController. Plugins are loaded after the client_main template has been displayed, so you wouldn't be able to set data there.

What is the path to the logo set to? View the source for that page and search for "inv_logo". It should be set to something like /path/to/blesta/uploads/invoices/inv_logo What response does the browser give when it attempts to fetch the logo? You can check this in your browser with developer tools, or in the web server logs. For the TCPDF error, can you remove the code changes you made to fix that issue, and instead try the following: Open /vendors/tcpdf/tcpdf.pdp At the bottom of the file there should be the characters: ?> Ensure "?>" are the last two characters of the file. If there is any white-space or new lines after those two characters, remove them. Save the file Try downloading an invoice from Blesta again

The AJAX order templates are not designed to support applying credits. If you want clients to be able to pay via credits on their account, you should use the Standard or Wizard templates instead.

That error appears to be unrelated to Blesta and the SolusVM module. It sounds like maybe some non-Blesta files were lost when you migrated to another server. I'd expect more info should be available in the server logs regarding the 500 error, but that is typically caused by a server misconfiguration of some kind. Since you still receive the 403 error when editing a package versus adding one, I think this is an issue with mod_security on the server. A mod_security rule may be defined that ends up blocking access to module options when editing a package in Blesta. If you have mod_security enabled, try disabling it to check whether module options load when editing a package. If so, then some mod_security rule is causing the issue.

I think you were right before about the run date being incorrect for Services::getAllRenewablePaid. I think what happened is that the run date (already in UTC) is converted to UTC while it was assuming it was not already in UTC. This advanced the date incorrectly such that each time the cron ran to renew services, your service was erroneously retrieved as renewable, and thus, renewed. This issue is fixed for v3.3.2 as apart of CORE-1500.

I'm going to close this as fixed in CORE-1390. You can create a new thread if you encounter this issue with v3.3.2+.

I'm not aware of any pending tasks that would add logging of actions performed by clients. Invoice reminders may still be sent based on your payment due notices' settings if the invoice is not paid. Cancelling a service won't suddenly void an open invoice, so they'd still be on the hook for whatever is still due.

You could only test adding/editing a service to see if the rules are validating by checking whether an error is generated. Is your Input Rule set for the Package or Service fields? If you create a product with the following service field input rule: {"hostname":{ "valid":{ "rule":"isEmpty", "negate":true, "message":"Hostname must not be empty" } }} ..and you have a "hostname" service field set, you can check whether the rule validates by adding a service. Go to add a service from the admin interface, select this product, and don't set a value for the hostname. When you click to Continue, an error should be shown saying "Hostname must not be empty". That will tell you whether the rules are validating. I tested this myself and find it to be working properly.

Not sure why I didn't see this sooner. You probably already discovered the issue, but when specifying parameters (the regex) to a callback ("matches"), an array format is expected. JSON arrays use brackets rather than braces, so the fix would be to simply change the rule from: "rule": {"matches", "/^[\w.-]+\.midomain\.(com|it)$/"}, to "rule": ["matches", "/^[\w.-]+\.midomain\.(com|it)$/"],

Yes, we'd like to hear about potential XSS vulnerabilities. As with any automated software, it may have generated false positives, so we have to review what you've found for confirmation. You can report potential security issues you've found to security -at- blesta.com. I'm not sure to which ticket you're referring, but I don't see any tickets waiting our response in the last week. Weekends can take longer for a response though, since we're not often available then.

The client ID is available to some of the module methods as apart of input or service data. You should use that rather than the session, as there may not be any session user data available when the module is called automatically or by an admin.

I would recommend starting a trial, looking it over to see whether it will work for you, and then attempting a data import. The import can be a time-consuming process, and you may need to fix a few data anomalies and try the importer all over again if you run into issues. I suggest making a database backup after you've installed Blesta, but before you've attempted an import, so you can restore to a clean database if you run into problems.