Tyson

It sounds like you're confused about how to create services and how they work in Blesta. I'll start by clarifying what you were asking about earlier: If an invoice is generated for a service, the service will only be made active when the invoice is paid. Once paid, the service will remain active. If the service renews on a recurring basis, an invoice will be created before the service renews. If that new invoice is not paid, the service will eventually be suspended for lack of payment. All services are connected to a module. The module essentially determines the "type" of service. e.g. the cPanel module is used to create cPanel services An invoice line item for a service usually follows the format: Package Name - Service Key (from date - to date). This is set automatically when the invoice is created. If you were just starting out with Blesta and wanted to test creating a service for a client, you might do the following: Determine the type of service you want to create. This would be based on a module, e.g. cPanel, SolusVM, etc. Activate the module and setup credentials for it from [settings] -> [Modules] -> (Manage the module). Create a Package based on the module, which will define any settings for the product and allow you to set pricing. Create a package under [Packages] -> (Create Package). There can be a lot of settings, depending on the module you're using, but at minimum, set a Package Name, select the Module you previously defined, define at least one row of pricing (term, period, price), and assign this package to a Package Group. You can create a package group for the package to be assigned if you do not already have one. Create a client under [Clients] -> (Add Client) to which you will assign a service. Once the client is created, you can view their profile from the [Clients] listing by clicking on the link from their Client ID. Once viewing the client's profile, you can manually create a service for them based on the package you created. In the left sidebar, find "Add Service" under Account Actions. Choose the package you created and continue. You will then be asked for more specific options to set for the service (if the module allows for it), as well as basic options about the Term (and pricing) you want to set for the service. You can also choose whether to allow an invoice to be created, or instead create this service for free. Continue to review the details of the service. Then you can create it. Once the service has been created, it will appear in the Services table of the client's profile page. An invoice may also have been created, if you chose to invoice for the service, in the Invoices table. I know there is a bit of a learning curve with how to go about managing services and how they work, but if the documentation is not enough, feel free to ask more questions.

When is that error shown? When viewing the server actions page, or after performing one? It looks like it may be a module error. You can check the Module Logs under [Tools] -> [Logs], and click a table row for a SolusVM entry to check for errors.

Interesting. Hard to tell what went wrong then, but glad it's working for you now.

Taxes are applied based on your tax rules, and whether they match the client location. The client, package, and invoice line items also need to be set as taxable for the tax to be applied. Depending on exactly what you're trying to do here, you could update the package to make it taxable, ensure the client is not tax exempt, ensure that you have a tax rule setup that applies to their locale, and they should be taxed automatically when the service is added. Alternatively, you can update the invoice that is created when the service is added, and mark each line item as taxable, however, that is a manual process, and the total cost that they agreed to will have changed if it was not already taxable.

You might receive a 500 internal server error if you have a fatal error or syntax error in the code that is unparseable. If it only affects modules, then my guess is one of the modules is causing it. You can remove all of the module directories from /components/models/ and see if the problem goes away. Then add them one-by-one until you discover the module that is causing the problem.

You could use vQmod to modify Blesta without making core changes. In any case, you can update the Emails model (/app/models/emails.php) to set default tags that will apply to all emails sent. A few already exist, so it should be straight-forward for a developer to add others to your installation.

What is the issue exactly with the console for your virtualization type?

Thanks. This issue is resolved in CORE-1592 for the next version of Blesta. It won't fix the fact you have a 'hidden ticket', but it will make it so you cannot split ticket notes by themselves, as that is not the intended behavior. e.g. since a client doesn't see ticket notes, they have nothing to see in regards to that ticket. If you'd like to remove the 'hidden ticket', you will need to either add a reply (not a note) to that ticket--via the database--or convert a note to a reply, then it will be visible from the UI.

The Logicboxes API expects the phone number in international format for contacts. Seven 1's may be included if the phone number is not available in the client's account. The module also does not perform any action when suspending, unsuspending, or cancelling a service.

The email is sent when the action takes place (e.g. when the service is added), and includes the package/service meta fields set for the universal module product. The action itself (add/edit/cancel, etc.) isn't included as an available tag. You can view all available tags using the {% debug %} tag in the template and sending yourself an email by performing one of the actions.

Could you describe what you entered as the domain and TLDs before you clicked "Check Availability"? And how do you have your order form setup? Domain&Other type with Namecheap set as the Domain Package Group? You might receive the error "That domain name is not supported." if you try to check a domain name at a TLD that is not supported on the order form.

I don't think the upgrade will solve the issue, as we didn't update anything recently related to this issue. I tried to duplicate this by unapplying a transaction from a closed invoice, but it did open it again as expected. So I can't think of any reason why that invoice would still have a closed date unless a fatal error occurred at the time you unapplied the transaction. You would have noticed this at the time if you saw a blank page. Updating the invoice via the database to set a NULL date_closed should resolve it. Then you can apply the actual payment to the invoice to close it again.

If that language definition output the anchor as text, then it sounds like it is being output via Html::safe wherever it is displayed. What is the language definition term? Perhaps you may want to create a new definition altogether?

