1. Release Notes 5.5.0
Release date: 2020-01-13
1.1 New features
Add approvers
In eSignatures 5.5, you can add one or more approvers to the signing flow. This way, documents are first sent to an approver, and only sent to the required signers after the document has been approved.
Contact groups can also assume the role of approver. The member of the contact group who first opens the document will be able to approve for the entire contact group.
Reassign to another signer or approver
If an approver or signer feels they are not the right person to handle a document, they can reassign it to another approver or signer.
Note that the administrator must enable this feature in the Config Index before approvers or signers are able to reassign.
Itsme® as Advanced Electronic Signature
Itsme® was already available as Qualified Electronic Signature (QES). QES signatures are the most advanced and secure type of electronic signatures, but also the most expensive one.
As of eSignatures 5.5, customers who don’t necessarily need QES signatures can use itsme® as advanced electronic signature through OpenID Connect.
Note that you need to request the itsme® Login service at itsme® to start a configuration.
Possibility to disable one-time URLs
In eSignatures 5.5, administrators can choose to disable the use of one-time URLs (OTU). By disabling OTUs, signing and approval URLs don’t expire after a user has clicked them once.
Note however that it is strongly recommended to keep using OTUs. They are a security measure and allow eSignatures to be used in the safest possible way.
Also note that whenever an unsecured URL is used to sign a document, a mention will be added to the Audit proofs (provided the Audit proof setting is enabled).
Configurable interface languages
Administrators can now configure in the Config Index in which languages the eSignatures interface must be available.
Six new interface languages
The eSignatures interface is now available in six additional languages:
- Norwegian (Sami and Bokmal)
- Finnish
- Swedish
- Danish
- Polish
- Latvian
These languages are not activated by default, but administrators can enable them as mentioned above.
1.2 Improvements
Logical sorting of approvers, signers and approvers
Approvers, signers and receivers are now displayed in a logical order in the Document Details in the WebPortal.
- Receivers are always sorted alphabetically by last name, then by first name.
- Approvers/signers are sorted based on the approval/signing flow defined by the initiator, either in the WebPortal or in the API:
- Parallel: approvers/signers are always sorted alphabetically by last name, then by first name.
- Sequential: approvers/signers are sorted in the defined order.
- Complex: approvers/signers are first sorted in the defined order. If multiple approvers/signers may approve/sign during the same step of the flow, they are sorted alphabetically by last name, then by first name.
In the face to face signing modal, signers are sorted alphabetically by last name. If multiple signers have the same last name, they are sorted by first name.
1.3 Handled issues
Jira code | Issue code | Description |
---|---|---|
CEP-6978 | 31867 | Notification suppression issue when revoking document in API v2 has been solved. |
CEP-6893 | / | When you changed the file names of the documents you’ve uploaded to the WebPortal, and then added additional documents, the names of the already uploaded documents were reset to their original values. |
CEP-6943 | 31830 | DocumentGroupCode was not retrieved by Get Package Status call. |
CEP-6983 | / | After the first of multiple signers has signed, the subsequent signer only saw the fields they needed to sign in the WYSIWYS, and no longer had an overview of all the signing fields. |
CEP-7070 | / | Signer adding issue when choice of signing is disabled has been solved. |
CEP-6995 | / | iDIN QuickSigning issue has been solved |
CEP-6954 | 31897 | Error message when entering an invalid mandatedSignerValidation value has been improved. |
CEP-6931 | / | Speed issue when creating duplicate contacts has been solved. |
CEP-6884 | / | Wrong PersonGroup icon was displayed in signing field. |
CEP-6840 | / | Reset to default issue in Theming has been solved. |
CEP-6815 | / | When setting an expiry date the input boxes were not aligned. |
CEP-6651 | / | QuickSigning with multiple signing fields lead to deadlock while package was ending. |
CEP-4632 | / | Pagination issue has been solved. |
CEP-6870 | / | Configuration layout of OIDC field has been improved. |
CEP-6736 | / | Google Drive issue during upload has been solved. |
CEP-6854 | / | Signing method was not visible in draft package in combination with OIDC. |
CEP-6859 | / | Contact groups/Person groups WYSIWYS svgs were not found when using azurefilestorage. |
1.4 Known issues
eSignatures 5.5.0
Jira code | Issue code | Description |
---|---|---|
CEP-7078 | / | It’s currently not possible to sign with FranceConnect using eIDAS3 |
CEP-6352 | / | Translation migration issue. |
CEP-6422 | / | Error message when trying to mailOTP sign a document that has already been removed must be added. |
CEP-7170 | / | Signers should be displayed in alphabetical order in the face to face signing modal. |
eSignatures 5.4.3
Jira code | Issue code | Description |
---|---|---|
CEP-6897 | / | When using Audit proofs, a Worker issue occurred when packages were set to finished. |
eSignatures 5.4.2
Jira code | Issue code | Description |
---|---|---|
CEP-6874 | / | Inconsistent casing of query parameter “SessionId” in case of invalidToken. |
CEP-6288 | / | Branding issue: saving a change in one of the subtabs navigates to 1 tab above. |
CEP-6865 | / | When upgrading from 5.0.7 the Environment settings page prompts to save without having made a change. |
Signatures 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 single document must not contain more than 30 signing fields.
- 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.
- PDF portfolios are not supported. This is because a PDF portfolio may contain a wide range of file types that are not supported by eSignatures. A PDF portfolio may for instance contain e-mail messages, spreadsheets, CAD drawings, PowerPoint presentations, etc. As a result, a signer will only be able to view and sign the PDF cover sheet, and not the actual files the Portfolio contains, which renders the entire Portfolio invalid.
- 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
(Note that these limitations do not apply when using itsme through OpenID Connect)
- 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.
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.5.0, consult the Connective - eSignatures 5.5.0 - Installation Documentation to learn how to upgrade it to version 5.5.