Paul

I'm not sure if the invoice number is available to that page. The invoice is emailed to the customer, and available in the client area as you noted. To add it to that page you could open a feature request.

It doesn't have anything to do with Blesta specifically, but rather SSL/TLS on the server. There are 2 parts to it SSL/TLS in Apache (inbound requests) and SSL/TLS in PHP (outbound requests). CentOS 6 < 6.8 can do TLS 1.2 in Apache for inbound requests, but not outbound requests. This is why it's important to upgrade to 6.8 minimum. I think 6.9 is latest in that release, so that should be ok. No issues with CentOS 7.x

Also, just FYI in my experience if you're running CentOS, you will need CentOS 6.8 minimum. 7.x recommended.

HTML and Markdown are different. I think Tyson is saying that Markdown is supported, but that's not the same as entering your own HTML. See https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet for more on Markdown syntax.

Wrong. id_value is for display purposes, and it's not joined with any other tables. If id_value were unique, Blesta installs with multiple companies would not be able to have clients, or packages, or many other things with overlapping ID's. Also don't appreciate the language, and your response comes across a bit arrogant.

Not currently. I recommend having a support department for GDPR requests specifically, and then staff can generate and attach it to the ticket. If there is demand, we will consider adding self-service so that clients can request and get within the client area, along with a setting so admins can enable it or not. Companies may decide to only grant requests to EU customers, or all customers, or no customers.

We are planning to add a filter option here (and other places similarly) to allow more controlled filtering of Packages. In this case, by Module and by Name. Please see CORE-2339 along with a screenshot of the proposed look. What do you think? Any suggestions?

A package group can contain both restricted and non-restricted packages, and the group itself isn't restricted or not restricted. I would suggest mixing restricted and non-restricted packages in the same groups. There is a known bug with this right now though, where the restricted packages can mess up the order form, causing all packages in a package group to be displayed incorrectly. Should be resolved in beta 2 this week.

If you are using funnels and collecting order amounts to pass into Google Analytics, then your embed code may look a little different, and you'd want to make user of variables and possibly page conditions to set the right values. I'll have to look at an example of this using funnels and see if it's possible to provide a generic example that'll work. If you are not using funnels, and just want Google Analytics to appear on order pages, you can paste in the entire code and not use any conditionals.

That would be nice, I think the report system doesn't currently allow a search field in the report fields though. Something to consider though, thanks for the suggestion. It is a little bit more work to get the client's ID.

I'm not sure what you mean by the main package page.. do you mean the admin area packages, or the order form? As of 4.3, package groups can be sorted on the order form, and packages have always been able to be sorted in their groups, so the display order is now fully configurable on order forms. If you mean the display in the admin area, right now they are just sorted by newest package, though the Packages > Package Groups page will display packages in their sort order. There are some improvements we can make here in the future.

They would request a copy of their data by whatever means you specify. The ticket system is likely to be commonly used, but you should define this in your terms as they relate to GDPR. If there is demand for it, we would consider adding a self-service option for this in the future, but most companies will prefer to perform the export and review the JSON file to ensure it doesn't contain any information they don't want to provide before passing it along.

That's a good question. Right now the only way to sync them would be to do so manually, this option only affects new addons per the setting in 4.3. Syncing old addons to their parents could result in new prorated invoices, so I think we'd want to be careful about that. Perhaps a report to identify addons that are not in sync with their parent would be a start, if your goal is to sync them up.

Blesta version 4.3.0-b1 (BETA 1) is now available. You can download it from right here (Client Area Login Required). Read the blog post announcement at https://www.blesta.com/2018/06/15/blesta-4.3-beta-released/ This is a BETA release. Beta releases are not considered stable enough for production use, and are UNSUPPORTED. DO NOT INSTALL IN A PRODUCTION ENVIRONMENT. Please report any bugs you find in the v4.3 beta bug forum. Installing Blesta See Installing Blesta in the User Manual for instructions. Upgrading Blesta See Upgrading Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 4.3.0-b1. For older releases see all Change Logs.

I think you want these options under the "Service" area instead of the "Package" area. Where you entered these, they should appear when creating/editing the Package, but the service area will be shown to customers during checkout.

I agree some further changes are necessary. With VAT Inclusive, do you expect to define the price on the Package with tax included? Or do you still expect it to add VAT to the package price, but show it as a single price?

You'd have to export the FOUR theme, then import it, and then you can add the logo URL. I see how this is a bit unfriendly, and we can probably improve that. Regarding the logo image, if we allow it to be uploaded through Blesta, it would probably still be unique to the theme under Look and Feel. Also, files uploaded through Blesta go into the uploads directory which we recommend not be publicly accessible, so it might be necessary to serve the logo via PHP if we store it in the same way.

I don't think any change is necessary, unless it were clarification that the default feeds will remain in the message when performing a delete. To get around it in your install, you can remove the default feeds from the plugin config as described.

Fetching a trial key will return the same key if one was issued to that hostname within a given (unpublished, subject to change) period of time. This is to prevent people from running trials indefinitely, and never purchasing a license. This means that an expired key could be returned from our system, which would then result in an error within Blesta. @Sumaleth I have responded to your PM with some more details, that I hope will be helpful.

You will be able to fully delete clients, even if they have services and transactions in 4.3. Beta out any day now.

Is there any reason you can't use the order form in Blesta? You have to re-create a whole lot to keep it separate, but integrate. It's possible, but having Blesta accept the order, process with Stripe, etc is going to save you a lot of work. If necessary, you can modify the order form.

Did you check module log? Tools > Log > Module, click row to expand and see raw input/output. Is your firewall open? Are you sure your API credentials are correct? This is not a known issue with the module.

Each status will behave a certain way, so Inactive to login, Closed no login. It may make sense for us to add a tooltip or something to indicate how each status works so it's obvious to admins, but I think the current status toggle will work without the need to add a new separate option for disabling login.

I think this would address your concern: https://dev.blesta.com/browse/CORE-2222 It proposes a 4th status of "Closed" to client accounts, so that we would have: Active Inactive Fraud Closed And then the "Inactive" status behavior would change, and clients could login, etc.. unless it was "Closed".

Do you see an big jump in ID's? This can happen with automated bots registering accounts that fail to be created. A failure causes the transaction to be rolled back, but MySQL doesn't reuse the ID from the failed database transaction.