Paul

Thanks for the contribution!

Multiple domain registrars can be used, with different TLDs going to different registrars. This is all set up on the package level. When you add a package, you select the module and what TLDs the package applies to. Then, you add your domain packages to a package group. During checkout, all TLDs valid across all packages within the group are available for order. The order system determines which package to use for the TLD being registered, which in turn determines the module. Just to add -- in the future, when we release the registrar plugin, a pricing matrix will be available. That will simplify the current method of having to have a new package for virtually each TLD (Or at least TLDs where the pricing needs to be different).

We issued a trial key manually for you (At least I think that was you!) and I noticed it has been installed. Everything working now?

If you've already had a trial, the same trial key will be fetched. Also, Softaculous should be performing the entire install, so all you should have to do is go to /admin/login to login. If it's requesting a trial key and admin setup then the Softaculous install may not have completed correctly.

Probably. You'd need to merge these changes with any future updates to the support manager if you want to upgrade. This plugin should probably be forked and renamed.

Did you remove any terms, or just change the price of an existing term? In 3.1, we made it so that terms can't be removed if they are attached to an existing service, because it effectively removes pricing from the service.

The purpose of the group is to allow staff members to subscribe to those BCC emails if they wish. Go to My Info > Notices tab to subscribe to notices that are allowed for your staff group.

The download manager allows you to restrict downloads by client group, or by package. If a user purchases a certain package, it can unlock the restricted download on the download page. Doesn't that work in this case, or am I missing something at this late hour

You're cranking along pretty nice for 1 GPU. Our rates are $0.13 tier 1, $0.18 tier 2, $0.27 tier 3, and $0.30 tier 4 per kwh, through Southern California Edison. We're in Tier 3, which blows my mind since we hardly use anything. Expensive.

I believe the goal is to keep it backwards compatible. Existing modules that are not updated to take advantage of features of the new plugin should work, they just won't make use of any plugin features.

Awesome, thanks for the contribution. I've added a note to CORE-1036, we'll review your implementation.

The PayPal subscription payment would be applied to the invoice though, it would just leave a balance still due on the invoice for the other services. That remaining balance could be paid separately. I don't believe they would be able to set up a new subscription, post order, for such an invoice though because we detect whether all the services are recurring before displaying a PayPal subscription button.

Nice mod! Mass operations are not a bad idea.

Services that are billed on the same day, are added to the same invoice, regardless of their term.

An option to require a user reset their password on next login is not a bad idea. That could potentially be used for new accounts like this. However, the password reset method that is currently implemented is preferable for that purpose. It allows the user to request a password reset, receive a time sensitive link via email, and change the password to one they want.

The license is legit and transferrable.

The task was originally tagged for 3.1.2 and 3.2.0, so we will make an effort to look at this for inclusion in 3.1.2, which already has some other completed items.

While it's impossible to know the password, it's not entirely useless. I use the generate password option when creating new accounts manually and send a link to the password reset page so they can request a new password. In a sense, nobody knows the original password and the account is secure until the user resets it.

No. When we made the roadmap public all tasks by default were made private. As we move forward, most tasks will be changed to public or created as public. Even so, there will be tasks that remain private. Just because it doesn't show up at dev.blesta.com doesn't mean it's not in there. OpenSRS belongs to CORE-387. OpenSRS was originally going to be the first module with reliance/integration with our planned domain registrar plugin, CORE-818. However, the plugin is going to take some time to complete and the demand for OpenSRS caused us to rethink this. It will be released prior to the plugin, and work similarly to all the other domain registrar plugins that ship with Blesta.

It looks like this is tentatively assigned to version 3.3, and part of CORE-552. It's unlikely we would email a client their password due to security reasons, although when a new account is created the password can already be sent in the client registration email. We don't send passwords in these emails ourselves, and recommend against it. It's better if they request/receive a password reset email and choose a new password in cases where they do not create their account.

There's currently no importer available, but if you don't have a large number of clients in bb, you should be able to recreate them in Blesta and add their cPanel accounts through the Add Service option on their client profile pages. Just uncheck the "use module" option, so that it does not attempt to create the accounts again on your cPanel server.

Oh, just to add.. this pretty much will not affect 3rd party extensions, only those that ship with Blesta. The upgrader is not going to go to the marketplace and download extensions in order to upgrade them. That will still need to be done manually for the time being, and with a click in the future once the marketplace is up and running if the extension is available on the marketplace.

I dunno, good question. Now's a good time to voice your concerns. Cody can elaborate more on what we were planning, I see there's not too much in way of specs in project management. I do know that it was something that was going to be difficult to do originally, and that's why it isn't in there already.. but it sounded like he pretty much has it figured out now.

Yep, the idea is to make it an automatic part of the standard upgrade process.

Blesta doesn't use HTML syntax to render PDFs and I've never seen it take 15 seconds. It it instant for me. Do you have a logo or background image uploaded for your PDFs? If so, remove them and see if it speeds it up any. If it does make a difference, you could try optimizing the images, and adding them back in to see if that makes a difference. Also, make sure you have the GD library if using images in the PDF -- TCPDF sometimes tries to call GD to manipulate images.