Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

RFC: Role changes

Ouverte
  • Quelque chose ne va pas ?
#1,232 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
20/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
elixir
Domaine
api, authorization, backend

Piste de recherche

Commencez par lire les policies et les actions d’API existantes pour la création, la mise à jour et la suppression de ProjectUser, puis comparez-les aux règles de rôle établies. Le travail sera considéré comme terminé lorsque les incohérences du modèle de rôle et de propriétaire de l’organisation seront résolues et qu’une orientation approuvée sera documentée avant de construire l’UI ; l’issue #1233 couvre le bug distinct de la règle de création.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

needs clarification RFC

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?

Langage dominant
Elixir
Étoiles
234
Forks
82
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de code-corps/code-corps-api

Toutes les issues de code-corps/code-corps-api

Issues similaires

Plus d'issues Elixir

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.