CARL Source
Implementation of the electronic signature
System > Electronic signature > Implementation of the electronic signature

The implementation of the electronic signature requires several operations to be fully usable.

 

IN THE DICTIONARY setting

As default, no electronic signature is defined in the application.
It must be enabled for each field or transition that requires this operation. For this purpose, a new option has been added in the [Dictionary] and [Status workflows] functions.

 

Creating a signature on an attribute

  1. In the dictionary function, access the desired object.

  2. In the [Attributes tab]:
    • Search for the corresponding attribute
    • check the "Signature" box
    • Save or confirm.

From now on, as soon as the field concerned is changed by a user, an electronic signature will be requested when saving this change.

Not all attributes allow the electronic signature to be enabled.

For example, the fields that are not defined as persistent (in particular, those with an empty table or column), the fields related to the status (changed by transitions), and certain field types (including SET, LIST and COLLECTION).

 

Creating a signature on a transition

  1. In the status workflow function, choose the workflow for the object concerned.

  2. In the table [list of statuses], choose the initial state of the targeted transition.

  3. In the [Transitions] table, check the "Signature" box on the line corresponding to the targeted transition.

  4. Save or confirm.

From now on, as soon as the targeted status change is made by a user, an electronic signature will be requested to confirm this transition.

The workflow of an object can also be found from the dictionary, on the [General] tab of the object's details.

Not all transitions allow the electronic signature to be enabled.
Only transitions dependent on a user's action can be signed. In particular, transitions marked as automatic cannot be signed.

 

adding to the list of reasons

When a user needs to sign changes, they have to choose a reason from a drop-down list.
The possible reasons have to be defined beforehand, depending on the contexts in which the signatures will be requested.

The list of reasons can be updated in the [List of values] function from the SIGNREASON list.

 

authorize viewing signature access

As default, no user is allowed to view the signature history.
This function should be reserved for certain profiles such as super users and administrators.

The access right to this function is defined in the user's [Profile].
This read right can be set in the [Functions] tab, under the [System \ Viewing signatures] entry in the tree structure.