Add basic Stage membership UI

[gabestein]

Motivation

So admins can add, remove, and change permissions of Members in stages

Requirements

• Ability to add/remove existing community members to a stage as an admin, contributor, or editor in the stage member tab, and invite new ones.
  • Add "add member" button to member tab of stage management, identical to "members" page add member button
  • Only admins should see the button
  • Should repurpose the existing member add UI, e.g.:
  • When clicked, shown a popup to search by email
  • If user found, can select permission for the stage and add it
  • If no user found, sends an invitation. That invitation should use slightly different language, e.g.: You have been invited to be a [role name] of the [stage name] stage in [community name].
• Ability to see existing members and their role, and delete them in the member tab of the side panel
  • Only admins should be able to see the delete button
  • Can just be the current member list, plus their role underneath their name and an x to delete them, similar to the current pub type editor

Acceptance Criteria

• If user is not already a member of the community, only adds a membership to the stage with the selected role — not an additional community-level role
• Does not implement permissions/querying, that's separate cards, but should add/remove the correct permissions
• Does not need to show cascading permissions yet, we can add that later

Extra work

Mockups (if available)

Old Requirements rolled into other tickets

- Permissions behavior: - Contributor: - Can see and edit Pubs directly in the stage (e.g. not child/related pubs not in the stage they don't have direct access to) - Can create new Pubs in the stage (they become direct members of these pubs) - Can create stageless child/related Pubs of Pubs in the stage (they become direct members of these pubs) - Can run actions/move/assign on Pubs in the stage - Editor: same as contributor, plus: - Can see and edit children/related pubs of Pubs in the stage, even if child/related Pubs are not in the stage - Admin: same as editor, plus: - Can edit stage configuration/actions/etc. - Can delete pubs in the stage - Can add members to stage as contributor, editor, or admin. (If the user does not exist already, they can be invited via email. The user receives an invitation to join PubPub as a result, with a message specifying the stage they have been invited to and a redirect to the stage configuration they have been added to.) - Email behavior: - When a user is added to a stage from the UI, they receive an email notifying them that they have been added to that stage, with a link to visit it. ## Acceptance Criteria - Add a new `role` column to the permissions table. This column stores an value for a new `PermissionRole` enum. - Community level roles will continue to function as they do today. (Eventually we will likely remove community member roles and rely on a single community permission per member) - The schema is not exactly right. Adjust the Permission table to capture the pubId, stageId, or communityId. - Add a constraint that ensures a member may have only one permission per platform object (community, stage, pub).

[3mcd]

I think both editor and admin are a bit too permissive. Since stages belong to a community, the ability to delete a stage should be granted by a community-level admin membership/permission.

Similarly, I think since action instances belong to stages, only admins of those stages (or community admins) should be able to reconfigure them. Which would make a stage edit permission have implications just for pub editing, not stage configuration. Which seems intutive IMHO.

[gabestein]

Updated! Let me know if this reflects your feedback.

One other thing: who should be able to create child Pubs? In the biorxiv use-case, they have this concept of adding an evaluator note, which I think would be a child pub in our case. Perhaps we need to add that to the contributor role in general? Can create child/related pubs (but can't automatically see them).

This also makes me realize we may, in fact, need a view-only role for the biorxiv case. I can't see them wanting to allow evaluators to edit the submission, but they do want them to be able to see it in full.

[gabestein]

Actually, I'm realizing there's very little difference between a stage contributor and a stage editor. What if a stage contributor is basically:

• Can see Pubs in stage
• Can create children/related pubs
• Can take actions

And editor is can edit?

[3mcd]

That makes sense to me. I don't think a stage contributor should be able to edit pubs in the stage, just create them and run pre-configured actions against them.