1. Release Notes 5.3.0
Release date: 2019-06-21
1.1 New features in eSignatures 5.3.0
Branding of eSignatures WebPortal
The entire look and feel of the eSignatures WebPortal is now rebrandable.
In previous versions of eSignatures, it was already possible to customize the WYSIWYS to some degree, but now every element of the entire WebPortal can be customized. This means you can apply a certain branding to the Document Portal, while using a different one for the WYSIWYS.
Rebranding the eSignatures is done by creating themes in the Configuration Index. To that end, a new user type has been created: the Client Administrator. Client Administrators can access the Theme settings of the Configuration Index, without being able to modify any other configuration settings.
You can choose to rebrand eSignatures on environment level, which means it will look identical for all users and signers, but you can also apply a different theme per document group. This way, all documents that are uploaded to one document group, say Sales for instance, will have their own WYSIWYS look, while others belonging to HR Documents will have a different one. You can even apply a specific theme on package level: for each package initiators upload, they will be able to select from a number of themes they wish to apply.
How to rebrand eSignatures is explained in full in Connective - eSignatures 5.3.0 - Branding Documentation - Limited Public.
Important: for the branding feature to work correctly, administrators must run the eSigner Maintenance Tool. See Connective - eSignatures 5.3.0 - Installation Documentation – Limited Public for more information.
QuickSigning of packages with legal notices
In eSignatures 5.3, you can now QuickSign a package, even when it contains legal notices. Note however, that the legal notices within a package must be identical per signer. It’s not possible to QuickSign if the signer has to enter one type of legal notice on one document, and another type on another document within the package.
When the setting IsQuickSignForLegalNoticeWithTagsEnabled under Signing Options Settings is enabled in the Configuration Index, legal notices may even contain a variable field (between tags) that signers must fill in manually. The value entered between the tags must be identical per signer for QuickSigning to work however.
In previous versions of eSignatures, each signing field in a package always had to be signed individually as soon as the package contained one legal notice.
Conditions
QuickSigning is subject to several conditions however:
- When multiple signing methods have been selected for the signer to choose from, the same choice of signing must be offered to that signer on every document of the package. It's not possible to QuickSign a package if the signer can choose from one pair of signing methods on one document and choose from another pair on another document.
- The following two signing methods cannot be combined with QuickSigning: sign manually+eID and biometric. If one of these signing methods has been selected, each field within the package must be signed individually.
- When using eID signing, a transparent eID card reader is required, i.e. a card reader without PIN pad. If the signer is using a PIN pad eID reader, they will be prompted to sign each field individually.
- When the package contains legal notices, their content must be identical per signer, as mentioned above.
Download unsigned documents from WYSIWYS
You can now download unsigned documents from the WYSIWYS. This way, you can open them in a PDF viewer for easy reading or print them and read them on paper if necessary before signing.
Whether or not the download icon is available in the WYSIWYS depends on whether the corresponding option has been enabled in the Configuration Index and whether the initiator enables the option while uploading the document.
Use of preferred languages throughout eSignatures
In previous versions of eSignatures, administrators could already configure the default environment language.
In eSignatures 5.3 administrators can still apply a default language on environment level, but when they create a new user, they can select a preferred language for that user that deviates from the default environment language. This also applies to users who self-register for an eSignatures account.
The preferred language will be applied throughout eSignatures:
- The email the user receives to activate their account is drafted in the preferred language.
- When the user creates a new contact, the default language of the contact is identical to that of the user.
- When the user uploads a package, the same preferred language is used.
- The email signers receive are drafted in the preferred language.
Note however, that the preferred language can still be modified on contact and package level.
Also note that when a user creates a new user in the User Management section, and when a user self-registers for an eSignatures account, the default language for that new user is the one configured on environment level.
Unique identifiers for mandated signing
If you want a contact to be able to use eID or BeLawyer for mandated signing based on matchid, you need to add a Unique Identifier for the aforementioned signing types when creating the contact.
The unique identifier is used to determine who exactly is mandated to sign during a particular session, based on their:
- National security number for eID signing
- LawyerID for BeLawyer signing
Note that it is up to the administrator to set the MandatedSignerType setting to matchid in the Configuration Index for this mandated signing type to work.
Mandated signing combined with iDIN
Mandated signing based on name and birth date can now be used with iDIN signing.
Extra info in Signing Method selection window
In the Signing Method selection window, users can now see which signing types (if any) are configured incorrectly, or incompletely and are therefore unavailable. A tooltip explains which elements are missing when hovering over the signing type. For instance, SMS OTP will be unavailable if the contact info doesn’t contain a phone number. Mandated signing with BeLawyer will be unavailable if the contact info doesn’t contain a birth date or unique identifier.
In previous versions of eSignatures, a signing type that was not configured correctly was not shown at all in the Signing Method selection window.
Extra info in Document Portal: available signing methods and used signing method
When checking the details of a document in the Document Portal, users can now see which signing methods were offered to the signers, and which signing method the signers actually used.
The signing methods a signer can or could choose from are marked in grey. The signing method a signer used is marked in green.
Extra info in Get status call: SigningTypeUsed
Just like WebPortal users, API users can now also see which signing type a signer used. To that end, an extra response parameter has been added to the Get Status call: SignatureTypeUsed. If no signing type was used (i.e. if the document isn’t signed yet), this parameter returns “null”.
New API call: Get Package Identity
API users can now retrieve the identity data of all iDIN actors of a fully signed package and its documents. The identity data is returned by iDIN itself and is retrieved through the eSignatures API.
Note however, that there will be no identity data to retrieve until the package has the FullySigned state.
New API call: Get Themes
API users can now retrieve the list of themes that have been created in the Configuration Index, and their theme code.
The theme code can be entered as Request parameter when creating Packages and Instant Packages. The packages in question will then have the requested theming.
Separate activation of Cloud accounts
eSignatures already supported uploading documents from Dropbox, Google Drive and OneDrive. In eSignatures 5.3, administrators can now choose which Cloud account to enable. Each Cloud account can be enabled or disabled separately per environment.
Note that this feature is supported on environment level. It is currently not supported to apply it on user level.
Separate activation of Terms of Use, Privacy Policy and Cookie Policy
Administrators can now choose which policy they want to enable or disable. The Terms of Use, Privacy Policy and Cookie Policy can all be enabled or disabled separately per environment. In previous versions of eSignatures, all three were either enabled or disabled altogether.
1.2 Improvements
Optimized document handling
The document handling is optimized in several ways.
Asynchronous prerendering
Documents are now prerendered asynchronously. By the time the user gets to sign the package, the rendering is already done, which results in a faster signing time since the user no longer needs to wait for the document to load. An additional advantage is that the rendering of documents now happens only once: when the document has been rendered for the first signer, it won’t need to be rendered again for the subsequent signers.
No prerendering when server signing
When server signing packages, no rendering is done at all, since no user action is required.
Multiple queues in the Worker
The different Worker processes are now done by a designated queue, instead of by a single queue. For instance, CommandQueue does the signing, CommandQueue2 does the prerendering and CommandQueue3 does the status change. Since the tasks are now done on a first in first out basis, users no longer need to wait until all processes are done to see the status change.
Note that administrators can add more CommandQueues as required. Also note that each CommandQueue has its own Poison Queue. Attention: The Clear Poison Queue call clears all poison queues. It’s currently not supported to clear one or more specific queues.
Audit proof files are no longer stored in the database
In previous versions of eSignatures, the Audit proofs feature had a significant impact on the eSignatures database. As of eSignatures 5.3, the Audit proof files are stored on the storage drive of the server that hosts the data. This reduces the load on the database but obviously increases the load on the storage drive.
The Audit proofs are removed from the storage drive once the corresponding package is deleted via the API call or via the WebPortal.
Default translations are no longer stored in the database
The default backend messages and their translations – which are used in signature texts, email messages, etc. – are no longer stored in the Translation table of the database but are handled by the eSignatures application itself.
If clients want to use customized messages instead of the default ones, they can enter them in the Translation table, which will override the default translations.
Attention: on-premise clients who were already using custom messages, must make a backup of their existing Translation table (since the eSignatures 5.3 Translation table will be empty) and execute it again after the upgrade. See Connective - eSignatures 5.3.0 - Installation Documentation for more information.
Thumbnails are no longer stored in the database
The thumbnails you see when scrolling through the documents of a package are no longer stored in the database but are stored in the storage account for performance purposes.
Attention: when upgrading from a previous version of eSignatures, administrators must run the eSigner Maintenance Tool for the thumbnails to be rendered correctly in eSignatures 5.3. See Connective - eSignatures 5.3.0 - Installation Documentation – Limited Public for more information.
Improved transfer to itsme integration layer
When sending packages and documents to the itsme integration layer before signing, the itsme Description field is now populated with the DocumentName if the package contains one single document, and with the PackageName if the package contains more than one document.
In previous versions of eSignatures, the Description field was populated by the values the eSignatures Admin configured as free text fields in the Configuration Index.
Improved InstantPackage call
When doing an Instant Package Creation call while Audit Proofs are enabled, the Locations Id (which is required to do a Post extra proof call) is now by default returned. This way the Get Signing Locations call no longer needs to be used to obtain the Locations Id of Instant Packages.
1.3 Handled issues
Jira code | Issue code | Description |
---|---|---|
CEP-5612 | / | OpenID Connect translations are currently not loaded correctly. |
CEP-5972 | / | Migrating themes created in earlier versions of eSignatures is not working properly. |
CEP-5578 | / | The Connective logo can sometimes be seen when the WYSIWYS is loaded even when the logo has been changed. |
CEP-5370 | / | It’s currently not supported to use templates combined with mandated signing based on matchid. |
CEP-6140 | / | Client Administrators didn’t have the correct permissions to modify Themes in the Config Index. |
CEP-6116 | / | The Get Package Identity call to retrieve iDIN data is now fully functional. |
CEP-6112 | / | The default value of the CombineLegalNoticeAndSigningPolicy setting in the Config Index is correctly set to true. |
CEP-6111 | / | iDIN signing issue with mandated signing disabled in the Config Index has been fixed. |
CEP-6110 | / | The DownloadUnsignedFile Api parameter is now correctly called DownloadUnsignedFiles. |
CEP-6103 | / | Reusing the download url after you’ve downloaded an unsigned package from the WSIWYS now works as intended. |
CEP-6102 | / | When downloading an unsigned document from the WYWISY, the document is downloaded correctly, and you are now also redirected correctly. |
CEP-6100 | / | The download unsigned document button issue has been solved. |
CEP-6098 | / | “Corrupt document” upload issue has been solved. |
CEP-6097 | / | Creating keypairs in the Config Index wasn’t working. |
CEP-6096 | / | CookiePolicy error that prevented doing a clean install of eSignatures 5.3 Build: 5.3.19136.01 has been fixed. |
CEP-6094 | / | Modifying the translations in the database was no longer working. |
CEP-6015 | / | Contacts there were creating a few eSignatures versions ago are not able to sign with SMS OTP even if their phone number is correctly filled in. This is because of the PhoneNumberCountry field that didn’t exist in earlier versions and is therefore not filled in for those contacts |
CEP-5980 | / | The signer modal was not always loading correctly. |
CEP-5979 | / | When using a DSS without a tenantId the DSS tab in the Config Index did not load properly. |
CEP-5961 | / | Creating a contact during the upload flow no longer creates multiple signers instead of one when he has multiple fields to sign. |
CEP-5960 | / | The server sign response change compared to API v2 has now been implemented. |
CEP-5959 | / | The DownloadUrl from a v2 Package Status call now returns the correct .zip name. |
CEP-5952 | / | User creation issues in User Management has been solved |
CEP-5950 | / | iDIN signing was no longer working |
CEP-5939 | / | DSS TrustStoreAlias loading issue has been solved. |
CEP-5916 | / | Wrong error message when you select eID and BeLawyer, and MandatedSignerType is set to matchid has been fixed. |
CEP-5913 | / | Package details are now correctly displayed in document group. |
CEP-5912 | / | F2F signing error has been resolved |
CEP-5909 | / | When QuickSigning a package that contains a legal notice and more than 2 signing fields with eid the lock call is now triggered correctly before you start filling it in. |
CEP-5905 | / | The SigningTypeUsed parameter in the Get Status Call now correctly returns all the signing types used for an actor. |
CEP-5807 | / | XML signature contains wrong MIME Mediatype. |
CEP-5700 | / | When signing with ManualBeid and using the Get Status Call the "SigningTypeUsed" parameter returns "ManualDigital", instead of "ManualBeid". |
CEP-5698 | / | DocumentSigners table with nvarchar(MAX) type issue has been solved. |
CEP-5685 | / | Adding a new Contact in summary screen now correctly closes the create contact modal (Firefox) |
CEP-5680 | / | Get Package Status didn’t provide correct timestamp |
CEP-5678 | / | When signing with iDIN, the transaction number is now present in signature. |
CEP-5656 | / | Worker uninstall could not be done without rebooting the server |
CEP-5603 | / | Very long signing names are now no longer out of bound |
CEP-5656 | / | Worker uninstall could not be done without rebooting the server |
CEP-5603 | / | Very long signing names are now no longer out of bound |
CEP-5596 | / | Signing a document after upgrade no longer gives errors in the worker logs |
CEP-5591 | / | Signer selection issue when rejecting F2F has been resolved |
CEP-5400 | / | Asynchronous signing issue where you could still reject a document after you signed it and closed the modal has been solved. |
CEP-5399 | / | Package naming issue during upload has been solved |
CEP-5398 | / | Signing fields placement and signing method selection issue with iDIN has been resolved |
CEP-5373 | / | Touch screen issue has been resolved |
CEP-5275 | 29067 | Notify error has been resolved |
CEP-4765 | / | When signing complex with itsme, a legal notice error was displayed even though no legal notice was used. |
CEP-4977 | / | When downloading PDFs in Safari on MacOS, the PDFs got the extension .dms instead of .pdf |
1.4 Known issues
eSignatures 5.3.0
Jira code | Issue code | Description |
---|---|---|
CEP-5972 | Migrating themes created in earlier versions of eSignatures is not working properly. | |
CEP-5944 | Itsme scrolling is not as smooth as expected on Safari on iPhone. | |
CEP-5612 | OpenID Connect translations are currently not loaded correctly. | |
CEP-5578 | The Connective logo can sometimes be seen when the WYSIWYS is loaded even when the logo has been changed | |
CEP-5370 | It’s currently not supported to use templates combined with mandated signing based on matchid. |
eSignatures 5.2.7
Jira code | Issue code | Description |
---|---|---|
CEP-5982 | 30119 | WYSIWYS scrolling/zoom issues on mobile devices |
eSignatures 5.2.5
Jira code | Issue code | Description |
---|---|---|
CEP-5676 | / | A revoked package with status “in progress” cannot be deleted. |
eSignatures 5.2.4
Jira code | Issue code | Description |
---|---|---|
CEP-5564 | / | When a package contains both an asynchronous and synchronous signing method, and the asynchronous signing fails, the signing session cannot be recovered. |
CEP-5605 | / | When signing f2f with iDIN and multiple signers, only the first signer is able to sign. When not signing f2f, a signer is only able to sign the first signing field. |
eSignatures 5.2.0
Jira code | Issue code | Description |
---|---|---|
CEP-5370 | / | When you set the MandatedSigningType parameter to matchid for eID signing in the Configuration Index, it is currently not possible to upload templates. |
CEP-4396 | / | Rebranding improvements |
CEP-4817 | / | Display bugs when using complex signing on Safari and Chrome |
eSignatures 5.1.1
Jira code | Issue code | Description |
---|---|---|
CEP-4719 | / | The timeout of the session is currently absolute. Users are logged out even if they have been active. |
Older known issues
Jira code | Issue code | Description |
---|---|---|
CEP-3467 | / | eID field with name+birthday validation & belaywer field (regardless of validation) incompatible |
RFC-520 | / | When a package contains multiple documents that must each be signed by a different user, and User A rejects the documents assigned to him, while User B accepts the documents assigned to him, the rejection details are not visible on Package level, nor on Document level for the user who accepted the documents. The rejection details are only visible on Document level to the user who rejected the documents. These details will be completed in a future version of eSignatures. |
/ | / | German installation of Chrome can generate errors during signing. |
1.5 Known limitations
General
- A package must not exceed 150 MB.
- A single document inside a package must not exceed 30 MB.
- A package may contain a maximum of 15 documents.
- An .xml files must not contain more than 2 million characters per file. A package must not contain more than 15 .xml files.
- Large files might affect signing performance depending on the user's Internet connection.
- Documents whose physical dimensions exceed 3.99 m by 3.99 m are not supported.
- Uploading PDF/A documents is only allowed if the format is PDF/A_2A or PDF/A_1A.
- When uploading PDF documents that already contain signature fields - which you created in a PDF solution such as Adobe Acrobat Pro DC - make sure the signature field names only contain letters and numbers, or a combination of both. Any special characters such as accented letters, slashes, dots, etc. are not supported and must not be used. The same limitations apply when uploading PDF documents that contain text fields.
- Adding multiple initiators within a single package is not supported.
- Combining eID signing and BeLawyer signing as choice of signing is not always supported: when the MandatedSigningType is set to nameandbirthdate in the Configuration Index, these two signing methods cannot be combined.
- Packages currently can’t contain both XML documents and PDF documents on which signatures will be placed. The type of package is determined by the first uploaded document.
- The default groups ‘administrators and default user group’ can’t be used as a signer in templates.
- Inserting a tab in front of a Text Marker in Word is not supported. Instead of using tabs, use tables, columns or text boxes. If you still want to use tabs, convert your Word document to PDF before uploading it.
- When using Safari: after you upgrade from an older version, you will be prompted to quit your browser. When reopening your browser and your previous tabs don’t open automatically, do not reuse your original link to the signing page. Instead, go to History > Reopen All Windows From Last Session.
- Native design applications for DTP, CAD, etc. can generate documents with a high level of complexity (very high number of elements, vectors, images, …). This may result in the fact that the application cannot prepare the document in a reasonable timeframe. Consequently, it will be impossible to add these files to the Signing environment (not through the API nor in the DocumentPortal) due to timeout. It is not possible to know in advance if a complex document will generate a timeout or not as it depends on too many factors. The applications generating these kinds of PDFs usually have a setting to create a PDF that is suitable for online usage. We strongly recommend using this setting to reduce the complexity of the document before upload.
Itsme signing
- When using itsme as signing method, the target type of your documents must be PDF/A-1 or PDF/A-2. It’s the administrator’s responsibility to make sure these output formats are available in the user’s eSignatures solution, and it’s the user’s responsibility to select the correct output format. Connective does not perform any checks whether the right output format has been selected combined with itsme.
- When using itsme signing in packages through the WebPortal, each document within the package must be signed individually.
- Itsme signing is currently not supported on macOS Mojave v10.14 combined with Safari v12.0.
Audit Proofs
- The Audit proof feature has a significant impact on the storage drive (repository) on which the data will be hosted. The bigger the documents, the more space will be used. The impact grows exponentially with bigger documents.
- The Audit proof feature also has an impact on the signing speed of eSignatures. The bigger the documents, the longer the signing time will be. Small documents (<1MB) do not seem to impact the signing speed.
API v2 to v3 migration
Legacy Mode
If clients are not able to upgrade to API v3, because they’re not ready to support one-time URLs or access tokens, they can use the Legacy mode setting combined with version 2 of the API. Legacy mode is a transitional measure that supports ‘old’ URLs and allows you to complete unfinished documents. Please be aware that this is a deprecated feature and will be removed in version 4 of the API.
The following limitations apply:
- When legacy mode is set to disabled in an environment, and you decide to enable it later on, the API flows that have been created when legacy mode was disabled will no longer work.
- When Legacy mode is set to disabled, the download URLs retrieved from API v2 can only be used once. These URLs should not be sent directly to the end user in an email, as the second time the URL is opened, a non-user-friendly error message will be show. To avoid this, clients can take the following actions:
- Either they email an URL to their application so that they always redirect from their application to the newest download URL retrieved from API v2 just before redirecting.
- They append ?fromEmail=true to the URL retrieved from API v2 so that we can show an error screen asking the end user to enter their email address. If that email address corresponds with a signer or receiver and the package / document exists they should get an email from Connective with a new, working URL.
2. Upgrade Information
For customers signing with physical tokens (eID, biometric using Wacom, etc.), the Connective Browser Package must be upgraded to version 2.0.6. The upgrade should be prompted automatically when trying to sign a document.
If you have a version of eSignatures installed prior to version 5.3.0, consult the Connective - eSignatures 5.3.0 - Installation Documentation to learn how to upgrade it to version 5.3.0.