1. Release Notes 5.4.0
Release date: 2019-09-26
1.1 New features in eSignatures 5.4.0
Reduced match level in Mandated Signer Validation
In previous versions when using nameandbirthdate as Mandated Signer Type for either eID, itsme or iDIN, the match level between the signer information and the data retrieved from the signing method had to be 100%. The slightest mismatch would render the signer “not mandated to sign”.
As of eSignatures 5.4, system administrators can configure a MatchLevel for each of those signing types in the Configuration Index, under Signing Options Settings. This way, you can configure how accurately the contacts' first name and last name must match the data from itsme, iDIN of their eID card. Note that the Jaro-Winkler algorithm is used to calculate the accuracy. So, the accuracy is not based on the exact number of characters that match.
API users can also choose to override the MatchLevel value configured on environment level by passing the MatchLevel parameter in the Set Process Information and Instant Package Creation calls.
Ending the signing flow
As initiator, you can now end the signing flow at your own convenience. As soon as a package has been signed by at least one party, but still has some unsigned fields that must be signed by others, you can now choose to end the flow and mark the package as finished.
This way, the document becomes available for download and it is no longer necessary to wait for all parties to sign before anyone is able to download the document.
As API user, you can end the signing flow by doing a Skip Signers call. All signers that haven’t signed yet, get the status “Skipped” and the package is marked as finished.
Managed identities for Azure resources
eSignatures stores a lot of files while processing documents. When storing files in Microsoft Azure Blob Storage, eSignatures now supports the use of managed identities. Thanks to the managed identities feature, system administrators can use the Azure Role Based Access Control (RBAC) to grant access to the storage account. This way, no credentials are necessary to access the storage.
An added advantage is that you no longer need separate storage accounts to host multiple clients. Managed identities make sure clients only have access to the files they should have access to.
System administrators can configure the managed identities feature in the Configuration Index, under File Storage Settings.
Omit text from signature appearance
The following signing methods place a visual signature image, created by the signer, on a document: manual, manual + eID and biometric. When using any of these signing methods, the following default text is placed on top of the signature image: “Digitally signed by X on behalf of X”, followed by a date and time.
In eSignatures 5.4, system administrators can choose to omit that text so only the signature image is shown on the signed document. Note however, that the text is still stored within the digital signature; it is only removed from the appearance. Also note that any legal notice will also be omitted from the signature appearance.
1.2 Improvements
Retries in case of Callback errors
When a Callback error occurs, eSignatures now retries multiple times to access the external system the Callback URL points to.
By default, eSignatures retries three times in three retry cycles to do the callback. If the error still occurs after the number of retries, the document or package is sent to the poison queue.
System administrators can also choose to customize the retry mechanism in the Worker config file.
Configurable redirect with asynchronous signing
When using an asynchronous signing method, users could already close the signing session and work on other things while the signing continues in the background. Except when a RedirectUrl had been configured in the API. In that case, the Close button was unavailable and users still had to wait for all documents to be signed before being redirected.
In eSignatures 5.4, API users can now configure when the redirect happens: 1) immediately as soon as the user clicks Start signing, 2) after a delay of 5 seconds, or 3) after session when all documents in the session have been signed.
Additional info in Audit Proofs
Audit Proofs now also contain the signer's IP address.
The signer’s IP address is added to the proofs each time a signing event occurs, e.g. start of signing, end of signing, SMS OTP is sent, mail OTP is sent, etc.
1.3 Handled issues
Jira code | Issue code | Description |
---|---|---|
CEP-6675 | 30863 | Signer could not always view package details in Signer Portal. |
CEP-6661 | 31289 | Branding issue in Edit Contact window has been fixed. |
CEP-6560 | 31093 | WYSIWYS finishing issue has been fixed. |
CEP-6528 | / | Branding issue during upload has been fixed. |
CEP-6456 | / | Wrong error message was displayed when QuickSign is disabled. |
CEP-6345 | / | Connective logo has been removed from console. |
CEP-6287 | / | Search issues in Theme section have been fixed. |
CEP-5393 | / | Azure Webjob shutdown issue during asynchronous signing has been fixed. |
CEP-5286 | / | Signed document download issue has been fixed. |
CEP-5066 | / | Marker issue has been fixed. |
1.4 Known issues
eSignatures 5.4.0
Jira code | Issue code | Description |
---|---|---|
CEP-6651 | / | QuickSigning multiple fields in a single document while the end document flow has been initialized currently causes Deadlock logs. |
CEP-6589 | / | When the status of a document is “Ending” it’s currently not possible to view its details. |
eSignatures 5.3.0
Jira code | Issue code | Description |
---|---|---|
CEP-5944 | / | Itsme scrolling is not as smooth as expected on Safari on iPhone. |
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. |
eSignatures 5.2.0
Jira code | Issue code | Description |
---|---|---|
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 |
---|---|---|
/ | / | 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 portfolios is 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, each document within the package must be signed individually, which means QuickSigning is not supported.
- 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.4.0, consult the Connective - eSignatures 5.4.0 - Installation Documentation to learn how to upgrade it to version 5.4.