Create signature roles table

[signebedi]

In the user model, let's represent form approval as a table, which allows admins to represent complex chains for form approval and routing. This can define whether a group has veto power or is just notified at a certain stage; it can also define whether to do group-based routing (eg. when group 1 submits a form, route it to group 2 for approval and notify group 3) or whether to apply it to all users at the outset (eg. anyone who submits a form, route it to group 2 for approval, etc.). Additionally, we can define whether a specific user in relation to the user submitting the form gets a say in its approval. We can define what happens when a form is approved, returned / pushed back, or denied. For example, does a returned form go back to the initial submitter, or the last reviewer? This is also complicated because reviewers and approvers will likely be represented in the form data (eg. the document database) but the rules will be defined, at least under this system, using a relational database table. Bit of a frankenstein approach but I think it will work.

Originally posted by @signebedi in #22 (comment)

[signebedi]

[api] add form approval route
The idea here is that approvals can be passed and handled using the rest API. They should not require data changes as these are just updates in the metadata, but should be given a journal entry. This allows us to reconstruct eg. that "User X approved/disapproved/returned form at TIMESTAMP".

[signebedi]

[api] add form signature route
The idea here is that signatures on form submissions can be passed and handled using the rest API. They should not require data changes as these are just updates in the metadata, but should be given a journal entry. This allows us to reconstruct eg. that "User X signed form at TIMESTAMP".

[signebedi]

See a009180