Tyson

It sounds something is causing the cron to error out. You should enable error reporting in Blesta and run the cron manually. Note that cron tasks run at specific times/intervals. If a task fails (shows the spinning icon), it may wait 6 hours to try running again. If you're familiar with databases/SQL, you can update the `log_cron` table and delete all records that have a NULL `end_date`. You should be very careful with deleting the `log_cron` records if you are using Blesta in a live environment. Deleting the records entirely lets Blesta know that those tasks were not run, and so it will attempt to run those tasks again when the cron runs next. It would be best to immediately run the cron manually (don't let it run automatically) at this point so that you can view the output of each task as it is run. With error reporting enabled, any errors encountered should appear on the [system] -> [Automation] page. Once you know what the errors are, we can determine the issue and offer a remedy. If you're not familiar with databases/SQL, then you can disable the cron from running automatically instead. Then wait a while (wouldn't need to be more than 6 hours) so that you can run the cron manually. All of the problematic tasks would run, and any errors encountered will be displayed from the [system] -> [Automation] page.

I wouldn't call this a bug since that was the intended character limit for that field, but perhaps it needs to be increased. Usually for something that long it may be better to truncate (or use an acronym for) the company name. How many characters are in that client's company name?

Languages follow the ISO standards for country and language codes, and are formatted in Blesta as ISO639-1_ISO3166-1, e.g. "en_us", "en_gb", "fr_fr", etc. Other languages translated by the community are available from the translator. There are several directories of language definitions in Blesta, including the core files, plugins, modules, gateways, components, helpers, etc. Creating them manually can be a pain. If you download one of the translations from the Translator you can get an idea of all of the directories and files involved. More info on translating Blesta is described in the documentation.

All of the available tags are described in the documentation. You can generally find documentation on available tags by looking for the specific plugin the email template is created from. In this case, the Support Manager. The tag you're looking for is {ticket.summary}.

It might be useful for potential developers to know which payment gateway and registrar you intend to integrate Blesta with.

As far as the Support Manager is concerned, a ticket is created independently from any note or reply text you add to it, so it would require additional logic to determine which reply was indeed created when the ticket itself was created (i.e. which reply is indeed the first)--if any reply was created at all. I can see how it might be useful to show "New Ticket" as the subject rather than "Update to Ticket", but I think that is a relatively minor issue not warranting a separate email template by itself. What you could do is update the Ticket Updated email template subject line to cover both cases of New and Updated tickets. If you edit that email template you can change the subject line to: {% if ticket.reply_date_added == ticket.date_added %}New{% else %}Update to{% endif %} Ticket {ticket_hash_code} New tickets will then say "New Ticket" in the email subject, and updated tickets will continue to say "Update to Ticket". To be more technical, this will evaluate that the ticket reply (the text you wrote in the ticket) was created at the same time that the ticket itself was created. In that case, it will show "New Ticket" as the subject. However, because the ticket and its reply are created independently of each other, it is possible that they may be created at a different second, causing some new tickets to continue to use the subject "Update to Ticket" instead. That is likely a rare occurrence.

The email template conditional I mentioned didn't work for you, or setting the IP for Multicraft (from the documentation) didn't work? If the former, make sure you enter it in the Welcome Email for your Multicraft Package.

I think that title was given to those that helped test Blesta prior to the v3.0.0 beta.

It sounds like you may need to update your Multicraft configuration file to set the server's IP address as described in the documentation. As for the email template tags, a username/password is only available for the first service added for a client. If a Multicraft server is added to a client that already has a Multicraft server, then an account already exists for them in Multicraft, and that account is re-used. Because it is re-used, nothing is stored (nor available) for their username/password via those email tags. In this case, it may be better to set a conditional in the email template to denote whether they should login with existing account details, or with those available. e.g. {% if service.multicraft_login_username %} Login with Username: {service.multicraft_login_username} Password: {service.multicraft_login_password} {% else %} Login using your existing Multicraft account credentials. {% endif %}

Replying to a ticket always sends the Ticket Updated email template. The email is sent once a reply has been made, as opposed to a note or log entry on the ticket.

We don't currently have that feature scheduled, so I couldn't say when the Namecheap module will support SSL certs. All I can say for certain is that it won't be in v3.5.

It looks like this is a bug because the package group order should not change. I've created a task (CORE-1618) for us to look into it further.