The Import Manager plugin will be updated in v3.5 to support importing Multicraft services using the Multicraft module when performing WHMCS to Blesta migrations. This update is attached to this thread for anyone migrating from WHMCS before v3.5. Download the attached file, multicraft.php, and place it into the following directory of your Blesta installation: /plugins/import_manager/components/migrators/whmcs/5.2/config/ Then follow the import migration steps outlined in the documentation to migrate from WHMCS to Blesta. Note: Not all Multicraft module settings, package settings, and service settings will be imported. Once you have completed the migration, you will need to, at minimum, update the Multicraft module row. You can do so under [settings] -> [Modules] -> (Manage Multicraft) -> (Edit). Make sure to set the Panel API URL. Additionally: The Multicraft package that was created should be updated as well, to set specific options (e.g. "Owner Can Set Name") because many of these settings could not be imported. Only "Player Slots", "Server RAM", and "JAR File" settings will be imported. Each Multicraft service will only have the login username, login password, and server ID imported. The other settings should be updated when managing the service so their values are accurate. However, clients can still perform actions on the server regardless. You may need to reference the actual server settings in Multicraft when updating those settings for the service in Blesta. multicraft.php

Since there's not a way to remove the name server fields just for clients from the interface, you will need to update some code to accomplish this change. Here's what will likely work: Find /components/modules/namecheap/namecheap.php from your Blesta installation. BACKUP this file somewhere Open that file in a text editor and search for: $fields = array_merge(Configure::get("Namecheap.nameserver_fields"), Configure::get("Namecheap.domain_fields")); Replace that line with: $fields = array_merge(Configure::get("Namecheap.domain_fields")); Save the change and overwrite the file at /components/modules/namecheap/namecheap.php Now when a client goes to order a domain, they should not have any option to set name servers. However, you can still set them yourself when managing the service from the admin interface, or updating them on the package. The name servers you have set on the package will be used for services by default.

Could you provide steps for us to duplicate this problem?

CORE-1586 is a different issue. A zero-due order asking for payment will be updated as part of CORE-1489. If you're running v3.3.2+, invoices with zero-due are closed automatically on creation.

The links look fine to me. Have you attempted to reset your password so you can check the email you receive? If so, does the link work? If the link is fine, your customer probably clicked an old reset password link. The links are only valid for a short time (e.g. 4 hours). If the link is no longer valid when they visit it, they would be redirected to the login page. In that case, they should enter their email address on the reset password page to receive another email, and then check their email within those 4 hours.

Which module are you using? Namecheap? I think that module always shows five name server fields, but I think only two are necessary when provisioning the service. Others can be added/changed by the client during or after order. In some cases, they may want to add additional name servers. Curious why you'd like to remove those extra fields?

Who are you looking to CC/BCC in a ticket? Would you CC/BCC a particular ticket reply, or CC/BCC them for all ticket replies? Would they be included for informational purposes, or would they have the option of responding to the ticket via email (this would be more complicated)? The system already includes client contacts in CC automatically if they are involved in opening/replying to the ticket.

So customers could choose the JAR directory from the available options: "Daemon Jar Directory" (daemon), "Server JAR Directory" (server), "Server Base Directory" (server_base)? Or can you set a custom directory name? The Multicraft API documentation isn't clear on its customizability. How do you manage custom JAR access for customers now? Do you check each order manually and change the JAR directory so they can upload their own when they have "Custom JAR Access" checked on their order? The "order form options" (i.e. service options and config options) are shown under the module options (e.g. under the "Multicraft Options" heading) in the admin interface when you go to add the service. Additional addon services are listed below those service options in the admin interface, selectable once you click the "Addons" link. The "Addons" link will only appear if the service can have addons assigned to it, which are made available via Package Groups. That might sound confusing, but the process is fairly simple once you get the hang of it: e.g. Create a package for the Multicraft service (you probably already have). Assign it to a package group. I'll refer to this package group as "Multicraft PG". Create a new package group for addons. I'll refer to this package group as "MC Addons". Select the type "Add-on". Assign the "Multicraft PG" package group to the list of parent groups. Create a package for an add-on service. Assign it to the "MC Addons" package group. Now when creating a Multicraft service, the "MC Addons" package group will be available, and the service you assigned to that group can be selected for order.

How do you have the product setup? Are the name servers setup as a package option, or is the field included by the module? If the field is included by the module, then it depends on how the module is constructed and whether it allows for the name servers to be removed. If the field is a package option, it cannot currently be removed from display. In the next minor release of Blesta (v3.5), package options will have a setting that will allow them to not be selected by clients when adding or editing a service, which may be what you're looking for.

Chances are the {password_reset_url} tag in the "Password Reset" email template (found under [settings] -> -> -> (edit Password Reset)) is including a malformed or incorrect URL. It might be that your company hostname is incorrect. You can find and update the hostname under [settings] -> [system] -> [Companies] -> (edit). You could try to have a password reset email sent to you for your staff account to check if the link in that email is incorrect as well. It would be best to see what the URL of the link in the email is to determine the problem.

Attachments are generated and included on the fly, and they might vary based on other settings and filtering options, so the email template really doesn't know what actual attachments will be included with it until the email is sent. We could probably give a vague general description that "This email template may include invoice attachment PDFs", but anything beyond that would be speculation. And since plugins can set email templates and send attachments if they'd like, they may choose not to include any description about the possible attachments. By then, a description about possible email template attachments becomes uninformative, as you still wouldn't really know whether the template sends attachments are what they are.

No ETA yet on the affiliate system, although you can follow its progress from this task. I'm curious why you would want to make the JAR directory an option for orders. It seems to me that customers may not understand why they're being asked to specify where the JAR Directory is for their JAR file when ordering. Could you elaborate on how you plan to use the JAR Directory as an option for orders? Would you show the option similar to how it is displayed when creating a package in Blesta?