...
Note: This 'enhanced' security model can be used in advance of creating services for defining roles: We can define the currently required roles 'in the backend' and later add services and UIs for defining new roles.
Workflow Model
Should the approval process be represented on the server side (e.g. in the repository)?
How does *approval state* map to *permissions*?
...
Tier 1 Approval Process
Here the user signs the Tier 1 agreement upon account creation and is added to a "Tier 1 group". The group has the Download role for all Tier 1 data layers.
"WF" refers to an envisioned workflow system which knows the approval workflows and can tell each participant what its next step is.
Tier 2 Approval Process
This approval requires two hurdles, the Tier 1 agreement plus a new agreement which may be specific to the requested layer. Upon approval Synapse adds the User to the Access Control List for the Layer.
Tier 3 Approval Process
Here we have the added complexity of an external IRB. An "IRB daemon" is added to send approval requests to the IRB and to listen for replies. The interaction with the user is asynchronous: While waiting for approval the user may do other things (though not access the requested layer). Finally she receives an email saying the request was approved.
Some open questions:
- How does Synapse know not to wait for any more steps, once it gets the final reply from WF (the workflow is not yet done)?
- When Synapse asks "next step" can it refer to a specifc workflow instance (and avoid getting an approval step for some other user)?