Cody

CORE-1074 fixed for 3.1.3.

Probably not.

Added CORE-1092. Currently planned for 3.3.0, but no guarantee it will make it in at this point.

If you're having trouble it could be that: That event only exists in version 3.1+ That event is only executed when an invoice is edited. Also, it's better to create a plugin to listen for the event.

Links expire automatically after a predetermined amount of time. See configuration setting: Blesta.reset_password_ttl. Feel free to submit your idea as a feature request. Closed as not a bug.

The key pair does not change automatically, no. If the key pair is destroyed the system will return an error to the client, at which time the client should simply attempt the key exchange request. A new key pair will then be generated automatically.

Uh... no. Only unskilled programmers will say that. We write Unit Tests and perform nightly builds to detect regressions before release.

"Servers" would not have been correct grammar.

Does Stripe not do this? Last time I checked they did.

Where are you getting this bizarre information? It's certainly not from the PCI spec. If the server doesn't touch the card data there is no need for PCI!

Correct. PCI compliance is nothing more than a set of guidelines describing HOW to store and handle card information securely. Blesta follow those guidelines. So if your server is properly configured you are already PCI compliant. The discussion regarding never touching card data (using stripe.js, etc.) is PCI avoidance, not compliance. If you never touch card details you don't have to worry about PCI compliance.

Added CORE-1085 to allow merchant gateways the ability to bypass Blesta when adding/editing payment account details.

This is untrue and misleading. Blesta is entirely PCI compliant, regardless of how you choose to store or not store card details. The only compliance requirement which must be followed (and is entirely outside of Blesta's control) is PCI compliance scans to ensure proper server configuration.

We've been looking into ways of providing gateways the ability to inject javascript into the payment process for some time. It's coming down the pipeline but to be honest, unless there's more of a demand for it, it's not happening in 3.2 or 3.3.

Bummer. Well, if it does happen again please do capture the headers and send them along.

The portal plugin allows you to create links for these types of things on the portal landing page using a WYSIWYG editor.

Google Checkout is dead.

Not a bad idea.

I don't think a dedicated mobile version will be necessary when 3.2 comes out (responsive bootstrap client/public interface).

With steps to duplicate maybe we can try it ourselves, but without steps to duplicate... no.

Heh. We were just discussing this last Friday. So far very little demand for this particular gateway.

Simply means what it says. Perhaps you're attempting to log in with your email address instead of your admin username? That's probably the biggest issue people run into when logging in, since their username is not necessarily their email address.

To temporarily get around the issue you're experiencing you can edit /plugins/support_manager/components/email_parser/email_parser.php From: $files['attachment']['name'][] = $attachment->getFilename(); To: $files['attachment']['name'][] = (($filename = $attachment->getFilename()) ? $filename : "unknown"); Since we're unable to duplicate the issue, we need a copy of the headers for the message that fails to parse correctly in order to debug.

What are the headers for message ID 1 in that mailbox?

Moved to support as quite obviously a support request.