Communities: additional permission level

[tmorrell]

Is your feature request related to a problem? Please describe.

For a large community you may want to have a number of reviewers work on submissions, but not provide them permissions to edit all records in the community. The current community permissions are "Reader", which has no ability to manage community requests and "Curator" which has permissions to edit every record in the community. A permission level in between these two would provide more flexibility.

Describe the solution you'd like

A new "Reviewer" permission that provides edit access to community draft records. This would provide edit access to all community drafts, but not published records.

Describe alternatives you've considered

We have not been able to come up with alternative options for large community record management.

[zguillen]

Would love to see this (linking my project's related issue for my own sanity's sake MSD-LIVE/issues#139)

[fenekku]

thinking out loud here / things to investigate

• Can the reviewers publish the record or only edit?
• How would the reviewers indicate that they've reviewed? For that matter, we don't have this GitHub-like "reviewed" affordance currently.
• Should they even be able to publish the record, given the "lock-out" problem: once they've published they can't edit the record back to fix a mistake they suddenly realized?
• Is the "edit/update" functionality using/allowing for distinctive permissions in the implementation (i.e. is a new Community role with permissions enough or is some change at update/edit level necessary?)
• Would subcommunities / breaking the large community up, make sense for these situations instead?

[tmorrell]

All good questions!

• For our use case only edit would be the best, but I'm not sure what would be easiest to implement or if that would be the best for everyone.
• We're currently having reviewers tag a record as completed in the comments, and then we pull out everything in the queue to an external table https://caltechlibrary.github.io/irdm-queue-portal/. Having this integrated into the community would be better, but it's a larger project than just adding the permissions.
• That's one reason I prefer the "edit-only" option.
• To investigate
• We're using communities to enforce curation on all our records in the repository, so using sub-communities would be cumbersome. We'd have to move all published records out of the main community and into the more restrictive published community. I think it would be possible, but seems more complicated and confusing

[zguillen]

Our use case was a bit simpler to describe but probably more difficult to implement UI-wise. Our users have requested the feature to share a draft they have started for another person to co-edit with them. They would be limited to sharing with someone already in the community the draft belongs to (we enforce all records to be assigned a community). Also, once a draft has been shared with person B, that draft should be listed on the Uploads section of person B's dashboard. All co-editors would have the same permission on the draft (to publish, delete, etc.)

[lnielsen]

Today there's an issue in that you cannot share by link directly from the deposit form (this is a bug), otherwise you could have shared the draft via a secret link with co-works who would get the permission to edit or just preview the draft. You can do it from the published record, but not the draft yet.

CERN CDS team is working on allowing share with user/group instead of only by secret link today.

The basics is there, but the integration into the list of uploads is a bit harder I think.

[lnielsen]

Other roles that I've heard requested:

• Submitter (i.e. can submit to community, but not see restricted records)
• Reviewer (can see and comment on requests, but not necessarily take actions)
• Annotator (can perform annotation actions on a record, but not edit the record)

Overall, the easiest might be to have configurable roles per instance with some good defaults.

[ugswork]

As @lnielsen had mentioned, I needed to add an access level 'Reviewer (can see and comment on requests, but not necessarily take actions)'. I have it working and the link to code is in ugswork/access_level@c555d0d#diff-ff296616e161972069eacb9c47da9701cf9d4aa6a4b75a7572c3a5a12018edb7
While the code related to UI is fine, the changes in the following 2 files are work arounds and need to be redone.
invenio_rdm_records/requests/community_submission.py - changes so 'Reviewer' can get to the request page
invenio_records_permissions/policies/base.py - to remove 'Accept/Remove' buttons
I would like to get input on how to rewrite the code. Thank you very much.