Releasenotes

Changes in the SOAP API interface for the 2.13 release:

The createUser function on the PxPomAccount has a third parameter $email, this parameter was added in the 2.12 release, but in the 2.13 release it is required due to changes to our login system. 

When this parameter is not given or invalid the function will not crash, but return false.

So when you use this function in API scripts please make sure a valid email address is supplied. 

In version 2.12 we introduced the so called issue checker, a lot of potential pitfalls are recognized. In this way we hope to help you to make your e-mail better and make sure that the message arrives in the inbox of the recipients.

However some of the pitfalls for which a warning is given will damage the reputation of both your company and our servers. In version 2.13 we will NOT allow your e-mail to be sent if some specif errors are detected. The following problems will cause your e-mail to be unsendable.

• A DKIM is configured but not correct
• The message size exceeds fair limits
• The envelope or from address is misconfigured
• Sender ID / SPF is setup but does not allow our servers to send your message
• The spam score exceeds reasonable limits
• Unsubscribe behavior is not configured for the target collection or database

There have been a lot of changes in the way how the users are connected to their accounts and their user information. The old system required that each user should be created on each account, this is not necessary anymore. Each user will now exist only a single time with access to one or multiple accounts.

Due to this change the login will now only require your e-mail address and your password. After the login you will have the possiblity to choose your account if you have more then one.

The application supports multiple types of fields examples of these are integer (for numbers), email, phone, text (with a certain length) and select (allows the user to define a list of options). If you convert one field to another field (or change the options or length) a check is performed to make sure that no data is lost. If data will be lost the user should be warned.

Unfortunately this warning did not appear in all cases, and if the change was performed it was not registered as a change. As a side effect, this could cause inconsistency between an e-mail and a webversion of that e-mail.

In version 2.13 of the application, some changes were made to improve the warnings. A lot of extra ways of data loss are recognized and a correct warning is triggered for these. Eg. if you remove one of the options of an select it will give a warning but only if it used in one of the profiles. And if non-ascii characters are used in a text-field and that field is converted to an e-mail field a warning is given, because the e-mailfield only supports ascii characters.

When you decide to accept to loss of data and ignore the warning, the changes are now also completely logged and are thus also visible on the webversion.