Proposition rights management

#32 , #30 

src/graphql/typeDefs/actions.graphql

@@ -65,25 +65,39 @@ type Mutation {
 
     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)
-    - Un user est viewer du groupe G :
-        - s'il est admin, speaker ou member d'un des descendants de G dans le LDAP.
-        - 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
+        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).
-    - Un user est membre d'un groupe G s'il est membre, speaker ou admin d'un des descendants de G dans le LDAP.
-    - Un user est speaker d'un groupe G s'il est speaker ou admin selon le LDAP.
-    - Un user est admin d'un groupe G s'il est admin d'un des ascendants de G dans le LDAP.
     - 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.
 
     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 :