Creating a signature package with separate signers and a different sender still shows the sender's name in the list of signers in the signature box placement web GUI
Thursday, March 23, 2023 at 07:54pmHello all,
My goal is to enable an admin person to easily assist with a signature package (they will be the sender) but where the admin person is strictly the sender and will never be a signer.
I am exploring the following mechanism for creating signature packages using the OneSpan REST API. This is for documents for which we do not yet have templating set up, so we need the OneSpan web GUI signature box placement UI.
Using the REST API, we create a signature package with, say, two signers A and B and one sender C. We create the package in draft mode.
The sender C (the admin person) can then go directly to the signature package using the URL we know at this point (since we have the package id), log in, leave all signature package details as is (the signers, the authentication methods, etc.), click "Next", and then get to the signature box placement web GUI to place the signature boxes.
This all works fine in my tests.
The issue is that in the signature placement web GUI, there are three names on the left available to drop into the document to create signature boxes: signer A, signer B and sender C.
It seems strange and incorrect to present the sender's name as an option to use for creating signature boxes when they are explicitly set to be a sender only and not a signer.
I am wondering if there is any way to have only signer A and signer B's names shown in this scenario in the signature box placement web page.
Thanks!
-Tim
Reply to: Creating a signature package with separate signers and a different sender still shows the sender's name in the list of signers in the signature box placement web GUI
Friday, March 24, 2023 at 08:24amHi Tim,
Thanks for your post! From your description, you meant the sender name in the recipient list on designer page, right?
If that's the case, you have two approaches to follow:
(1)Either contact our Support team and update your designer profile as:
"rolePickerSender" : false
(2)Or since you are using RESTful API, add this attribute when building the transaction JSON:
{
"name": "Example Transaction",
"status": "DRAFT",
"data": {
"senderVisible": false
}
......
}
This approach will also hide the sender from the recipient list in the transaction detail page (the page with all transaction details before you clicked "NEXT").
Duo
Reply to: Creating a signature package with separate signers and a different sender still shows the sender's name in the list of signers in the signature box placement web GUI
Monday, March 27, 2023 at 08:46amHi Duo,
Thank you so much!
Yes, we are using the RESTful API to create DRAFT status signature packages and I am referring to the sender name in the recipient list on the package designer page where signature placement boxes are dropped onto a preview of the document.
I have tested adding to our REST call the custom data field senderVisible set to false as mentioned:
"data": {
"senderVisible": false
}
This works exactly as desired, where the sender name is now no longer displayed on the designer web page UI. Only the two signer names are displayed on the left.
Could the senderVisible field be added to the list of request payload custom transaction data fields documented here:
https://community.onespan.com/documentation/onespan-sign/guides/feature-guides/developer/custom-transaction-data
or in some other place where I could find all the supported custom data fields?
Regards,
Tim
Reply to: Creating a signature package with separate signers and a different sender still shows the sender's name in the list of signers in the signature box placement web GUI
Monday, March 27, 2023 at 09:01amHi Tim,
Yes, you are exactly adding custom transaction data, just this attribute name is recognized/reserved by OneSpan Sign. Other reserved examples could be "origin", "version", "currentSignerProgress", "overallProgress". Custom transaction data is a place to store extra data related to your integration (e.g. transaction/signer reference ID in your system), just try to avoid those reversed attribute names and you can store any custom data, for example:
"data": {
"senderVisible": false,
"customField1":"text value",
"customField2":false
}
Duo