1. Release Notes 5.4.2
Release date: 2019-10-29
1.1 New features in eSignatures 5.4.2
Contact groups
Contacts can now be grouped into contact groups, which can be added to a signing field just like a singular contact. Any contact who belongs to the contact group is able to sign the signing field. It doesn't matter which contact signs it, as long as it's a member of the group. Note however that as soon as one member has signed, the others no longer can. Once a document has been signed by a member of a contact group, all members will be notified.
Sharing of contacts and contact groups
Contacts and contact groups can now be shared among users. This way, when you create a new user in eSignatures you can immediately provide them with all the required contacts.
In previous versions, a new user always had to create their contact list all manually.
Automatic creation of contact upon self-registration
When a user signs up for an eSignatures account, a corresponding contact is now automatically created.
This way, users no longer need to create their own contact manually. The only action they still need to take is complete their contact info with a phone number (in case they want to sign with SMS OTP) and a Unique Identifier (in case they want to use Mandated Signer Validation combined with eID or BeLawyer signing).
Different types of stakeholders in the API
To reflect the contact groups feature in the API, three types of stakeholders have been introduced, which can be passed in the Set Process Information (v3.1) call and in the Instant Package Creation call. A stakeholder can now be a person (default), a person group or a contact group. When using person group or contact group, one of multiple persons will be able to sign the package for the entire group.
New API call: Get ContactGroups
This call allows API users to retrieve the list of contact groups that are currently used in the eSignatures WebPortal, and their corresponding code.
The ContactGroup code can be entered as Request parameter when doing a Set Process Information (v3.1) call or Instant Package Creation call. Any member of the requested contact group will be able to sign the package for the entire group.
Multiple OpenID Connect signing profiles
Administrators can now configure multiple OpenID Connect signing profiles in the Config Index. As a result, multiple custom signing types can be offered in eSignatures.
Notification Hub
The Notification Hub will enable eSignatures to use third-party sms and email providers in a flexible way.
Important: this feature is reserved for future use and must not be enabled or configured in eSignatures 5.4.2, even though it is available in the Configuration Index.
1.2 Handled issues
Jira code | Issue code | Description |
---|---|---|
CEP-5494 | 29381 | Login fields were not filled automatically when using password managers. |
CEP-6739 | 31497 | Adding phonenumber to receiver issue has been fixed. |
CEP-6731 | eSignatures could not connect to SMTP server with NTLM and GSSAPI auth methods | |
CEP-6751 | / | iDIN is still available as signing method even though mandated signing based on nameandbirthdate is enabled and the contact’s info doesn’t contain a birthdate. |
CEP-6795 | / | Correction in API documentation |
CEP-6738 | Contacts could not be edited in signing field creation modal. | |
CEP-6323 | / | XML signing issue has been fixed. |
CEP-6398 | / | Changes to the “Unselected colour” setting in Theme > Portal > After login > Big tabs > Background can’t be saved. |
CEP-6515 | / | WYSIWYS message error has been fixed. |
CEP-6674 | / | Favicon issue in Theming has been fixed. |
CEP-6722 | / | Error message color issue in Theming has been fixed. |
CEP-6743 | / | Document group theming issue has been fixed. |
CEP-6749 | / | OIDC signing error message has been added to the log when response info is not in the configured format (JWT or json) |
CEP-6750 | / | Default document theme issue when using API v2 has been fixed. |
CEP-6753 | / | Issue when creating a contact that contains a phone number during the addition of a receiver has been fixed. |
CEP-6768 | / | Disabling legal notice issue has been fixed. |
CEP-6783 | / | EmailOTP case sensitive issue has been fixed: EmailOTP is no longer case sensitive. |
CEP-6789 | / | Input field text wasn’t themable. |
CEP-6744 | / | Multiple OpenID Connect profiles could not be loaded in clean install. |
CEP-6808 | / | Preselecting signing methods issue has been fixed. |
CEP-6809 | / | Error messages have been improved. |
CEP-6813 | / | Correct error message is now returned when creating a draft document with invalid document group in API v2. |
CEP-6816 | / | Matchid issue when adding a signer without unique identifier has been fixed. |
CEP-6820 | / | Specific signing order issue with EmailOTP and SMSOTP has been fixed. |
CEP-6824 | / | Preview issue with checkboxes/marks in Theming has been fixed. |
CEP-6823 | / | OpenID Connect upgrade issue has been fixed |
CEP-6816 | / | While matchid is enabled it is possible to add a signer that does not have a unique identifier. |
CEP-6844 | / | Unique identifier issue has been fixed. |
CEP-6767 | / | OpenID Connect profile that was only linked to a package in final state could not be deleted. |
CEP-6766 | / | OpenID Connect profiles are now sorted alphabetically. |
CEP-6764 | / | OpenID Connect settings visibility issue has been fixed. |
CEP-6763, CEP-6762 | / | OpenID profile creation issue has been fixed. |
CEP-6726 | Some special characters were not displayed in Config Index. | |
CEP-6542 | Mouse over functionality over Big tabs has been removed. | |
CEP-6519 | Download unsigned doc issue on iOS has been fixed. | |
CEP-6452 | / | ‘ |
CEP-6095 | / | Package title field is now required. |
1.3 Known issues
eSignatures 5.4.2
Jira code | Issue code | Description |
---|---|---|
CEP-6870 | / | Configuration layout of OIDC field should be improved. |
CEP-6874 | / | Inconsistent casing of query parameter “SessionId” in case of invalidToken. |
CEP-6883 | / | PersonGroup signer is not displayed in package summary. |
CEP-6884 | / | Wrong PersonGroup icon is displayed in signing field. |
CEP-6288 | / | Branding issue: saving a change in one of the subtabs navigates to 1 tab above. |
CEP-6736 | / | Google Drive issue during upload. |
CEP-6838 | / | Some extensions are mentioned twice in the custom files list when selecting a favicon in Theming. |
CEP-6854 | / | Signing method is not visible in draft package in combination with OIDC. |
CEP-6859 | / | Contact groups/Person groups WYSIWYS svgs not found when using azurefilestorage. |
CEP-6865 | / | When upgrading from 5.0.7 the Environment settings page prompts to save without having made a change. |
CEP-6878 | / | Personal contacts are missing during creation of contact group. |
eSignatures 5.4.1
Jira code | Issue code | Description |
---|---|---|
CEP-6651 | / | QuickSigning with multiple signing fields leads to deadlock while package is ending |
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.4 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.2, consult the Connective - eSignatures 5.4.2 - Installation Documentation to learn how to upgrade it to version 5.4.