• de comptabilité : par exemple les personnes inscrites à un voyage
• de communication externe : par exemple : la liste de tous les membres d'un service, "Groupe de contacts pour le projet X", "Equipe de développement du logiciel Y", "Membres du staff des mouvements de jeunesse de Perpette-les-bains", etc.
• de collaboration : par exemple avec la possibilité d'écrire au groupe ou la possibilité de recevoir des nouvelles en tant que membre du groupe, etc.
• de gestion des droits :
  • les droits relatifs aux pages (lecture, écriture, commentaires)
    • permet en quelques actions de donner à un nouvel utilisateur le droit d'accès à un groupe de pages donné
    • permet en quelques actions de donner à un groupe de personnes le droit d'accès à une page donnée en évitant d'ajouter individuellement chaque personne de ce groupe
  • les droits relatifs aux actions (affichage de l'interface ou non)
    • permet par exemple de créer une action permettant de créer des utilisateurs et une autre permettant de s'identifier
    • permet par exemple de restreindre à un groupe des fonctions d'administration, etc.
  • les droits relatifs aux méthodes
    • permet par exemple, en quelques actions, de protéger un wiki d'une attaque en restreignant temporairement l'édition à un groupe donné

• de création des groupes
• de suppression des groupes
• d'ajout et de retrait d'un utilisateur à un groupe
• comment ajoute-t-on un groupe aux droits d'accès d'une page

Proposition I

• idéalement les groupes ne doivent ajouter que le minimum de complexité au wiki

• aucun groupe n'est créé à l'installation de WikiNi, les actions sensibles étant affublées d'une restriction d'accès par défaut
  • Je pense qu'il y aura des actions "sensibles" qui ne devraient pas avoir un accès libre, même au départ. Typiquement l'action qui gèrera les droits des autres actions/handlers et tous les actions/handlers servant à l'administration. Pour l'instant tout cela n'existe pas, mais quand on les créera je pense qu'il sera inévitable de créer un groupe à l'installation... A priori ça ne devrait pas poser un gros problème, quelle que soit la solution technique envisagée. -- LordFarquaad

• s'il existe un groupe d'admin créé au départ (j'y réfléchis encore), ce groupe peut être vide au départ. Idéalement, la transition entre WikiNi 0.4.x et 0.5 devraient se faire sans qu'on ai rien à faire au niveau fonctionnel. Tous les administrateurs fonctionnels ne voudront peut-être pas utiliser ces fonctions. -- CharlesNepote
  • Attention: il ne faut pas se retrouver dans le problème de l'oeuf et de la poule exprimé dans ACLGroup: si le groupe des admin se retrouve vide, il faudra qu'un administrateur technique ajoute manuellement une personne dedans si le besoin d'administrateurs fonctionnels se fait ressentir (on ne peut bien entendu pas imaginer que le groupe des admins soit ouvert !) A mon avis le fait d'introduire obligatoirement une personne dans le groupe d'administrateurs lors de la transition ne devrait poser aucun problème: les anciens modules resteront libres d'accès. Quant aux nouveaux, jusque là WikiNi tournait très bien sans et devrait donc encore tourner même s'ils ces derniers ont un accès restreint. Donc rien de nécessaire à faire au niveau fonctionnel. -- LordFarquaad

• les interfaces actuelles de WikiNi ne sont pas modifiées (ou si peu) ; celles gérant les groupes s'ajoutent

• il existe la notion de groupe ouvert et de groupe contrôlé

• création des groupes
  • par défaut tout le monde peut créer un groupe ; mais cette possibilité doit pouvoir être désactivée par l'administrateur fonctionnel
  • la création de groupe par n'importe qui ne pourrait-elle engendrer des phénomènes de typosquating : exemple le groupe "admib"
  • un groupe peut (doit ?) être vide à sa création ; il n'est pas nécessaire qu'il soit peuplé au départ : exemple : "Personnes désirant commander le livre de référence pour le cours sur l'économie des fourmis rouges d'Afrique Centrale - ajoutez-vous à la liste"

• suppression des groupes
  • quelles sont les conditions :
    • groupe vide ?
    • le transfert de ces prérogatives ?
    • la fin de sa durée de vie ?
    • "Groupe vide" : je ne pense pas que ce soit une condition nécessaire, de toute façon elle risquerait d'être contournée par la suppression préalable de tous ses membres, ce qui par ailleurs risquerait de s'avérer assez fastidieux... Par contre une condition nécessaire serait peut-être que le groupe ne soit pas le responsable d'un handler/action (cela dépend de la manière dont les droits pourront être transférés en fait) -- LordFarquaad
  • qui peut supprimer un groupe ?
    • propriétaire du groupe seulement ?
    • administrateur ?
    • utilisateur ayant droit à la fonction de suppression des groupes ?
    • créateur du groupe ?
    • n'importe qui dans le cas d'un groupe ouvert ?

• ajout et retrait d'un utilisateur
  • tout utilisateur peut joindre et se retirer d'un groupe ouvert
  • tout utilisateur ne peut pas s'ajouter lui même à un groupe contrôlé
  • qui autorise ou inscrit un utilisateur à un groupe contrôlé ?
    • Chaque groupe a un responsable qui peut ajouter n'importe qui dedans
    • Il existe une action aux droits restreints et qui permet à ceux qui y ont accès d'ajouter n'importe qui à n'importe quel groupe
    • -- LordFarquaad
  • tout utilisateur peut idéalement sortir de lui-même de n'importe quel groupe (ouvert ou contrôlé)

• une page peut-elle être possédée par un groupe ?
  • J'ai bien peur que cela soit fort complexe à gérer, cela risquerait d'entrainer de nombreuses modifications assez complexes dans le noyau et les modules existants, à savoir qu'à chaque fois qu'il faudra vérifier une droit d'accès il faudrait obtenir la liste de tous les membres du groupe propriétaire... Par ailleurs je ne vois pas trop ce qu'il y a à gagner: actuellement celui qui crée une page en est propriétaire, dans l'avenir il devrait pouvoir donner les différents droits d'accès à un groupe. La seule différence réside dans le fait que si un groupe était propriétaire d'une page il pourrait en régir les ACL et en changer le propriétaire. Je ne pense pas que ce soit vraiment nécessaire... De plus cela risquerait de poser des problèmes en cas de suppression du groupe en question... -- LordFarquaad

• Et quand on aura su y apporter des réponses il faudra encore discuter de la façon de gérer tout ça ! :-j Par contre je ne sais pas s'il y a vraiment besoin d'autres propositions, vu que celle-ci est fort ouverte à la discussion. -- LordFarquaad

Solutions techniques

• ACLGroup, reposant sur la notion d'administrateur
• Je vais avoir besoin bientôt moi-même d'une gestion des groupes, j'ai voulu me baser sur ACLGroup mais il y a énormément de choses que je voudrais améliorer. J'ai déjà fait quelques modifications et il ne reste plus grand chose de ce qu'il y avait au début :-j Je ne pense pas que ça devrait prendre beaucoup de temps, même si je n'en aurai pas tellement à court terme. J'espère tout de même pouvoir fournir assez rapidement ma propre solution, qui pourra aussi servir d'exemple. -- LordFarquaad
  • Très bien. -- CharlesNepote

Question sur ACLGroup

• Je ne sais pas s'il est compatible avec la 0.4.2, mais pourquoi ne pas passer simplement à la version 0.4.3 ? (Ou même à la version CVS qui est stable) S'il n'y à que le menu de gauche à ajouter, c'est peut-être plus simple ? Cependant il serait peut-être préférable d'attendre que nous ayons fini de développer la gestion des groupes, afin que vous n'ayez pas de difficultés à mettre à jour vers les futures versions... -- LordFarquaad