Order handling

Update signers

You can only remove signers that are pending or queued.

If you are using the API, remember to include existing pending and queued signers, otherwise, they will be removed from the signing list. You can add more signers to an order by including them in the request.

All signers have a priorityGroup value, where the lowest number (1) has the highest priority and vice versa. The default priority for a new signer is the current highest pending priority. The priority of a new signer can not exceed the highest pending priority.

GUI users can only change notification settings when creating the order, but API users can change the notification setting on the update signers request, by including the notifiyAllSigners: true in the option parameter. 

Signer status

Signers and solicitor involved in a specific errand are stored the requested_signers table in the database. The current status of a signer can be found in the column action, where the value corresponds to the following state:

  • 1 - Signer state is pending. This means the user is currently requested to sign the errand. The user can also reject the errand
  • 2 - Signer state is signed. The signer has signed the errand and the timestamp for when it was signed can be found in the  column action_timestamp
  • 4 - Signer state is rejected. The signer has rejected the invite to sign, and the timestamp for when it was rejected can be found in the column action_timestamp
  • 8 - The user has created the errand, aka the user is the errand solicitor
  • 16 - Signer state is queued. When all signers with higher priority has signed (or rejected), the queued signer will change to pending state (1) and will get the invitation to sign