update hist_rights + create hist_likers

notes/hist.json

@@ -3,6 +3,7 @@
     "children": [
         "hist_graphql",
         "hist_ldap",
-        "hist_rights"
+        "hist_rights",
+        "hist_likers"
     ]
 }
\ No newline at end of file

notes/hist_likers.json

+{
+    "title": "'Likers' (aka 'followers'), 'dislikers' et notifications",
+    "children": []
+}
\ No newline at end of file

notes/hist_likers.md

+TODO
\ No newline at end of file

notes/hist_rights.md

-## Overview
+L'objectif de ce mémo est de décrire la façon dont sont pensées les autorisations dans Sigma, i.e. à quelle condition une requête doit être acceptée et traitée, ou rejetée. 
+(E.g., les requêtes "créer un nouvel événement 'proj JTX'" ne doivent être acceptées que si elles proviennent d'un admin ou d'un speaker du groupe JTX.)
 
-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. 
+On décrit aussi comment spécifier, de façon concise, les niveaux de droit requis pour chaque requête GraphQL, grâce au tag `@rights` sur les resolvers.
 
-### 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, 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
+## Définitions
 
-### Le graphe organique des groupes
+Remarque : cette section suit le modèle décrit dans https://gitlab.binets.fr/guillaume.wang/gestion-des-droits-sigma/, et constitue un assez bon résumé des parties pertinentes de ce dernier.
+
+### Statuts d'appartenance (i.e. "niveaux de droit basiques")
+Un utilisateur peut être **membre strict**, **speaker** ou **admin strict** d'un groupe. Cette information est stockée dans le LDAP. 
+[^Cela correspond aux "statuts d'appartenance *atomiques*" dans 'gestion-des-droits-sigma'. Le statut "follower" n'est pas discuté ici car il ne définit pas de niveau de droit.]
+
+Par définition, les statuts d'appartenance sont inclus les uns dans les autres : admin-strict *implique* speaker *implique* membre-strict.
+
+### Légalité et permissions
+Dans l'idée, toutes les actions sur Sigma sont effectuées par des groupes. En réalité, ce sont des utilisateurs qui font des choses "au nom d'un groupe".
 
-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.
+Ceci inclut les actions "lire un message" : on considère que si un utilisateur lit une annonce, c'est qu'il la lit *au nom d'*un groupe auteur ou destinataire.
 
-### Conditions pour les niveaux de droit
+Pour qu'une requête soit acceptée, il faut donc vérifier *qu'il existe un groupe* tel que
+- l'action correspondante est une action **légale** du groupe (e.g. le groupe est auteur ou destinataire de l'annonce)
+- l'utilisateur à l'origine de la requête a la **permission** d'effectuer cette action au nom du groupe.
 
-Un des rôles du *graphe organique des groupes* est de définir le niveau de droit des users pour chaque groupe.
+Les "légalités" sont en général intuitives, donc on ne les spécifie pas.
 
-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.
+### Niveaux de droit 
+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 "au nom du groupe", autrement dit quelles sont les actions qu'il a la permission d'effectuer.
 
