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

Discussion: Better alternative to user abilities based on roles

Ouverte
  • Quelque chose ne va pas ?
#1,150 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
javascript
Domaine
api, authorization, frontend

Piste de recherche

Commencez par l’exemple d’ability dans l’issue, en particulier projectMembership, userRole et les route before/afterModel checks. Examinez les options listées de current-user sideloading et d’API abilities ; la tâche est considérée comme terminée lorsqu’une solution approuvée existe pour les vérifications d’abilities asynchrones et les project membership requests excessives, mais aucun fichier ni test n’est nommé.

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

Description

Difficulty: Medium

Problem

Right now, most of our authorization stuff is based in a user's membership level in a project. They can be unrelated, they can have a pending membership (meaning they requested membership, but they are yet to be approved), or they can be any of [contributor, admin owner].

Based on the level of their role, they are allowed or not allowed to perform certain project-related actions.

First Problem: Amount of requests

In order to determine a role level of a user in a project, we usually need to perform the following:

  1. fetch project.projectUsers
  2. for each projectUser, actually load the record from the backend, because just having the id is not enough.

Right now, this is not a big deal performance-wise. However, we expect projects to grow, and this is, worst-case, n+1 requests for a project with n members. Luckily, we use colasced id requests to significantly reduce this, but it's still something that's potentially problematic.

Second Problem: Ember-Can does not play well with async

The ability above is a computed, the content of which is partially dependant on async network requests.

Basically, in most cases we have something like this:

projectMembership: computed('project.projectUsers', 'currentUser.user.id', function() {
  let currentUserId = get(this, 'currentUser.user.id');

  if (isEmpty(currentUserId)) {
    return false;
  } else {
    return get(this, 'project.projectUsers').find((item) => {
      return get(item, 'user.id') === currentUserId;
    });
  }
}),

userRole: alias('projectMembership.role'),
userIsContributor: equal('userRole', 'contributor'),
userIsAdmin: equal('userRole', 'admin'),
userIsOwner: equal('userRole', 'owner'),

canEdit: or('{userIsAuthor,userIsAdmin,userIsOwner}'),
canAssign: or('canEdit', 'userIsContributor'),
canReposition: alias('canAssign')

With template usage, where we do or do not render parts of the UI based on abilities, this works amazingly well, mostly thanks to DS.PromiseObject and DS.PromiseArray classes.

As results are being fetched, eventually, we will get a currentUserId and we will get a projectMembership.role. Until that happens, the ability is evaluated as false. For templates, this is almost exactly what we need. Eventually, when we determine a user is able to do something, that part of the UI will render.

For the case of routes and redirecting in case of lack of abilities, this is problematic. In those cases, we basically get the current value of the ability, which is usually false at the moment of a route's before/afterModel hook. Due to that, we are forced to use a dirty solution of explicitly fetching records before checking the ability:

return get(project, 'projectUsers').then(() => {
  if (this.cannot('manage project', project)) {
    return this.transitionTo('project');
  }
});

Its a very clear code smell and it will end up being highly problematic as the number of users grows.

We need a solution, primarily for the second, but also for the first problem

Potential solutions

We sideload the projectUser relationship as part of the user request

This works, but also means a lot of data we don't need being loaded. Most user will not need information for other user records.

We sideload the projectUser relationship, but only for the current user.

Our API could sideload it in this specific case, if the GET /users/:id matches the currently authenticated user.

Really, this would tackle most cases. We'd have to rethink our currentUser/abilities structure, but it could work quite nicely, I think.

We could go further and have the authentication request return a user record with all the sideloaded information, which we can then push into the ember store manually.

The more I think about it, the more I like this solution.

We send some sort of computed ability table structure for each user

Probably highly complex and something I'm not looking forward to tackling and would vote against, but wanted to get the option listed here anyway.

Have some sort of ability endpoint on the API, which can tell each user if they can/cannot do something.

Again, a solution I do not personally like, but listing it for the sake of discussion.

Other options

Listed above are the options I could think of, but there may be other.

Side effects

Depending on how we deal with this, we could eliminate the need to fix #1151

Langage dominant
JavaScript
Étoiles
120
Forks
75
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-ember

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

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

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