Paul

Glad it's working for you. Just FYI for anyone with an urgent license issue where the license was purchased directly from us. Please open a ticket. Critical is best for a license issue if a re-issue does not solve it. One of only a few reasons Critical is appropriate. If you purchased your license from a reseller, please contact the reseller first. If you contact us, we will need your license key and your email must match what's in the whois for the domain.

Yep, you can forget about umlauts and such. It's the reason we defaulted to the font that we did. But if you don't need those, helvetica works great. It's why we included it.

We updated the WHMCS importer today to resolve some issues for a customer migrating from WHMCS 7.1. The change should be in 4.1, but I'm adding it here on the forums in case anyone has trouble importing and wants to give it a spin. whmcs_migrator.php Download the file, and upload it to ~/plugins/import_manager/components/migrators/whmcs/ overwriting the whmcs_migrator.php file that is there. Run the import with System.debug and error reporting disabled in your ~/config/blesta.php config file, which is the default state.

I've alerted @Jono about this, hopefully he can make the change to the documentation.

Config options are not converted. It gets very complicated. We may have another look at this in the future.

You can specify prices in base currency on your packages and have Blesta perform the exchange rate to other currencies. To enable that, go to Settings > Company > Currencies, and uncheck "Use Package Pricing for New Services Only". If this option is checked, new services must use the defined package pricing. If unchecked, it will be converted.

1. The term change takes affect at the next renewal. That might account for the discrepancy. 2. Blesta Addons is correct, however I will note that we are planning to add a feature to distinguish upgrades from downgrades such that you could only allow upgrades if you choose. A bit related to your question, but not sure it would be helpful to you. 3. Make sure your SMTP ports are open at your firewall, and check your logs. You can also enable error reporting in /config/blesta.php and try sending manually. Double check your settings under Settings > Company > Emails > Mail Settings. It's important that you have the right SMTP Security set for the port. For example, with Mailgun the settings are SMTP Security: TLS, SMTP Port: 587

Are you using pro-rata for domains? I believe the bug introduced by CORE-912 was this one: https://dev.blesta.com/browse/CORE-2397 If you're not using pro-rata, I would expect it to impact all services. If not pro-rata, what are steps to duplicate?

Officially, you'd need an unbranded license to do that. Reason being is that we could get a lot of requests for what would be acceptable to change it to with a branded license. So with a branded license, officially, it should be unchanged. With that said, if you do change it to that, it's not likely anyone is going to complain.

I like the idea, but it's not very simple to implement. A simple solution would result in staff getting spammed every time an incident occurs. A more measured approach is to log these kinds of issues, and then send out a single digest email once a day or at some interval to staff who are subscribed to receive those notices. The good news is that with 4.1 comes monolog, which means there is a common place that issues are starting to be logged to. Over time, monolog will handle more and more logging, and some type of staff notification system will be feasible.

It does seem like only the summary is searched. I presume this was done because searching all of the replies is time consuming, however it's certainly possible... we could search replies, and notes, and it's probably worth at least benchmarking to determine the impact. Besides, it's more acceptable to make the user wait longer when doing a specific search, ie a search on tickets only.

Encrypting a large amount of data on the fly with PHP is not feasible as it's incredibly slow. However, it might be possible to use openssl on the linux system to perform the encryption, prior to securely transferring it to a remote location. I found this article that describes that https://blog.cavebeat.org/2016/02/encrypted-backups-with-secure-mysqldump/

Thanks, I posted a comment / question on the requests site.

Ah, very nice! So when you change it for a specific service, you can enter the new details for the new service fields.

A new Alipay non-merchant payment gateway (alpha) is available. To install, download the attached alipay.zip, unzip and upload the "alipay" directory to ~/components/gateways/nonmerchant/" and visit Settings > Company > Payment Gateways > Available to install and configure. alipay.zip

Do you remap service field data for all services that get a module change? It's one of the reasons we don't allow it currently, because it could potentially create issues with those services. I agree something needs to be done though, so looking forward to seeing what you're working on!

It's not possible. Why would you want to migrate away from Blesta anyway? Your users will have to reset their passwords.

Could you provide more information about what you're trying to accomplish? We may have some recommendations. Since user passwords are hashed though, using bcrypt HMAC SHA-256 hashes they are not reversible. If they were reversible, it would be considered a security risk. Even MD5 is not reversible, but it's considered weak due to collisions and rainbow tables.

Are you just having trouble with teamspeak? Can you still provide a TCAdmin server with Teamspeak to test?

/callback/gw/1/paypal_payments_standard/ is the correct path, assuming your Blesta is install in the root web. If Blesta is at sub.domain.com, then sub.domain.com/callback/gw/1/paypal_payments_standard/ would be correct and should just return a blank page with HTTP 200 response (not a 404) Assuming that is correct, it's also important that the paypal email address match a client. This is how Blesta decides where to apply the payment, it checks for a matching email address. If the email does match, it should be applied. If it does not match, that subscription should be cancelled and re-created within Blesta or the customers email address should be updated to match. In the future we want to store subscription id's and reference them that way instead, which would resolve this kind of issue.

It should work on their latest version, unless they just recently released a big update. Are you having trouble? Can you tell us more?

The addon package should be billed monthly if it's a monthly service. Can you elaborate?

It sounds like it should be closing it then if: The department is set to close tickets after 2 days A staff member was last to reply Your cron is running the task every 6 hours What you could do is see if there are any errors. You can disable your cron job before it processes that task again, and then run it manually under Settings > System > Automation with error reporting enabled. To enable error reporting, edit /config/blesta.php and change Configure::errorReporting(0); to Configure::errorReporting(-1); You may also wish to enable System Debug. To do so, change Configure::set("System.debug", false); to Configure::set("System.debug", true); Be sure to change this back when you're done. ESPECIALLY System.debug. System.debug is known to sometimes cause licensing issues if left enabled.

Was the admin or client last to respond? If the client was last to respond, it will not automatically close the ticket as it expects it's waiting for staff to respond. This prevents clients from opening a ticket, not getting a reply, having their ticket auto-closed, and talking bad about you on social media

CORE-2406