Paul

Nope, and it's not been very highly requested. You may wish to start a feature request thread for this though, so we can gauge interest.

Awesome, thanks for the update!

Are you migrating from Blesta 2.5.4? If it's something less than 2.5.4 (ie 2.5.0-2.5.3) then it wouldn't work. The error seems to indicate an issue with the query, but I've never seen this reported before and it's hard to say without the full query. It appears to be fetching module row information. Are you importing to Blesta 3.4.2, using the Import Manager that ships with that version? MySQL 5.0.67 is fairly old, and it should work, but curious why MySQL is so much older than your PHP. Upgrading MySQL might be a good idea, but I'm not confident it would result in a better outcome.

If bounces are not rate-limited they should be. That may be the issue here, as Tyson mentions. Tyson, can you look into this further? Jonathan, this may not be the most ideal work-around, but you could disable the "Ticket Bounce" email template to prevent these emails from going out. The downside is that if someone sends in a legitimate request and it's not accepted, they won't get the notice.

Blesta gives PayPal a unique URL to post each IPN notification to so that the payment can be correctly applied. The URL contains the company ID, along with the internal client ID. This allows payments to be applied correctly even when the same person may have multiple client accounts, even across multiple companies. The issue is one we've discussed internally in the past, and I believe there were limitations to being able to make this work without re-creating the subscription. I suspect it may be possible by creating a file that acts like a proxy, taking the IPN request, and determining the internal Client ID and company to apply it to. Proxying the response back to PayPal. I'll bring it up again on Monday. If you have information about what URL PayPal notifies on whmcs installations, it may be helpful. I would really like this to work out of the box, as it removes an obstacle for migration.

Expose looks interesting. Even though it hasn't been updated in some time, PHP IDS does work pretty well. We have some tasks to improve it further, as it can result in false positives for staff in Blesta. For example, editing email templates. An option to disable PHP IDS checks for authenticated staff is pending. Eventually I'd like people to be able to use PHP IDS more, or whatever IDS system we ship with Blesta. It would be great too, if we were able to push down new rules to Blesta installs. If a security vulnerability were discovered, it would potentially allow us to push out a rule to block against it.

What data specifically are you concerned about? Blesta encrypts a lot of things by default, but modules can also control what they want to store encrypted so there is flexibility there. We don't use any secret proprietary encryption algorithms, it's all open so the data can be decrypted, with some effort. The database backups area in the settings should be restricted for staff groups that you don't want to have access. Under Settings > Staff > Staff Groups, edit the staff groups and remove permissions for those that should not have access. Without access, they will not be able to change the settings or generate a backup manually. The encryption key currently should not be changed, but a utility that would allow you to re-crunch all of your encrypted data with a new key would be a good idea, it just hasn't been a high priority yet. A passphrase can be set for batch credit card processing, and the passphrase can be changed or removed without affecting the encrypted data. Cheers!

CORE-1607, top of the backlog for 3.5

Definitely not in the database, makes for large harder to restore, harder to backup databases. You should have a really good reason for using BLOB, and even if it was base64 encoded, too much data. Doesn't seem like a lot of support for this, but I'm tempted to create a task anyway, that we'll get to, sometime. Anyone think of any reasons we *shouldn't* add this, except for the fact that it may clutter the UI?

I believe the template is /app/views/admin/default/admin_clients_email.pdt, look for $this->Form->fieldText("from", $this->Html->ifSet($vars->from), array('id'=>"from")); Change to: $this->Form->fieldText("from", "your@emailaddress.com", array('id'=>"from")); I think that's right.

You could modify the template to hard code in a specific email address, but you'll have to merge that change on any upgrades.

Does this work for everyone?

CORE-1605 - When proforma is converted to an invoice, set date billed to current date Also, CORE-1561 - Requeue invoice for delivery when converted from proforma Both of these should be in 3.4.3 as soon as next week. That leaves 2 things I believe, please correct me if I'm missing anything. 1. CORE-1287 - Prevent Proforma and draft invoices from reusing numbers. This is more complex. 2. Do not display date due on invoices converted from proforma. On #2 I think some more discussion is required. There are a couple ways to do this: 1. Have an invoice settings option to disable the display of due dates on all invoices. This may be useful for those who do not use proforma as well. 2. Do not display due dates on invoices that were created from paid proforma invoices. If we do this, we need to store more information on the invoice that indicates that it was previously a proforma invoice, possibly another field in the table. Thoughts on #2? Thoughts on CORE-1605, CORE-1561, or CORE-1287? EDIT: Also, to add, it would be simple to remove display of the due date on invoices that are not proforma with a little code. So, while we come up with the best solution, you could make this change now to affect all invoices (but not pro forma).

PayPal must have the correct currencies selected for the gateway, and the packages being purchased must be in one of those currencies, and the order form must explicitly accept the same currency.

Setting the date billed to the date paid should be simple enough, but not displaying the due date is another issue. Once an invoice is an invoice, I don't believe there is any record of it once being proforma. Is it a problem if the due date is also set to the date billed / date paid? Or maybe change the due date only if it is older than the date billed / date paid? Or is it standard to not display the due date at all? If we don't display it at all, we need to be able to tell that it use to be a proforma invoice. Thoughts?

Your server just needs to be able to connect to PayPal's API with their upgraded SSL. If your server doesn't accept their certificate, or understand SHA-256 signed certs, then it will not work. Unless your server is old, it should work fine.

Use the "Record Payment" option in Blesta under their client profile page. Record Payment is under Actions. Also, you can get there by clicking Pay next to the invoice, then record payment instead.

I sent you a PM

I just sent you another donation, and anyone who has found your work useful should do the same!

We would be happy to help promote a zadomains.net module. Also, the marketplace is almost ready, and it could be listed there.

There isn't currently any rotation of backups (deleting old ones). S3 is pretty cheap, but you may wish to login to S3 and delete old ones backups manually. An archiving and rotating feature request for deleting older backups while archiving say a daily, weekly, or monthly would be welcome. Restoring has to be done manually. If we add the ability to do a restore in the UI, it could fail if it's too large. Database restores in most cases should be done via CLI Using phpMyAdmin works too, but has similar limitations as to size and timeouts as if we built in a restore to the UI.

Blesta is transparent about encryption and what algorithms are used. You will always be able to decrypt your data, with the exception of hashed data, like passwords which are bcrypted HMAC-SHA-256 hashes and are not reversible, even by Blesta. So yes, you can get your data out.

BrainTree Vault? Someone emailed asking about it today, not sure if that was you or not but if you would be willing to buy an owned license for BrainTree Vault support we may be able to make that happen. I would just need Cody to review the docs to ensure there are no obvious issues.

Cool, any thoughts from anyone else? (Can I get a PLUS ONE?) lol

I like the suggestion, it saves a few steps in finding out. I would be hesitant to add another permanent column though, I wonder if it would make sense in the "Term" column, ie "1 Year @ $123.00 USD". It may take up less room. Also another reason to do what I wanted to do before the initial 3.0 launch, which is an icon / drop down selector for selecting which columns you want to display and in what order. Would allow us to add a lot of column options, while maintaining a clean UI by default.