Decide which user roles there should be

[stefandesu]

Related to #44.

We need to think about which kinds of user roles make sense for jskos-server and what each role is allowed to do.

[nichtich]

I'd call the fine-grained rights "scopes" because we may later introduce scoped tokens to jskos-server. Roles may be defined on top of these scopes

Some scopes to start with: (not taking into account right access because all content is readable by anyone for simplicity):

• write_mappings : create, modify, and delete your own mappings
• admin_mappings: modify and delete all mappings
• write_annotations : create, modify, and delete your own annotations
• admin_annotations: modify and delete all annotations

[stefandesu]

I'm not sure about scoped tokens (because I feel like it would make the whole process even more complicated if jskos-server had its own tokens), but I agree about using scopes and roles as a collection of scopes.

[nichtich]

Scoped tokens might not be required but I'd still call the rights "scopes". We we'll then have

• identities (individual identity URIs such as https://orcid.org/0000-0002-7613-4123)
• identity providers (orcid, github, ldap-vzg...)
• scopes (write_mappings, write_annotations, write_concordances...)
• roles (can be configured freely in addition to some hard-coded roles)

Both identities (only selected users) and identity providers (all users that have an identity from selected providers) can be used to define roles (e.g. orcid => "editor"). Each role has a list of scopes.

As discussed at #48 there is a special user role "self" that only applies in relation to your own records, this makes it a bit more complex. Maybe there is an easier way to model this.

[stefandesu]

For #48, we would need a separate config file (in JSON format) in addition to the .env file anyway, so the role definitions can be added there.

[nichtich]

@stefandesu this can be closed, no? It seems to predate current way of configuration of actions.