TODO: me relire et modifier/enlever les passages barres si c'est correct.
## Overview
Chaque utilisateur a un certain niveau de droit sur chaque groupe. Ce niveau de droit indique ce qu'il a le droit de savoir et de faire.
> ~~Chaque niveau est inclus dans les niveaux supérieurs.~~
**^-- ce n'est plus le cas depuis https://gitlab.binets.fr/br/sigma-backend/issues/32**
TODO: quelle est la bonne specification? Merger les deux.
### Les differents niveaux de droit [specification issue de resolvers.ts]
*Par rapport à un groupe donné*, les différents niveaux d'un user sont :
- none - aucun droit
- viewer : l'utilisateur a visibilité sur le groupe. Il sait que le groupe existe, et a accès à un certain nombre d'infos.
- member : l'utilisateur est membre du groupe
- speaker : l'utilisateur peut parler au nom du groupe. Il a le droit de publier des annonces et d'organiser des évènements
- admin : l'utilisateur a tous les droits sur le groupe
### Les differents niveaux de droit [specification de actions.graphql]
*Par rapport à un groupe donné*, un user peut avoir différents niveaux de droits :
- none : ne sait meme pas que le groupe existe, aucun autre droit (typiquement, une connection où l'utilisateur ne s'est pas authentifié)
- authenticated : sait que le groupe existe, aucun autre droit (une connection on-platal sans auth, ou une connection authentifiée)
- viewer : le user a aussi accès à l'activité publique du groupe : frontpage, Q&A, liste des membres, speakers et admins
- member : le user a aussi acces à l'activité interne du groupe : les PrivatePost, ainsi que les Message dont le groupe est auteur ou destinataire
- viewer : le user a aussi accès à l'activité publique du groupe : frontpage, Q&A, liste des membres, speakers et admins, Message dont le groupe est destinataire
- member : le user a aussi acces à l'activité interne du groupe : les PrivatePost, ainsi que les Message dont le groupe est auteur
- speaker : le user peut aussi parler au nom du groupe. Il a le droit de publier des annonces et d'organiser des évènements
- admin : le user a tous les droits sur le groupe
- ~~supervisor : le user est admin du parent du groupe et peut donc intervenir dans ce groupe (il est par défaut 'viewer' mais peut prendre les droits d'admin arbitrairement)~~
### Le graphe organique des groupes
Les champs `parent` et `children` de l'objet `Group` dans le schéma GraphQL définissent un graphe des groupes, appelé *graphe organique des groupes* car il définit les héritages de droits d'admin (l'admin d'un groupe peut administrer les groupes enfants) (de la même facon qu'une hiérarchie organique militaire). Ce graphe ne doit pas contenir de cycles, i.e. doit être un arbre.
Un des rôles du *graphe organique des groupes* est de définir le niveau de droit des users pour chaque groupe.
### Conditions pour les niveaux de droit
> ~~D'abord, petit détail de terminologie : les cinq niveaux de droits sont inclus les uns dans les autres (un speaker est aussi un viewer, par ex.) (sauf pour supervisor qui n'est pas admin par défaut)~~
**^-- ceci n'est plus le cas, cf issue https://gitlab.binets.fr/br/sigma-backend/issues/32**
Un des rôles du *graphe organique des groupes* est de définir le niveau de droit des users pour chaque groupe.
- Les conditions pour qu'un user soit membre, speaker ou admin sont claires, puisque cette information est stockée directement en BDD.
- Un user non-membre est viewer du groupe G :
- s'il est membre d'un groupe immédiatement parent de G (one-edge-down visibility), ou
- s'il est membre d'un groupe faisant partie du champ "visibilityEdge" de G
D'abord, petit détail de terminologie : les cinq niveaux de droits sont inclus les uns dans les autres (un speaker est aussi un viewer, par ex.) (sauf pour les permissions héritées)
Plus précisément, on a les inclusions suivantes : admin strict > speaker > membre strict > membre hérité > viewer > authenticated.
Il n'y a que admin hérité qui n'est pas nécessairement inclus dans les autres niveaux de droits.
Détaillons ici les conditions exactes pour avoir un niveau de droit donné.
#### Pour les groupes simples
- Member :
- Un user est membre strict du groupe G s'il est member, speaker ou admin de G selon la BDD sous-jacente.
- Un user est membre hérité du groupe G s'il est membre strict d'un de ses descendants.
- Speaker : un user est speaker du groupe G s'il est speaker ou admin de G selon la BDD. Pas de notion d'héritage de speaker.
- Admin :
- Un user est admin strict du groupe G s'il est admin de G selon la BDD.
- Un user est admin hérité du groupe G s'il est admin strict d'un de ses ascendants.
- Viewer : un user est viewer du groupe G
- s'il est membre hérité de G.
- s'il est membre hérité d'un groupe immédiatement parent de G (one-edge-down visibility), ou
- s'il est membre hérité d'un groupe faisant partie du champ "visibilityEdge" de G
- s'il est membre d'un métagroupe dont G est membre (implicit visibility-edges).
- Dans tous les autres cas, le user a le niveau de droits "none".
- Dans tous les autres cas, le user a le niveau de droits "none" ou "authenticated", selon le cas de figure.
== Pour les méta-groupes ==
- Un user est membre d'un méta-groupe G s'il est membre (hérité) d'un groupe simple dans G.
- Un user est speaker d'un méta-groupe G s'il est admin strict d'un groupe simple dans G.
- Un user est admin d'un méta-groupe G s'il est admin (hérité) d'un groupe simple dans G.
- Un user est viewer d'un méta-groupe G s'il est viewer d'un groupe simple dans G.
L'autre rôle du *graphe organique des groupes* est de permettre l'administration "en cascade" des groupes enfants.
Si un groupe est le parent d'un autre, alors les admins du groupe parent peuvent se déclarer admins du groupe enfant. Exemples :
- BR est parent de Chocapix. L'admin de Chocapix est parti en vacances. L'admin de BR peut se déclarer admin de Chocapix et faire ce qu'il a à faire, sans attendre le retour du respo Chocapix.
- Cotisants-Kès est parent de Troll'X. Troll'X fait n'importe quoi (en floodant de Messages par ex). Les admins de Cotisants-Kès (les kessiers) peuvent se déclarer admin de Troll'X et stopper les dégâts.
Si un groupe est le parent d'un autre, alors les admins du groupe parent sont admins (hérités) du groupe enfant. Exemples :
- BR est parent de Chocapix. L'admin de Chocapix est parti en vacances. L'admin de BR peut, en tant qu'admin (hérité) de Chocapix, faire ce qu'il a à faire, sans attendre le retour du respo Chocapix.
- Cotisants-Kès est parent de Troll'X. Troll'X fait n'importe quoi (en floodant de Messages par ex). Les admins de Cotisants-Kès (les kessiers) peuvent, comme ils sont admins hérités de Troll'X, stopper les dégâts.
Remarque sur speaker :
Il s'agit d'un nouveau niveau de droit par rapport à Frankiz 3.0 ; il n'est pas implémenté dans le LDAP frankiz.
Par conséquent, il est probable que, au début du moins, on impose que speaker=admin, pour pouvoir continuer à utiliser ce LDAP.
Le mieux serait néanmoins de rajouter cette propriété au LDAP.
Il s'agit d'un nouveau niveau de droit par rapport à Frankiz 3.0 ; qui est a présent implémenté sur le LDAP bloaziadur.
## Dans l'implémentation
...
...
@@ -68,16 +71,19 @@ Utilise dans resolvers.ts
Certaines fonctions de connectors effectuent des vérifications d'authorizations avant de renvoyer une réponse, d'autres non. Pour être sur qu'on ne renvoie jamais de réponse sans avoir au préalable effectué les bonnes vérifications, chaque fonction possède dans sa description un attribut droit, qui décrit les droits que requiert cette fonction.
La valeur de @rights peut être :
`super` - la fonction n'effectue aucune vérification, et renvoie le resultat demandé
`admin( groupID )` - la fonction ne fait que ce qu'un admin du groupe indiqué aurait le droit de faire
-`user` - la fonction ne fait que ce que l'utiliateur a le droit de faire (vérifications via l'argument user)
La procédure a suivre est la suivante : quand une fonction possède un certain niveau de droit, elle ne peut appeler une fonction possédant un niveau de droit plus large que si :
- 1- on a au préalable vérifié que l'utilisateur possédait effectivement ces droits.
*ou*
2- on s'est assuré que l'opération effectuée par cet appel particulier de la fonction était dans les droits de l'utilisateur
- 2- on s'est assuré que l'opération effectuée par cet appel particulier de la fonction était dans les droits de l'utilisateur
D'un point de vue pratique :
- les **resolvers** doivent **vérifier** que le user possede les droits énoncés dans le tag @rights, avant de renvoyer un résultat / modifier la BDD. Ils vérifient aussi que le user possede les droits nécessaires pour appeler des fonctions dans les models.
- les fonctions dans les **models** peuvent **supposer** que les droits du tag @rights sont acquis, ie. qu'ils ont été vérifiés par la fonction appelante au préalable.
#### Quel @rights donner a quels resolvers ?
...
...
@@ -89,20 +95,20 @@ Les fonctions qui ne modifient pas la BDD et ne renvoient pas de données sur la
cf `objects.graphql`
Les Mutations concernant les *Requests* suivent à peu près toutes le schéma suivant :
