specs/models/M_APP_VER_STEP_SIGN

Signature Step

A Signature Step (Signature Form) is a variant of a Form Step that allows users to add an e-signature within an app running in the Tulip Player.

An e-signature can be:

  • Badge ID
  • LDAP Username/Password: If an organization uses LDAP to authenticate users in Tulip, then a user must input their username and password from their LDAP directory.
  • SAML Username/Password: If an organization uses SAML to authenticate users in Tulip, then a user must input their username and password from their SAML directory in a popup window.

An operator cannot proceed to the next step of an app until a qualified user has filled out the e-signature. The signatures cannot be autofilled- they must be signed via the permitted credentials each time they are presented.

An app builder can add one or multiple Signature Steps to an app.

Each E-signature from a Signature Step is recorded in a separate column in the list of Completions.

Fields

<table> <tr> <td><strong>Name</strong> </td> <td><strong>Description</strong> </td> </tr> <tr> <td>Submission Rules </td> <td>The types of users that can sign the Approval Step. Options: <ul> <li><strong>Any User:</strong> Any operator can add a signature.</li> <li><strong>Any operator besides app executor: </strong>Any operator can sign off EXCEPT the one that is currently logged in.</li> <li><strong> Operator executing app:</strong> Only allow the currently logged-in operator to add a signature.</li> <li><strong>Specify a list of allowed users: </strong>Choose from a list of all users and operators in a Tulip account. Multiple users allowed.</li> </ul> </td> </tr> <tr> <td>Approved Submitters (optional) </td> <td>A list of Tulip users that are approved to sign the app in the Player </td> </tr> <tr> <td>Signature Timestamp </td> <td>The timestamp is applied based on when the Tulip user signed the Signature Step before the app was completed </td> </tr> <tr> <td>Signer </td> <td>The full name, user ID and profile image of the user that signed the Signature Step before the app was completed </td> </tr> <tr> <td>Other </td> <td> <ul> <li>A required “Text” input widget can be used by the app developer to enforce signer to manually write reason for signature </li> <li>A “Dropdown” input widget with a list of options can be used to enforce signer to choose reason for signature </li> </ul> </td> </tr> </table>

Tests

IDName
QA-T106Signature Step : 01 - A signature form can be created
QA-T107Signature Step : 02 - Signature widgets cannot be deleted from a signature form step and additional ones cannot be created
QA-T108Signature Step : 03 - Signature form should allow any user to submit it when configured so
QA-T109Signature Step : 04 - Signature form should allow only the current user to submit it when configured so
QA-T110Signature Step : 05 - Signature forms should only be submittable a single time per process run
QA-T791Widgets - 12: Widget Shift+Drag and Option+Drag Modifications

Requirements

IDRequirement
PLAT-8869 (856)Continuous signing sessions require two signature components for first signing but only one (secret) component for subsequent signings.
PLAT-8891 (816)The manifestation of an electronic signature should contain the user's full name, date & time, meaning of signature human readable format; the record itself should contain these elements.
PLAT-8893 (815)Provide an unalterable and enduring link between records and their associated electronic signatures; they cannot be removed, changed, copied, transferred or deleted.
PLAT-8902 (817)Ability to require multiple electronic signatures for a record. Ie co-signer, verifier, etc.
PLAT-8904 (820)Electronic signatures have to be secured and not allowed to be falsified. They can only be used by their genuine owners.
PLAT-8905 (819)All electronic signatures have authenticate the signatoree by two distinct elements (e.g. username and password; at least one being a private element), or a secure unambiguous biometrics system that cannot be used by anyone other than their genuine owner.
PLAT-8906 (818)If more than one signature is required the electronic signature shall capture the role of each signatoree. Eg. trainer, verifier, co-signer, etc.