Rôles des membres des organisations

[florimondmanca]

Description du problème

Actuellement, on a 2 rôles : USER et ADMIN

Cela permet déjà de faire une distinction en permettant par exemple aux seuls ADMIN de supprimer une fiche de données.

Lors de l'atelier du 10/06, le besoin d'un 3e "rôle" s'est fait sentir, dans l'objectif de permettre à des "super-utilisateurs" (les véritables admin) de parcourir, accéder et éventuellement modifier l'ensemble des catalogues (équipe technique, DINUM).

Répartition des rĉles

Dans le contexte de l'outil de catalogage et de son UI :

Persona "Contributeur"

Rôle user

Doit pouvoir :

• consulter les catalogues de toutes les organisations
• contribuer au catalogue de leur organisation

Persona "Responsable d'organisation"

Rôle admin ? (comme "administrateur d'organisation")

Doit pouvoir :

• idem que utilisateur
• supprimer une fiche Allow admins to delete datasets #171

Persona "Super administrateur" (responsables de l'instance et équipe technique)

Rôle super_admin ? (pour expliciter leur statut de "véritable admin" transversal à toutes les organisations)

Doit pouvoir :

• idem que responsable d'organisation
• Permettre aux super admins de modifier les fiches de n'importe quel catalogue #451
• Permettre aux super admins de créer une nouvelle fiche dans n'importe quel catalogue #452
• Permettre aux super admins de supprimer les fiches de n'importe quel catalogue #453
• consulter (y compris contribuer et supprimer) les fiches qui ont un niveau d'accès "Restreint" dans les catalogues d'organisation dont ils ne sont pas membres (dépend de Régler le niveau d'accès d'une entrée dans le catalogue #289)

Critères d'acceptation

• Après la création d'une organisation sur une instance, le premier utilisateur qui s'enregistre obtient automatiquement le rôle de "responsable d'organisation" (dépend de Enregistrement et connexion #124).
• Dans tous les autres cas, les rôles sont changé par l'équipe technique par une intervention technique sur la base de données.
• Une organisation peut avoir un ou plusieurs responsables d'organisation.

Idées pour plus tard

• Est-ce qu'un compte Datapass peut contenir une information qu'on peut interpréter comme "cette personne a un rôle de responsable dans son organisation" ?
• Un "responsable d'organisation" (idem "super administrateur") peut voir dans une page dédiée dans l'UI la liste des membres enregistrés dans son organisation et peut modifier leur rôle.

Solution envisagée

Ajouter une valeur OWNER à l'enum UserRole, qui devient donc : USER | OWNER | ADMIN.

Le modèle physique devient :

User:
  id: ID (pk)
  role: UserRole
  organization_id: ID (FK, indexé)

Organization:
  id: ID (pk)
  created_at: datetime
  members: relationship("User")

Pseudo-code applicatif :

# Création d'une organisation
multi = execute(CreateOrganization(name="Multi"))

# Création du 1er utilisateur rattaché à l'organisation
# Il devient automatiquement responsable de l'organisation (= devient son `OWNER`)
johan = execute(CreateUser(..., organization_id=multi.id))
johan in multi.members  # True
johan.role  # 'OWNER'

# Création d'un 2e utilisateur : c'est un simple utilisateur
romain = execute(CreateUser(..., organization_id=multi.id))
romain in multi.members  # True
romain.role  # 'USER'

Permissions (pseudo-code) :

# L'utilisateur :user_id peut-il contribuer au catalogue de l'organisation :organization_id ?
# --> Seulement s'il est admin, ou utilisateur rattaché à l'orga
can_contribute(user, catalog) = (
    user.role == 'ADMIN'
    or user.organization_id == catalog.organization_id
)

# L'utilisateur :user_id peut-il retirer des jeux de données du catalogue de l'organisation :organization_id ?
# --> Seulement s'il est admin, ou responsable de l'orga
can_delete_datasets(user, catalog) = (
    user.role == 'ADMIN'
    or (user.role == 'OWNER' and user.organization_id == catalog.organization_id)
)

Alternatives envisagées

• Plutôt qu'un rôle OWNER, créer une relation User (0,1)-(1,1) OrganizationOwner (1,1)-(1,n) Organization pour représenter le fait qu'un utilisateur puisse être responsable d'une organisation : permet d'écrire directement org.owner.user pour récupérer l'utilisateur responsable (par une jointure), mais plus complexe et pas forcément nécessaire à ce jour. À voir si on finit par nécessiter d'avoir accès à un tel attribut sur org.
  • Références :
    • https://learndjango.com/tutorials/django-best-practices-user-permissions
    • https://forum.djangoproject.com/t/how-are-you-handling-user-permissions-in-more-complex-projects/2430/10

[florimondmanca]

@johanricher Je me demande ce qu'il faut faire de ce ticket ?

Dans le cadre de #388 je me rends compte qu'il y a toujours de la place pour une notion de "responsable d'organisation" (ex : Roselyne Aliacar) et "(super)admin" (nous).

Les cas d'usage concrets sont dans la description du ticket, je pense en particulier à ceux-ci :

• Un super-admin peut modifier n'importe quel jeu de données existant. Un respo d'organisation n'a pas de droit particulier en édition, il ne peut modifier qu'au sein du catalogue de son orga comme n'importe quel USER.
• Un super-admin peut supprimer n'importe quel jeu de données existant. Un respo d'organisation ne doit pouvoir le faire qu'au sein de son orga.

Ça demande un peu de travail.

Si on pense ne pas avoir le temps (j'ai du mal à estimer, il y a encore d'autres peaufinages à faire), je pense qu'il faudrait renommer le rôle ADMIN par exemple en ORG_OWNER. Dès lors nous (équipe de dev rattachée à l'orga "legacy") n'aurions pas de droit en écriture côté UI vis-à-vis des catalogues (on peut tjr faire ce qu'on veut dans la DB), seulement en lecture comme n'importe quel USER.

[johanricher]

Je suis d'accord que ce ticket n'a pas de finalité en soi, c'est à dire qu'il ne justifie pas à lui seul de réaliser des tâches spécifiques. En revanche il sert à avoir une vision d'ensemble plus cohérente sur la façon d'implémenter des tâches qui sont spécifiées sur d'autres tickets.

Comme toujours la logique est de voir au cas par cas ce qui doit être implémenté pour valider les critères d'acceptation. Ma doctrine est la suivante : s'il y a des éléments nouveaux ou des détails qui apparaissent pour implémenter un ticket, cela veut dire qu'il faut les extraire du périmètre et les implémenter plus tard.

Dans l'exemple que tu cites (#288) : l'idée c'est que la restriction doit s'appliquer à tout le monde (user et admin) sauf aux super_admin. Puisque c'est une forme d'exception qui pose des questions (ajout de complexité), c'est à implémenter séparément et ce n'est pas un must have pour la livraison.

Je vais mettre à jour #288 et créer un ou plusieurs tickets dédiés à l'implé côté super_admin (qui ne seront pas dans le périmètre de la livraison).