Paul

Upgrades are currently limited to packages in the same group of the same module. I suppose this would technically be possible across package groups, if the module is also the same, as the primary limitation is the module. (It's not, nor will it ever be possible to upgrade to a package of a different module) How do you propose this should look in the UI?

Ctrl+A, Ctrl+C. Submit. Oh crap. Back button. Ctrl+V, submit. Happy.

What was the timeout before, and what did you change it to? Was it taking a long time to send client emails out?

In order to modify an invoice, all payments must first be unapplied. You can unapply them by clicking to edit the transaction, and clicking Unapply for each invoice. Then, modify the invoices, then, re-apply the transactions using Record Payment.

If you're creating the cron in cPanel, then you can leave off the */5 * * * * from the beginning, and just make sure the path to PHP is correct. The cron should run every 5 minutes.

Is it possible that your invoice has a value in the thousandths or ten-thousandths place? Blesta tracks values to the ten-thousandths place, and there is currently a rounding error that can cause this. We're working on a fix. This can happen with very small unit prices or fractional quantities. Others don't have this issue, because they do not have the same level of precision.

If the invoice was paid, and the service is a pending service, then it should be activated within 5 minutes via your cron. Is your cron running correctly?

Yep! That's the best way to go if the account is pre-existing. Some people will select the option to NOT invoice them when adding it if they were being billed previously by some other system and you want to sync them up, and then change the renew date after the service is added as well, so that it renews at the right time. For example, if it's a 1 year service when you add it, it will renew a year from today. But if the client paid you for a year back on say January 15, 2015, then you may not want to invoice them now, and change the renew date to January 15, 2016.

Yes, on their client profile click "Create Service" under Actions. Select the cPanel package, and UNCHECK the "Use Module" option. This will add it to Blesta only. Then, go back and click the "Manage" link for the service, add the correct username and uncheck "Use Module" when saving it again. The account should now be linked, assuming it points to the same WHM server.

I updated the task to recommend that this occur only when making a payment and checking to save the card details. But, essentially yes.. if you didn't have a card set for auto debit, and you paid and saved the card, then it would be set for auto debit. You could go in and change it afterwards. The issue I believe we're trying to solve is someone signing up for service, paying with a credit card, saving the card details, and then having to manually pay when the service renews. If it's a recurring service, and you pay with a credit card, most customers would think that you'll continue to use that card for recurring payments.

I've added this as CORE-1653

One thing to note is that if your backup server is compromised, currently the encrypted data would be useless to an attacker. They would be unable to decrypt credit card data, or encrypted service fields, etc. But, if the config file was present, then they'd have the key necessary to decrypt the data. I'm not opposed to a more complete backup, but such a solution should probably be optional and also be able to back up all files, including the uploads directory. For example: [x] Backup database [x] Backup files Which files? (x) /config/blesta.php config file only () All files, including uploads directory

Definitely sounds like a lack of permissions on your reseller WHM account. If the API doesn't return the packages you have access to in WHM, then Blesta is unable to display them.

I've been contemplating this for a while. When someone signs up, it would be ideal that if they choose to save their card details it sets that card up for auto debit. However, how should this work exactly? My thoughts: If a client saves a credit card, and they do not have any other cards that are set for auto debit, then mark the new card for auto debit. This would happen if the card was added via the order form, or directly in the client area. Any issues with this? The only thing I can think of, is that if they are adding a new card and want to use it for auto debit, they would have to select it if they already had a different card set for auto debit. But, I don't think we should change that automatically because they may want to keep the old card for auto debit and use the new one as a sort of backup or something.

Without config/blesta.php, nothing that is encrypted in the database will be recoverable. Blesta's database backup backs up the database only. You should at a minimum store your config/blesta.php config file on your computer. We recommend backing up all files and the database prior to any upgrade/downgrade but having a normal backup procedure for your files, and uploads directory is recommended as well.

Are you using CageFS with CloudLinux? If so, the mysqldump binary may not be available. If PHPIDS is not installed, I don't know why it would redirect to the index, I would be interested in seeing what your access_log looks like for those requests.

We may allow pull requests for certain extensions in the future. 1 step at a time

You may want to run a diff between your custom client theme directory and the source theme, it's possible there could be other files missing, or important parts to files missing that should be merged in.

Do you have PHPIDS installed? Settings > Company > Plugins PHPIDS can do redirects if the impact rating is high enough to trigger it. If PHPIDS is enabled, I suggest disabling it or adjusting the impact rating accordingly, at least until after you do what you need to do.

I'm glad you guys like CORE-639, not sure when it will be implemented though.

I understand what you mean, and ideally it would be great if we could allow people to register in Jira with access to comment on tasks. However, their licensing is restrictive in terms of the number of users we are allowed to create. So, currently we have the next best thing. Discussion on the forums, and you have public read access to Jira to monitor progress.

We use Jira, it wouldn't make sense to use two different issue trackers.

We are switching to Git, but will not be using Github. We are maintaining our own Git repository that integrates with Jira.

I sent you a PM with a trial license you can use on your local machine. You will need Internet access to activate the license. If you need a license for dev purposes after 30 days, email sales.

I'm just going to toss this out there - CORE-639 would allow for percentage discounts based on client group. The potential issue I see in this case, is that the discount would apply globally across all packages at the same rate.