Updated version of GrSciColl permissions - roles and scopes

[ManonGros]

The permissions were originally defined here: "Add scopes for GrSciColl users": #179

But we now have four challenges:

• merging entities (Implement service to merge duplicate GRSciColl entities #255): who can merge what?
• take into account the specificities of iDigBio: Allow iDigBio editors to merge GRSciColl entities #292 and Improvements in GrSciColl scopes #296: ideally iDigBio would remain in charge of taking care of their own records.
• the "country/node" use case: where some countries are in touch with the Collections community and would like to add an maintain institution and collection entries on behalf of institutions.
• creation logic (review create logic registry-console#366): who can create what?

We discussed many possibilities. For the purpose of the discussion, I tried to summarise some of the ideas in the following models (feel free to write a "new" model below if needed):

Model 1: super editor role + iDigBio is just an admin

In this case, we trust other admins to not edit iDigBio entry.

GRSCICOLL_ADMIN:

• Can edit everything
• Get a warning when editing IH entry in the UI
• Can merge anything (except with IH records - they would have to remove one IH identifier first)

GRSCICOLL_EDITOR: (we assume only institution or collection scope available)

• Cannot edit IH_IRN identifier
• Cannot edit iDigBio identifier
• Get a warning when editing IH entry in the UI
• Cannot edit machineTag
• Can create and edit all staff
• Can merge entries as long as they have permission to both (except iDigBio entries)
• Cannot create new institution
• For everything else, editor's right will depend on a scope:
  • If given institution permission:
    • can edit existing institution
    • can create and edit related collections
    • can add staff to institution and related collections
  • If given collection permission:
    • can edit existing collection
    • can add staff to collection

GRSCICOLL_SUPER_EDITOR (I assume we still have scopes here but we could also do without where this user is essentially a GRSCICOLL_EDITOR with scope for all institutions)

• Can create institutions
• Is given permission to edit institution created
• For everything else, same as GRSCICOLL_EDITOR

Example of admins: GBIF secretariat, iDigBio, maybe one or two members of the editorial Board
Example of editor: Collection manager, institution representatives, etc.
Example of super editors: Country representatives/Node managers, etc.

Model 2: super editor role + iDigBio editor role

In this case, we trust other admins to not edit iDigBio entry.

GRSCICOLL_ADMIN:

• Can edit everything except:
  • iDigBio identifiers and tags
  • delete iDigBio entries
• Can merge anything except iDigBio and IH records (in case of two IH records, they would have to remove one IH identifier first)
• Get a warning when editing IH entry in the UI

IDIGBIO_EDITOR:

• Can do the same as GRSCICOLL_ADMIN for iDigBio records.

GRSCICOLL_EDITOR: (we assume only institution or collection scope available)

• Cannot edit IH_IRN identifier
• Cannot edit iDigBio identifier
• Get a warning when editing IH entry in the UI
• Cannot edit machineTag
• Can create and edit all staff
• Can merge entries as long as they have permission to both (except iDigBio entries)
• Cannot create new institution
• For everything else, editor's right will depend on a scope:
  • If given institution permission:
    • can edit existing institution
    • can create and edit related collections
    • can add staff to institution and related collections
  • If given collection permission:
    • can edit existing collection
    • can add staff to collection

GRSCICOLL_SUPER_EDITOR (I assume we still have scopes here but we could also do without where this user is essentially a GRSCICOLL_EDITOR with scope for all institutions)

• Can create institutions
• Is given permission to edit institution created
• For everything else, same as GRSCICOLL_EDITOR

Example of admins: GBIF secretariat, maybe one or two members of the editorial Board
Example of iDigBio editors: iDigBio people
Example of editor: Collection manager, institution representatives, etc.
Example of super editors: Country representatives/Node managers, etc.

Other ideas not integrated in these models

• Have country scopes instead of the GRSCICOLL_SUPER_EDITOR
• Have rights instead of GRSCICOLL_SUPER_EDITOR (editor + right can create institution)
• Have rights instead of IDIGBIO_EDITOR (iDigBio = admin + right to edit iDigBio)

[MortenHofft]

Here is an idea for a third model. It isn't entirely thought through, so perhaps I'm just adding confusion.

---

GRSCICOLL ADMIN
can do absolutely anything

GRSCICOLL AUTHOR
Can do everything an editor can do + create institutions within their scope (national, institutional). And when creating an institution, then the institution is added to the users scope

GRSCICOLL EDITOR
Can modify entities in their scope (national, institution) and create collections within existing entities. With one important exception, they cannot edit machine tags.

Add machineTag namespaces to user profiles
For an editor to edit machine tags you need to have access to the namespace. So the user profiles is extended with namespaces. As it was intended 10 years ago.

Issues
Of course this would not be enough to control identifiers the way above models do. But perhaps identifiers should either be open for all with entity access or closed to anyone but admins. And then we use the machine tags for things where a subset have access. Such as iDigibBio.recordSetQuery/iDigibBio.collectionUUID.

Alternatively we also add identifier types to the user profile. So that an idigbio editor will get a special identifier type they can control.

In this model someone from iDigBio (or a future partner), could control their own machine tags, while leaving the core entity to be edited by the collection owners.

[CatChapman]

This is great, thank you all so much!

My primary concern right now is this:

Would an iDigBio editor be able to create new institutions/collections? It's not completely clear to me. I think it's necessary at least for collections, especially since I've already had to create a new collection at least once.

Having machineTags be restricted is a VERY good idea, so I'm glad that's covered here.

[timrobertson100]

Would an iDigBio editor be able to create new institutions/collections? It's not completely clear to me

This is a requirement, so needs to be possible. The same is true for a scoped editor designated as the administrative agent for a country or institution.

The third model looks like the correct level of granularity to me, as it has a simplicity that should prove robust for future development; any more intricate and we could find we're scared to make changes.

The people assigned those clear roles would also be able to also review and apply changes offered through an open "suggest an edit" where their scope allows it.

I feel we should capture all changes somehow as well, even if it is just a global log of changes applied (i.e. not automatically revertable, but can be searched and data extracted to be manually reapplied).

[ManonGros]

Consensus: we will have three roles + the suggest a change (gbif/registry-console#376) + audit trail (see suggest a change).

Some things to keep in mind / potential issues with this model are the following:

1. Anyone able to edit identifiers can delete the IH identifiers and unlink entities from IH. This is ok for institutions but this is a problem for collections because the synch will create a new one.
   We should use machineTags instead if identifiers for the synchronisation and there should be a way for users to say "this institution should be disconnected from IH".
2. GRSciColl offer fields that aren't available in IH. So editors might still want to edit IH-linked entries. So we can't just prevent editors from editing IH-linked entries.
   Some solutions could be show a warning message or only enable to edit fields that won't be over written.
3. iDigBio should still be able to edit/add machineTags.
   They should either be admins or have the tag namespace as scope in their names.
4. We haven't taken into account staff. I suggest that everyone can create and edit staff. Is that ok?

For that model to happen, we need:

• implement country scope (GRSciColl permission - implement country scope #341)
• implement audit trail and suggest a change (Suggest a change registry-console#376)
• use machineTags instead if identifiers for the synchronisation (GRSciColl - use machineTags instead of identifiers for IH synch #342) and make it possible for users to request disconnecting institutions from IH (Update GRSciColl UI to reflect the way we now use machineTags and identifiers registry-console#379)
• allow to add the machineTag namespace as scope in the registry UI (add link to issue here)
• implement API call to find all the users that can edit a given entity (Be able to sort users by Roles #330)

[marcos-lg]

All the changes of the registry API are deployed