Roles RFC
In PubSweet we need :
- roles that enable a team to work on a knowledge asset
- global roles that enable system wide access
- global roles that enable system configuration
Teams
The PubSweet philosophy is that teams can fluidly form around an asset to improve it. The following are important foundation principles.
-
there are an arbitrary number of roles per asset
One org may require 20 people to work on an asset, another there might just be one person. -
role names are always bespoke
It is important to remember that there is no standard way of naming roles in knowledge production (eg. publishing). An editor is not an editor is not the editor. -
roles often require their own components
Roles may need access to some components and be excluded from others. For example, in the case of journals, an author needs the editing component, but quite probably they will need to be excluded from the review component. -
roles requirements can change over time
A role may need to come into play at a certain moment but be passive at others. A reviewer, for example, may only be required to perform their task at a certain time, and an author may not be permitted to edit an article while it is being reviewed.
Features
This suggests at least the following features:
- roles are set globally
- role are managed within a system configuration
- role names are set by the user (via sys config)
- there are no limits on the number of roles
- roles apply to, and are fulfilled, on the asset level
- different roles may have identical permissions
- roles permissions allow or deny access to components
- assets have states
- there may be multiple states per asset
- states names are arbitrary
- state names are set by the user (or component programmer)
- events may be triggered when assets enter or leave a given state