Paul

This license is with us and eligible for transfer. We don't handle transfers on reseller licenses.

Your cron should specify the full path to PHP, ie /usr/bin/php /home/username/public_html/backstage/index.php cron > /dev/null (etcwhatever is here) Check Settings > System > Automation to see the recommended command. Blesta attempts to locate your PHP and show the right thing. It may not be 100% accurate all the time, but it's a good place to start. If Apache is running PHP 7.2, then CLI should be also.

I can confirm it is eligible for transfer.

How long has it been "stuck"? If it fails, Blesta should pick up and retry when the task runs next. Check Settings > Company > Automation to see if the task appears to still be running, when it last ran, and what the schedule is. If the task appears to be running but should have been completed, it may have crashed. Check your logs ../logs_blesta/ defined under Settings > System > General.

That's right, but the headers can be spoofed, that's why the ticket hash.

How do you mean? CC and BCC recipients receive a copy of the original email, so subject & body would necessarily be the same. If a ticket is sent to multiple recipients, then I think we'd generate each email separately and it wouldn't be a CC. The ticket hash provides necessary security and verification.. I forgot that I was composing this, and may have had more to say and got distracted. So, I'll leave it at this for now

{ticket_hash_code} is designed in such a way that Blesta can use it to identify the proper ticket, without leaving room for someone to maliciously modify the code to reply with updates to tickets that belong to other customers. It's designed with security in mind. ticket.id and ticket.code have direct relationships with real tickets, particularly ticket.id which is auto incrementing. Someone who receives a ticket with an ID of 100 can be reasonably sure that the ticket with an ID of 99 has already been created just before this one and is probably still open, and that ticket ID 101 will follow.

Is your cron job running as root? Did you install as root? Cron should run as the same user as your web server runs as.

Do you have a ticket open? When you updated from 4.5.0 to 4.5.1 did you apply the patch originally or the full version? There's nothing in the update that should cause the error you received, unless it was a coincidence and your license hadn't been validated in quite some time. When you updated to 4.5.0 was everything working fine? Did you run /admin/upgrade to upgrade the database? If it was working fine, and was upgraded properly, then applying the 4.5.1 update should be fine. However, you could pretty easily roll it back by re-uploading the 4.5.0 release, or restoring from backup. Does it work if you do that?

Blesta provisions paid pending orders. This means that the order is approved and paid, then the cron provisions the service. Whether the order is approved depends on your settings and any anti-fraud. Check Packages > Order Forms > Settings for anti-fraud options. Edit the order form to make sure "Require Manual Review and Approval of All Orders" is unchecked. Make sure your cron is running, it provisions orders that are approved and paid.

CC who for what exactly? For most, contacts work well, especially billing contacts who will receive billing related emails.

Support > Staff, click to edit the Staff member and add a signature for them under "Settings". Whatever is added to the signature will be inserted automatically into the editor when the staff member goes to respond to a ticket. The signature can optionally be removed, but it'll appear automatically.

In your Department settings, is the "Override the from address set in email templates with the email address set for this department" option checked or unchecked?

https://translate.blesta.com If you do a good complete translation we can make yours replace the bad translations.

Not an option right now. People can download and install it.

How long ago did you change all of those services to active? It can take up to 6 hours for a lock to clear on its own. I would give it some time and see if it goes away. If these services were imported as pending, it's possible there is some weirdness with the data that is contributing to the issue.

Does your label have a space in it? Remove any spaces and non-alphanumeric characters. If it's still an issue, check your logs. ../logs_blesta/ defined under Settings > System > General. White pages generally mean errors.

Changing a password in cPanel doesn't update the password in that other billing application. They just used SSO. Stay tuned, there's a rumor than the cPanel module may be updated in Blesta 4.6 to do this. Of course, I can't confirm nor deny this, time will tell.

This thread is over 2 years old, why resurrect it? If you are having a similar issue, please open a new thread and provide details (you can always reference this thread).

Did you run /admin/upgrade without error? White pages are generally errors, check your error logs ../logs_blesta/ typically, but defined under Settings > System > General. If you can tail all the logs via SSH (tail -f /path/to/logs_blesta/*) while you refresh those white pages, any errors will be displayed. Otherwise, you'll have to download the log files and open them up and check timestamps.

Are you trying to sell subdomain hosting off of your own domain? What module are you using? See this request for cPanel https://requests.blesta.com/topic/choosing-a-subdomain-for-hosting-product To accomplish this now, you'd need to make a tweak to the module.

More adoption!

What Mike said. There is likely a pending service that is failing to be provisioned. Could be resulting in an error. Check your logs at ../logs_blesta/ (Defined under Settings > System > General) Pending services listed under Billing > Services: Pending

Never do 2 things at once. Since 4.4.2 supports PHP 5.6, I suggest doing the upgrade of Blesta first, then upgrading PHP. Backup database + files 3.6->4.4 is a long way, I suggest upgrading to 4.0, then 4.4.2. See the upgrade docs at https://docs.blesta.com/display/user/Upgrading+Blesta for an important list of files that must be deleted when upgrading from 3.x. After you are up and running on 4.4.2 on PHP 5.6, and upgrade PHP, then you will need to apply the right hotfix in the blesta-4.4.2.zip file, hotfix-php7 for PHP 7.0, and hotfix-php71 for PHP 7.1 or 7.2.

Disabling open_basedir is the simplest solution, but you could alternatively include all paths that Blesta must access. Off the top of my head, the install directory, the uploads directory, the temp directory (/tmp/) to start. phpseclib also tries to access /dev/random, /dev/urandom for encryption purposes. It's easier to leave open_basedir disabled, but that's up to you. We also recommend running Blesta on its own server (A VPS will do) without any other applications, but many run in it a shared environment.