The javascript you included above is for fetching and displaying package options as form fields. There's really nothing you can do with that to aid in creating a new column for service renewal price under the Services table. If you need the combined pricing of the service and configurable options, then you would need to update the controller for that view to fetch and include this information for each service. You can fetch configurable options by calling Services::getOptions, and simply sum up the package price and config option prices to come to a total renew pricing that you can include on a new column in the view.

Yes, you need to first enable those notices under Staff Groups in order for staff from those groups to subscribe to the email notices.

In order to create a package, you need to assign it to a module. You went to [settings] -> [Modules] and found there were no modules installed, however, if you go to [settings] -> [Modules] -> [Available], you will see a list of all available modules that you can install. If you're not selling a service specific to any of the modules, then you'll want to install and use the generic "Universal Module" from that list. That module lets you create products and module options yourself. I described how to go through the process of creating a package for someone else in another thread here, and how to create a Universal Module product here. You can also take a look at the Universal Module documentation for more info.

If customers can upgrade those packages now, then they will still be upgradable with the proposed change. The proposed change only adds a filtering option that allows you to disable package upgrades within a specific package group. This does not span over multiple package groups. Support for trial package upgrades to a paid package is a separate feature described in CORE-504.

CORE-1613

What are the order dates? The order dates are shown on the Orders widget under the [billing] -> [Overview]. If the dates are at about the same second, they may have somehow ordered twice on accident. If instead, the the order contains two identical packages (click the table row to see), then they are adding two of the same packages to their order before checking out. If the latter is the case, they may have gone through the order twice and not realized that they already had the item in their cart.

I can see how that would be an issue for domains. We think the solution would be a new option that allows you to determine what package groups allow upgrades/downgrades. So when adding/updating a Package Group, there would be an option to "Allow package upgrades/downgrades within this group". If unchecked, no packages within the group can be upgraded/downgraded. All of the current settings will still be in effect, e.g., only packages from the same module can be upgraded, and clients can only upgrade packages if you have the setting enabled for them to do so. Do you think that would be a viable solution?

Blesta doesn't send a single daily email regarding multiple settings, like you mentioned. Blesta sends individual emails for things like payment reminders, suspension notices, etc. when the cron determines such an email should be sent. As an admin, you can subscribe to those emails so that you receive them when a client does as well. You can enable that per email under [My Info] -> [Notices]. A description of what each email template is used for is also available under [settings] -> [Emails] as well as in the documentation.

I imagine it is useful for some to allow the same email address to be used for different contacts as long as it's not for the username since some clients have a single person managing multiple (likely business) accounts, and checking only one email address would be more convenient than multiple. And for me, it is certainly easier during development to manage all of my 'fake' clients.

The email addresses are identical, and both accounts use the email address as the username? Or are the usernames different (they have to be)? Blesta allows for the same email address to be used for separate accounts/contacts, but if the email is used as the username, then it must be unique from all other users. The client would have received an error if they tried to create an account with a username that has already been taken.

Having custom fields per invoice line item is a bit different than the OP's request for custom client fields to appear on an invoice. Nonetheless, the scenario you've presented sounds like a reasonable work-around for exporting information to Xero for accounting purposes. The main reason a feature like this doesn't currently exist in Blesta is because Blesta primarily focuses on providing a billing solution rather than an accounting solution. We would be interested in integration support between Blesta and other accounting software like Xero, and in fact a feature request has been brought up before. We do prioritize our development based on demand, and as you've noticed, additional accounting features have not been very widely requested.

I've never used Microsoft Access personally, but from your link, it sounds like it simply encrypts/decrypts your entire database using your passphrase. Blesta encrypts some individual fields in the database, but not the entire database. The two are very different. I'm not sure what kind of security audit you're referring to, but I imagine that seeing password fields and credit card information as encrypted text is the expected result of a security audit. If there were a "hack" stored in an encrypted field, then you have vulnerabilities elsewhere that require attention. Encryption occurs internally to Blesta. There is no separate solution crafted for the purpose of encrypting/decrypting data outside of Blesta. Such a solution would require knowledge of its presumed use, which is knowledge we don't possess.

I see that the file appears to be corrupt after downloading it. But if you could provide an image that you uploaded through the support system, which no longer displays when downloading it, then we can test it in our systems to verify whether we encounter the same issue. At the moment, uploading and downloading attachment images is working fine in my system, so I'm not able to duplicate it.