Paul

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.

We are switching from SVN to Git soon, though it's unlikely at least for now, that there will be public access. We have a build process, and part of that process is to pull in externals. All extensions have their own version numbers and belong to their own repositories. So, even if we did allow public access, there's more you'd need to do in order to have everything that's in a build. We'll be announcing more details about this and more as we get closer to a 4.0 release.

I saw a picture of a polling station inside a shipping container lol

Hi Razva, Thanks for stopping by, I recall seeing that thread. To answer your questions - 1. Blesta does not currently support config option logic, however I do see us implementing this in a future release. We fully plan to provide better support for dedicated servers. 2. We do include a Proxmox module with Blesta, and a 3rd party developer has released a modification of it here - http://www.blesta.com/forums/index.php?/topic/4037-module-proxmox-reloaded-beta-release/. I don't believe our version includes support for configurable options, and it has noot been updated since we introduced config options in Blesta. 3. Blesta does have multi-lingual support, and in many areas where you define the language you can enter a custom language definition. One example is Contact Types which you can define in the interface. See http://docs.blesta.com/display/user/Company+%3E+General#Company>General-CreatinganewContactType There may be other areas that could benefit from this.

This is what restricted packages really are for. The issue however, is that we have not yet made restricted packages show on order forms. If added to an order form, restricted packages should only appear to users who have access to those packages under their client profile > Actions > Set Packages and whom are authenticated. Without the ability for clients to order restricted packages they have access to, restricted packages can only be administered by staff. Price overrides work well for one off price reductions that are unique per client, and Restricted Packages work for selling in tiers (Once we can get it working with the order form). Our Blesta reseller plugin that we use internally adds monthly licenses as "one time" services and handles the billing for them via its own automation task. It allows clients to be added as resellers, and pricing tiers to be assigned to them. This is similar in a sense to the other methods, and what you describe, but it requires the plugin to take over invoicing, which is currently only possible for one-time package options. I mention this as it's a unique way of handling tier based recurring billing using a single package. I think we were considering an event or feature where a package could get its pricing from a module or plugin. Such a case would allow the plugin to determine the pricing within itself.