Tyson

The most common reason for a module to not appear is if it does not follow the file structure pattern, particularly the file name of the module's directory and the main module file (they should match). The second reason is if the file name does not correspond directly to the class name in camel-case.

Thanks. I don't see any missing </html> tag, though. I think the problem is as you described--the Widget object is not closed, so it does not end a couple div tags. CORE-2011

Every invoice must have at least one transaction associated with it which sums up to the full amount of the invoice in order for it to be paid.

The exchange rate of your company's default currency should be 1.0000. The exchange rate of every other currency should differ relative to that currency. In Licensecart's screenshot, 1.00 USD = 0.975 EUR.

Thanks, that does look strange. Added as CORE-2009.

I'm curious to know why you have database upgrades being processed when re-saving a package rather than upgrading the module?

FYI, the task to update the Multicraft module to support v2 is CORE-2008.

Did it work before? I'm not aware of an issue with dedicated IP's not working.

Many of those field parameters are set by whatever module the package belongs to. If you're looking to update them all in a general case, then you'll have to update that template directly (i.e. make a core change). Alternatively, you could create your own order template by copying /plugins/order/views/templates/ajax/ into a new directory, e.g. /plugins/order/views/templates/custom_ajax/. Then update config.json to rename it accordingly. Since you now have a custom template, you can update the config_packageoptions.pdt template file in there, and then update your order forms in Blesta to use this new template.

I assume you mean the `clients`.`id_value` field. This cannot be changed. It is set automatically based on your settings in Blesta with respect to other existing clients. There is no 'isDomain' validation rule, however, you can create your own using the 'matches' rule which validates according to your defined regular expression. You cannot write your own callback function to handle the validation from the UniversalModule (unless you actually update core code), so I don't think that would be the best route. Here's an example: {"service_label":{ "valid":{ "rule":["matches", "/^[0-9]{1}$/"], "message":"Label must be an integer" } }} What do you mean? The API does not accept error messages, however, it makes error messages available to you if there are any. You can do anything with them. Input field cannot set a description. How/where would such a description appear in the UI? Input fields could have tooltips associated with them, but the Universal Module does not currently support tooltips.

Likely multiple files, as invoices can be constructed and sent in multiple places. The invoice delivery component is one place that would need to be updated.

It looks like you should be able to set variables to the structure from the Appcontroller.structure event, although I neither wrote the event nor tested this behavior. What are you setting for your event exactly?

Bug in Blesta or Multicraft? If you're using the current module with their new API (not in legacy API mode) then there could be API issues. You will need to continue using the legacy API.

Which company name? The client company name? The company name they're logged into? For the latter, you could update the `companies` table to store a language definition representing the name of the company rather than the name itself? Then place that language definition in the global language files for each language.

This would require you to define a client setting for the invoice template, and then send invoices using this template. The latter half would require core updates to use the client setting rather than the company setting, which is not supported.

Have you tried setting the event to return an array of key/value pairs, where the key is the variable name, and the value is the variable's value?

The variable you set is not available on pages where the plugin is not loaded to call one of its controller actions. Your plugin is simply not called on most pages, so it never sets the variable to the structure. Have you tried tying into the Appcontroller.structure event?

Can you give an example of an ID that you would like to change it to? If you're only looking to show a unique integer for each package, then updating the `packages`.`id_value` would suffice. Simply update the `id_value` for 6 to 7, and one of the two 5's to 6, resulting in, for example: 5 | Domain Registration (.com) 6 | Skilled 7 | Domain Registration (.net) And of course, always backup the database, or at least this table, before making manual changes to it.

Yes. What have you done? Your plugin controller: class MyController extends MyPluginController { public function preAction() { parent::preAction(); $this->structure->set('my_var', 'my_value'); ... } ... } structure.pdt: echo $this->Html->ifSet($my_var); The variable will only be displayed in the structure if your plugin controller has been loaded.

Can you provide any information on version 2 of the Multicraft API? What's new?

What makes you think the timezone is incorrect, exactly? Any other information you can provide from How to Report a Bug? What is the date stored in the database under `log_users`.`date_updated`? You can run this query on the database to find the records ordered by the most recent: SELECT * FROM `log_users` ORDER BY `date_updated` DESC;

Interesting to see a duplicate package ID. I wonder if that is an anomaly with the data being imported. The package IDs shown in your screenshot are constructed from data saved in the database. If you're familiar with databases, or have access to a database UI utility like phpmyadmin, you can view these records from the `packages` table. The problem is that one of the `id_value`'s is duplicated. Having duplicate package IDs is normal if the packages are from different companies, but clearly that is not the case here. However, having a duplicate package ID will not negatively impact how the system operates, as that ID is for display purposes only.

I can't attest to your situation, but I can tell you how mine is setup: - Root user in Multicraft has an API key set. Take the root username and this API key and set them in Blesta. - The URL to the Multicraft API file is very similar to where you login (by default), e.g. https://domain.com/multicraft/api.php - set this in Multicraft as the API URL. The Panel URL is the same (by default), minus "api.php", e.g. https://domain.com/multicraft/

What is "MulticraftAPI.php"? Blesta doesn't come with this file, so there is no reason you should be adding it to your Blesta installation. The API URL the module asks for is on the Multicraft server. It sounds like you have that setup correctly because you've stated that you receive a response of "No API user supplied". You would not have received any response if this were incorrect. The error indicates the "Username" you have set in Blesta is likely missing, as it is not included in the API request to Multicraft, hence the "No API user supplied" error.

I'm not familiar with Multicraft's scheduling options to deduce whether it is possible to shutdown the server if no one is online. Similarly for running the server for 1 hour instead of all day. The Multicraft module for Blesta, though, does not have any options to create or modify schedules. For cron, yes, you can have it run automatically. Setting one up through a control panel like cPanel can make this an easy process. The docs describes this briefly, and help can be found on the forums if you run into issues.