Membership on PubPub Platform is designed, like the rest of Platform, to be extremely flexible and allow for lots of different patterns to emerge, while at the same time not requiring users to spend endless time configuring individual permissions on individual roles to achieve what they want.
To achieve this, we will be creating a matrix of permissions out of core Platform metaphors, rather than building a separate matrix permission system. Permissions will be determined by the intersection of a Member's role (contributor, editor, admin) and the scope at which they have been added (pub, stage, community). For ease of use, we will also allow admins to create groups of members which can be added in place of individual members.
Core Goals
Allow admins to give users the ability to edit pubs only at specific points in a workflow when their contribution is needed, e.g. copyeditors or legal review, which only needs to happen at certain points
Allow admins to give users control over large parts of a process without giving them control over the entire community, e.g.
Allow pub submitters (authors, reviewers, etc.) to create and edit pubs, but not to take other actions on them and not to see other, sensitive pubs or discussions related to them (e.g. reviews of pubs)
Allow communities to see and manage large lists of more "distant" members who may have contributed or reviewed a pub, but who are not part of the core community
High-Level Projects
Member types: contributor, editor, admin
Member management (add/delete/modify?) at three scopes: pub, stage, community
Community-level management is particularly interesting, as this is where people will browse the large numbers of contributors, in particular, who are part of their community. We may want to make room for adding user metadata, or linking these with pubs, etc.
Ability to create member groups with many members, and to add those groups to any scope with any type (e.g. the "Copyeditors" group gets added to the "Copy editing" stage as an "editor").
Ability to add a member to a user group automatically upon invitation via short code, or when they fill out a form and are not previously a member. For, e.g., allowing communities to create reviewer solicitation forms that put people in a reviewer member group.
Email notifications when an existing user is added, or a new user is invited, to any scope
Note on member types
Generally speaking, here's how we're thinking about the different member types:
Contributor: Can only edit fields/take actions on Pubs/Stages which they have explicit access, even at the community level. For people like submitters, reviewers, etc.
Editor: Can edit fields on pubs they have access to and their children/siblings, and run available actions on those Pubs (even if not a member of the stage). At the community level, these people can edit, but not configure/invite, everything. Generally for people who need access to groups of pubs like copyeditors, section editors, book editors, etc.
Admin: Same as editor, plus can configure actions on stages and invite members to the objects they have access to (or all objects, if at the community level).
Technical implementation notes
We have discussed implementing this using static permissions in code that resemble a more typical matrix permissions system for the three roles identified. This allows us to add more roles easily, if needed, or migrate to a more typical permissions system if this is not workable.
Summary
Membership on PubPub Platform is designed, like the rest of Platform, to be extremely flexible and allow for lots of different patterns to emerge, while at the same time not requiring users to spend endless time configuring individual permissions on individual roles to achieve what they want.
To achieve this, we will be creating a matrix of permissions out of core Platform metaphors, rather than building a separate matrix permission system. Permissions will be determined by the intersection of a Member's role (contributor, editor, admin) and the scope at which they have been added (pub, stage, community). For ease of use, we will also allow admins to create groups of members which can be added in place of individual members.
Core Goals
High-Level Projects
Note on member types
Generally speaking, here's how we're thinking about the different member types:
Technical implementation notes
We have discussed implementing this using static permissions in code that resemble a more typical matrix permissions system for the three roles identified. This allows us to add more roles easily, if needed, or migrate to a more typical permissions system if this is not workable.