RFC: Role changes

Comece lendo as políticas e ações de API existentes para criação, atualização e exclusão de ProjectUser e, em seguida, compare-as com as regras de função declaradas. Considera-se concluído quando as inconsistências no modelo de funções e proprietário da organização forem resolvidas e uma direção acordada for documentada antes da construção da UI; o issue #1233 trata do bug separado da regra de criação.

Right now, we have policies and actions in place on our API which would allow promoting and demoting project members by other project members.

We do not, however, have any UI to perform those actions, other than the basic approval of a pending membership.

I would love to be able to spec all this out, but really, I'm unsure in how this works, even with existing policies, due to some inconsistencies I'm seeing.

We need to resolve these inconsistencies before we can build a UI to support the feature properly.

A user is a member of a project if there exists a ProjectUser record linking the two.
Membership level is determined via a role field which can be one of ~w(pending contributor admin owner)

Depending on the role of the user performing the action, and the role change on the user the action is being performed on, we have the following rules

Create

• a user can create their own ProjectUser record - no role level check happens here, so this is definitely a bug. Basically, accessing the API directly, any user can make themselves owner, collaborator, admin or pending member of a project

To fix this, we should enforce the following create rule

• a user can create their own ProjectUser record, provided the role is "pending". This basically means they are allowed to apply for project memberships

Created issue #1233 for this

Update

• a user who is not a member of the project cannot update anyone's project membership
• a user who is a "pending" member of the project cannot update anyone's project membership
• an "admin" can update only "pending" memberships of a project
• an "owner" can do anything other than demoting another "owner"

The result of this is that admins can approve or reject pending, project memberships, while owners can do that and also promote contributors to admins, as well as admins to owners. I'm unsure about this last part, but my guess is, that way a project might have multiple owners at some point.

Overall, other than "owners"promoting others to "owners", this seems right to me and I'm not seeing problems directly. There is a problem which I will get to, however.

Delete

• any user can delete their own project membership
• an owner can delete any project membership, even other owners
• an admin can delete a pending member, or a contributor

The result of this is that any user, even an owner, can leave a project.

Owners can also cast out other owners.

Both of the above are potentially dangerous, but I'm not sure if there is any other way to deal with it.

Admins can cast out pending users (effectively rejecting their application) as well as collaborators.

Again, generally, these seem mostly ok to me. No outright bugs, but I'm unsure if those are the policies we want.

Other issues

The real issue is that, while an organization owner can create a project (or will be able to, once we deal with that milestone), there is currently no ProjectUser record being created to indicate that the organization owner is also the project owner.

I'm not even sure there ought to be. As I said above, we have some problematic cases when dealing with multiple owners, so maybe we should consider renaming our roles and simply update our policies so that the organization owner is considered a sort of superuser for each project within that organization.

We could rename owner to something else and modify our policy so organization owners have authority over this newly named role, but other members with the same role do not.

We could also cast out the owner role completely and just have pending members, contributors and admins, with the organization owner having the final authority over all other members.

It would simplify things a good deal and we can build off of it once people use the app and we get data/feedback to figure out if anything else is needed.

@joshsmith, what do you think?