Paul

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

It should probably be updated to use bootstrap columns (ie. col-md-4), which we added in 4.0 and started using with the mass mailer. That'd probably solve it.

Related to this, it's possible to change the server assigned to a cPanel service when managing the service as an admin. This is useful in cases where the account was migrated from one server to another. However, only servers from the same server group can be selected. Do you think this should be updated to allow any server to be selected? For example, if you have a server group called "Provisioning" and you have say 5 cPanel servers in it from which new accounts are assigned. But, you are moving an account from an older server to a newer server, the selector will not appear, or it will not allow you to select the new server which is in a different group. Show all instead? I hope that makes sense.

They aren't. https://requests.blesta.com

I wonder if this is an issue with the NVD3 library. Do you have the same issue if you download the library and edit one of the examples? http://nvd3.org/

It shows the login is a success even if it's a fail. We have a task for that. Here's the basic rundown for getting back in: To reset the staff password visit /admin/login and click the "Reset My Password" link. Enter your username, and click the "Reset Password" button. You should get an email with a password reset link within a few minutes. If you don't get an email, ensure that your username is correct. In phpMyAdmin or other MySQL database utility, look in the users table. Your username should appear in the "username" column, typically where id equals 1, as the primary staff account is the first user to be created. If that still doesn't work, you will need to temporarily enable legacy passwords. Please see [encryption](http://docs.blesta.com/display/user/Configuration+Files#ConfigurationFiles-Encryption) in the user manual, specifically Blesta.auth_legacy_passwords and set it to true. Then, in the users table for your username, update the password field to: 5f4dcc3b5aa765d61d8327deb882cf99 Then, try logging in with your username and the password password. Reset your password. Then, change Blesta.auth_legacy_passwords back to false.