-Dans la BDD sous-jacente, il faut que pour chaque groupe, on ait admin > speaker > member.
+Les différents niveaux de droit sont :
+- *none* : aucun droit, ne sait même pas que le groupe existe (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
+- *(inherited) member* : le user a aussi acces à l'activité interne du groupe : les PrivatePost, ainsi que les annonces et events dont le groupe est auteur ou destinataire
+- *speaker* : le user peut aussi parler au nom du groupe. Il a le droit de publier des annonces et d'organiser des évènements
+- *(inherited) admin* : le user a tous les droits sur le groupe
 
-Détaillons ici les conditions exactes pour avoir un niveau de droit donné.
+Remarque : cette description s'applique pour un groupe générique, mais les permissions associées à chaque niveau de droit peuvent être personnalisées ; par exemple un groupe peut choisir de rendre la frontpage visible à tout *authenticated*. 
+Voir plus loin la section idoine (TODO)
+
+*(inherited) member* et *(inherited) admin* correspondent aux statuts d'appartenance *membre strict* et *admin strict* par l'intermédiaire du graphe des groupes.
+
+### 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 DAG directed acyclic graph.
+[^Cette information est stockée dans le LDAP.]
+
+Un des rôles du *graphe organique des groupes* est de définir les niveaux de droit "hérités".
 
 #### Pour les groupes simples
 - Member :
     - Un user est membre strict du groupe G s'il est member 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.
+    - 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 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.
+    - 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 (hérité) de G, ou
+    - 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, ou
     - 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" ou "authenticated", selon le cas de figure.
 
+(Pour rappel, "la BDD sous-jacente" est le LDAP, dans le cas de Sigma à l'X.)
+
 #### 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 speaker 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.
+Ainsi, le graphe organique des groupes permet l'administration "en cascade" des groupes enfants : *les admins du groupe parent sont admins (hérités) du groupe enfant.* 
 
-Si un groupe est le parent d'un autre, alors les admins du groupe parent sont admins (hérités) du groupe enfant. Exemples :
+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 ; qui est a présent implémenté sur le LDAP bloaziadur.
+
+Remarque sur speaker : il s'agit d'un nouveau niveau de droit par rapport à Frankiz 3.0 ;il est à présent implémenté sur le LDAP bloaziadur.
+
 
 ## Dans l'implémentation
 
-Le système GraphQL est pensé comme l'interface par laquelle les utilisateurs interagissent avec sigma, les graphismes en moins. Le client peut envoyer tout type de requête. C'est au niveau des resolvers que les permissions sont gérées. D'où le @rights
+Le système GraphQL est pensé comme l'interface par laquelle les utilisateurs interagissent avec Sigma, les graphismes en moins. Le client peut envoyer tout type de requête. C'est au niveau des resolvers que les permissions sont gérées. D'où le @rights
 
 ### Dans les resolvers GraphQL : le tag @rights
-Utilise par JSDoc
-Le tag @rights est la gestion des autorisations.
-Utilise dans resolvers.ts
+Le tag @rights, un tag JSDoc custom, désigne la gestion des autorisations, et est principalement utilisé dans les resolvers (`resolvers.ts` et `object_resolvers/`) mais aussi dans les models.
+
+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.
 
-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~~
+- ~~`speaker( groupUID )`, `member( groupUID )`, `viewer( groupUID )` - même chose~~
+- ~~`user` - la fonction ne fait que ce que l'utiliateur a le droit de faire (vérifications via l'argument user)~~
 
-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
-- `speaker( groupUID )`, `member( groupUID )`, `viewer( groupUID )` - même chose
-- `user` - la fonction ne fait que ce que l'utiliateur a le droit de faire (vérifications via l'argument user)
+(^-- deprecated)
 
 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.

src/graphql/typeDefs/actions.graphql

@@ -53,51 +53,34 @@ type Query {
 
 type Mutation {
     """
+    Rappels du mémo rights : 
+
     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é)
+    - none : aucun droit, ne sait même pas que le groupe existe (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, 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
+    - viewer : le user a aussi accès à l'activité publique du groupe : frontpage, Q&A, liste des membres, speakers et admins
+    - (inherited) member : le user a aussi acces à l'activité interne du groupe : les PrivatePost, ainsi que les annonces et events dont le groupe est auteur ou destinataire
     - 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
-
-    Un des rôles du *graphe organique des groupes* est de définir le niveau de droit des users pour chaque groupe.
-        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.
-
-        Dans la BDD sous-jacente, il faut que pour chaque groupe, on ait admin > speaker > member.
-
-    Détaillons ici les conditions exactes pour avoir un niveau de droit donné.
+    - (inherited) admin : le user a tous les droits sur le groupe
     == Pour les groupes simples ==
     - Member :
         - Un user est membre strict du groupe G s'il est member 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.
+        - 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 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.
+        - 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 (hérité) de G, ou
+        - 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, ou
         - 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" 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 speaker 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 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 ; qui est a présent implémenté sur le LDAP bloaziadur.
 
     Les mutations ci-dessous sont divisées en quatre, selon le niveau de droit requis pour pouvoir les appeler.
     Les Mutations concernant les *Requests* suivent à peu près toutes le schéma suivant :