Paul

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.

That's unusual.. I assume the clients had a different ID internally in MySQL but the same ID code? How far apart did these clients register? Do you have any records from MySQL prior to cleaning it up?

There's not a cPanel only account import, but there is a process to adding cPanel accounts to Blesta if Blesta did not create them. Just follow these steps: https://docs.blesta.com/display/user/cPanel#cPanel-ImportingcPanelAccounts

Someone mentioned that they got this to work, I'm assuming it was you? You should be adding the directory name digitaloceanmodule to /components/modules/, which contains the module files. Then, under Settings > Company > Modules > Available, Digital Ocean should appear with an "Install" button.

This is likely out of date and the file attached to this thread has revisions. It'll be on our Github soon. Regarding this issue you've found, what is the affect? Also, feel free to post any other issues in this thread and we'll take a look.

This isn't a bad idea, disabling the editing of certain fields like names or company names could prevent accounts from being so easily sold to someone else. We'd probably use it internally ourselves.

Blesta 4.2 makes an attempt to determine the correct path to PHP under Settings > System > Automation. Not sure if this helps, but worth taking a look at what is displayed there if running 4.2+

I believe the client will have to do it. If that option was checked when they created their subscription, I believe they can do it within PayPal.. some steps listed at https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/manage_subscriptions/ You can check their subscription in your PayPal account also, and see if you have the option to change it, but I've only ever seen a cancel option.

So only the options in your screenshot? No others? I agree we should do this, but when I create the task I want it to be clearly defined.

I'm not totally sure I understand. Is this just a request to be able to set all of these reseller options on the Package in Blesta, if it's a reseller Package? When the reseller account is set, all these items are passed along? If so, does anyone have a list of all the options that should be included, or a screenshot in WHM where they would be set if created manually?

It's interesting that /dev/urandom is denied, most people that get an open_basedir error do not get one that references this path. You'll want to add this to your open_basedir path, or disable open_basedir.

If it keeps locking up, it's probably encountering an error and crashing. Since it's paid pending services being activated, look at your pending services.. most likely, some are failing to be activated, and possibly using a 3rd party module that is returning an error. Check also module log Tools > Logs > Module. Check also your file log (Settings > System > General > Log directory, open files in directory and look for errors at the same time)

Maybe the fields, like "Option Name" here should be able to be language definitions. If the fields could be translated, do you still think we should add Birthday and Gender? This would allow any fields to be added, and fully translatable. I think this is better than adding the fields into the core. Someone else will ask for SSN, hair color, or whether the person owns a dog, and custom client fields were intended to allow people to add anything they want.

If they were imported properly, then no, you shouldn't have to do anything. You may want to edit a few to spot check them, and ensure they have a username set that matches their cPanel username. If they do, you should be good to go.

Sorry I didn't see this thread sooner. Did you take a look at https://docs.blesta.com/display/user/cPanel#cPanel-ImportingcPanelAccounts ? It describes how to add an existing cPanel account to Blesta. The main thing is that it's pointing to the right server and the username is correct. If so, Blesta should be able to suspend/unsuspend automatically, etc.

Why doesn't a custom client field work for you? For language, you can add your own language definitions to the custom language file and use a definition here for the name instead.