🌍
Français
sblob a écrit:
Voilà j'ai un peu de mal avec les permissions
attention, ce topic concerne les modifications sur la gestion des permissions sur la branche 1.4. Seule la 1.4.0RC1 est actuellement disponible. Si tu rencontres un problème avec la version 1.3.x, merci de créer un topic "à part" :-)
Bonjour,
Déjà sur script moi j'adore :)
Voilà j'ai un peu de mal avec les permissions
Au départ j'ai créé chaque utilisateur en réglant les axxs à chaques galeries puis comme il y avait beaucoup de monde je me suis dit je vais faire un groupe comme ça je n'ai pas besoin de changer les axxs pour tous les utilisateurs mais voilà quand je change les axxs du groupe, les axxs des utilisateur ne marchent pas
Euh je suis clair?
choubs a écrit:
z0rglub a écrit:
dernière version :
3. ajustement des permissions
Règles de gestion :
(...)
- pour un groupe, si on passe une catégorie à interdite, pas de répercussion sur les membresen fait, si : les catégories devraient devenir interdites aux membres, sauf si leurs autorisations personnelles ou liées à d'autres groupes les y autorisent...
En fait, si maintenant, je repars, plutôt sur le principe de la branche 1.3 : un utilisateur a accès à une catégorie privée s'il y est autorisé ou qu'il fait parti d'un groupe qui est autorisé.
choubs a écrit:
z0rglub a écrit:
- la suppression d'un groupe ou l'exclusion d'un utilisateur à un groupe fait perdre les permissions (des membres) gagnés grâce au groupeidem
si user1 n'a pas accès à cat et qu'il est un membre de group1, et que group1 a accès à cat1, alors user1 accède à cat1 grâce à l'appartenance à group1. on est d'accord ?
choubs a écrit:
2 autres points :
1/ concernant la propagation 'private' vers le bas, catégorie => sous catégorie, qu'est-ce qu'elle apporte réellement :
elle apporte 2 choses :
1. de la logique : si tu rentres dans une maison composée de pièces privées et publique, que la pièce jaune est derrière la pièce bleue et que la pièce bleue est ton seul moyen d'accès à la pièce jaune, alors si la pièce bleue est privée, la jaune l'est aussi automatiquement (et inversement, si tu veux rendre publique la pièce jaune, la pièce bleue doit l'être)
2. la simplicité à gérer au niveau du code. Disons que c'est un peu fatiguant (lourd) de devoir systématiquement rechercher les sous-catégories des catégories privées pour savoir quelles sont les catégories qui sont privées dans la réalité.
choubs a écrit:
- est-ce qu'elle ne sert qu'à bloquer un user indélicat qui (bien que l'affichage ne lui -//:---\spam pas le chemin) essaierait de saisir un numéro de catégorie dans l'url..
non, parce qu'on fait (en 1.3) de toute façon une recherche dans l'arbre : dans le champ user.forbidden_categories, on trouve la liste des catégories privée avec récursion - catégories autorisées pour l'utilisateur - catégories autorisées pour les groupes auquel l'utilisateur appartient.
choubs a écrit:
- ne va-t-elle pas surcharger les écrans de gestion de permission (puisque presque toutes les catégories vont au final s'y afficher)
pas d'inquiétude :-) grâce au nouveau design des formulaires de Gweltas (système de double tableau avec d'un côté les catégories autorisées, de l'autre les catégories interdites), ça sera très pratique.
choubs a écrit:
2/ pour la gestion des permissions j'avais compris :
le postulat : quand l'admin passe une catégorie en privé, implicitement il souhaite en interdire l'accès
=> la mise en place d'une permisssion à un groupe ou à un utilisateur exprime le souhait de donner l'acces à la catégorie (et à ses parents...)
=>> une catégorie et ses parents devient autorisée au user dès lors que ses permissions personnelles le lui permettent OU que qu'il appartient à un groupe autorisé. en gros, il suffit qu'un élément lui donne accès pour qu'il puisse y aller. c'est bien ca ??? (j'ai des doutes quand je lis la réponse du maître a l'exemple de Michrone..)
c'est exactement cela.
Dans le texte descriptif, je vais rajouter une section "ce qui change par rapport à la branche 1.3" :
- le status private ou public s'hérite automatiquement : vers les extrémités pour le private, vers la racine pour le public
- les permissions s'héritent automatiquement vers la racine de sorte que si l'admin dit "user1 est autorisé à parcourir cat1.1.1" alors automatiquement cat1.1 et sa maman cat1 deviennet autorisées pour user1 dans le cas où elles seraient privées.
- le résultat calculé donnant la liste des catégories interdites passe dans une table externe user_forbidden. La mise à jour de cette liste s'effectue lors du chargement de la page par l'utilisateur si des opérations dans la partie administration ont impliqué la mise à jour (évitant ainsi de lourds calculs dans le cas de sites avec beaucoup d'utilisateurs et catégories)
Je vais faire une 3eme version.
choubs a écrit:
PS: c'est vraiment sympa de nous poser ces questions...
normal, on prend toujours de meilleures décisions en y réfléchissant à plusieurs.
Je traite ton post plus tard, faut que je parte, en attendant, testes la nouvelles build, c'est grâce au doudou que je l'ai faite... (elle inclut plein d'autre modifs...)
choubs a écrit:
je comprend bien les les règles "d'héritage" ascendant et descendant, et les partage.
Cette propagation automatique induit une grande prudence dans le passage public - privé, et devrait générer plus de manips dans la mise en place des autorisations individuelles et groupes...
Disons que ça rentre dans la logique des choses. Si on donne l'accès à une catégorie dans les profondeurs de l'arborescence, cela ne sert à rien si l'utilisateur ne peut de toute façon pas y accéder. Le problème viendrait plutôt du fait que certaines catégories soient à la fois mère (contient des sous-catégories) et fille (contient des éléments). Ce qu'il ne faudrait pas, c'est que parce qu'on autorise une catégorie, alors d'autres catégories filles soient automatiquement autorisées.
choubs a écrit:
par contre, j'ai un soucis concernant la fusion des permissions groupe / utilisateur sur le user
en fait, très vite on n'arrive plus à faire la différence entre les permissions décernées à la personne et celles décernées au groupe...
un cas qui ne me plait pas : on crée un groupe autorisé à voir une catégorie, on y associe un utilisateur. Le temps passe, le groupe n'est plus justifié : on le supprime : ca me gêne que le user continue à pouvoir accéder à la catégorie... ca revient à devoir revoir individuellement les permissions de chacun des users du groupe supprimé...
=> je verrais plutôt 2 tables d'autorisation : une 'user', une 'groupe', et 3e table de situation finale du user, calculée à partir des 2 premières. Cette dernière table est remise à jour dès que l'on modifie les permissions du user / du groupe, ou le rattachement du user à un groupe...
Tu as parfaitement raison. Je me suis vraiment posé la question avant d'écrire ce texte. Mon but est d'éviter la complexité, avec l'obligation d'utiliser des données calculées en base, quand elles deviennent trop longues à calculer à chaque rafraichissement de la page (comme la liste des catégories interdites).
J'ai 2 soucis de mon côté :
1. éviter d'avoir à recalculer toutes une flanquée de permissions à chaque modif de permissions (imaginez ce que ça donne avec un site de 300 catégories, 500 utilisateurs et 10 groupes...)
2. éviter de stocker des données liées aux permissions dans la table des utilisateurs (ça gêne Gweltas pour lier les utilisateur à des applications externes).
Autre, proposition étant donné les suggestions :
On reste sur le même principe qu'en branche 1.3 user_access (liste les catégories privées accessibles pour les utilisateurs) + group_access (idem pour les groupes) et on rajoute la table de données calculées user_forbidden qui contient 3 champs {user_id, categories, need_update}. Le champ categories est le strict équivalent au users.forbidden_categories de la branche 1.3
Les données de cette table ne sont recalculées que lors de l'affichage de la page par l'utilisateur et que la colonne need_update est à 'true'. La colonne est passée à "true" à diverses occasions :
- l'utilisateur rejoint ou quitte un groupe
- nouvelles ou obsoletes catégories privées
- changement de permissions de l'utilisateur
- changement de permissions d'un groupe dont l'utilisateur est membre
- ...
Bref, c'est une espèce de cache, mais il n'a pas à être recalculé intégralement à chacune des opérations citées ci-dessus.
Je modifie le texte, en conservant une trace de la première version.
Michrone a écrit:
Hello,
On peut donc donner les permissions soit à un user, soit un un groupe.
Si je donner des permissions à un user qui lui même fait partie d'un groupe, Il se passe quoi ?
Si categ X autorisée pour user Y
Categ X interdite pour groupe A dont fait patie Y.
en fait, avec la première version du texte (avant première modif liée au message de choubs) disait que lorsque la catégorie passe autorisée au groupe, alors les membres du groupe ont automatiquement l'accès, mais pas dans le sens contraire...
Comme l'a fait remarquer choubs, on n'a plus l'information du type "est-ce grâce à l'appartenance à un groupe ou grâce à l'utilisateur lui-même que la catégorie est autorisée ?".
Hello,
On peut donc donner les permissions soit à un user, soit un un groupe.
Si je donner des permissions à un user qui lui même fait partie d'un groupe, Il se passe quoi ?
Si categ X autorisée pour user Y
Categ X interdite pour groupe A dont fait patie Y.
Je ne sais pas si ce que je dis est correct, mais bon :-)
Voici une copie d'un post du forum privé, si vous pouviez le lire avec attention et nous donner votre avis...
dernière version :
z0rglub a écrit:
1. status par défaut
Les permissions se gèrent pour les catégorie "private" (colonne status). Par défaut, une catégorie est :
- status = $conf['newcat_default_status'] si la catégorie parente est public
- status = private si la catégorie parente est private
2. changement de status
Pour changer le status d'une catégorie, 2 écrans : admin/cat_options pour gérer de manière globale, admin/cat_modify pour gérer une catégorie à la fois. La règle est la suivante :
- si le status passe de public à private, toutes les sous-catégories en héritent
- si le status passe de private à public, toutes les sur-catégories en héritent (dans ce sens là, le verbe est mal employé...)
3. ajustement des permissions
Les permissions sont gérées par groupe et par user. Pour une catégorie privée, les permissions déterminent si l'utilisateur ou le groupe peuvent accéder à la catégorie. 3 écrans permettent de gérer les permissions :
- admin/group_perm : pour un groupe donné, liste les catégories privées. Les catégories actuellement autorisées sont en verts, les interdites, en rouge.
- admin/user_perm : pour un utilisateur donné, liste les catégories privées. Les catégories actuellement autorisées sont en verts, les interdites, en rouge.
- admin/cat_perm : pour une catégorie privée donnée, liste les groupes et les utilisateurs. Pour chaque ligne (représentant un groupe ou un utilisateur) propose de passer à permis ou interdit. Pour faciliter la lecture des permissions en cours, un groupe ou un utilisateur ayant la permission est affiché en vert, s'il n'a pas la permission, en rouge.
Ce dernier écran me paraît important, mais je ne le trouve plus. Il est difficile, voire impossible à gérer avec un grand nombre d'utilisateurs. Ne pourrait-on pas imaginer un écran avec une liste multipage sur les groupes ou les utilisateurs ?
Règles de gestion :
- pour un groupe ou un utilisateur, passer une catégorie à interdit rend les sous-catégories interdites
- pour un groupe ou un utilisateur, passer une catégorie à autorisée rend les sur-catégories autorisées *
- pour un groupe, si on passe une catégorie à autorisée, tous les membres du groupe sont autorisés pour la catégorie + les catégories parentes *
- un utilisateur a accès à une catégorie privée s'il y est autorisé ou qu'il fait parti d'un groupe qui est autorisé
- la suppression d'un groupe ou l'exclusion d'un utilisateur à un groupe fait perdre les permissions (des membres) gagnés grâce au groupe
- un nouvel utilisateur récupère automatique des permissions de l'utilisateur "guest"
* c'est un peu dangereux, mais je considère que l'admin sait ce qu'il fait ou qu'il prend soin de ne créer que des catégories mère (catégorie ne contenant que des sous-catégories) ou catégories filles (catégories ne contenant que des éléments)
4. stockage des informations
La table user_access est supprimée, au profit de la table user_forbidden :
- user_forbidden liste les catégories interdites pour un utilisateur. Table avec données calculées.
- user_access liste les catégories privées autorisées pour un utilisateur
- group_access liste les catégories privées autorisées pour un groupe
La table user_forbidden contient 3 champs {user_id, categories, need_update}. Le champ categories est le strict équivalent au users.forbidden_categories de la branche 1.3
Les données de cette table ne sont recalculées que lors de l'affichage de la page par l'utilisateur et que la colonne need_update est à 'true'. La colonne est passée à "true" à diverses occasions :
- l'utilisateur rejoint ou quitte un groupe
- nouvelles ou obsoletes catégories privées
- changement de permissions de l'utilisateur
- changement de permissions d'un groupe dont l'utilisateur est membre
- ...
5. changements par rapport à la branche 1.3
- le status private ou public s'hérite automatiquement : vers les extrémités pour le private, vers la racine pour le public
- les permissions s'héritent automatiquement vers la racine de sorte que si l'admin dit "user1 est autorisé à parcourir cat1.1.1" alors automatiquement cat1.1 et sa maman cat1 deviennent autorisées pour user1 dans le cas où elles seraient privées.
- le résultat calculé donnant la liste des catégories interdites passe dans une table externe user_forbidden. La mise à jour de cette liste s'effectue lors du chargement de la page par l'utilisateur si des opérations dans la partie administration ont impliqué la mise à jour (évitant ainsi de lourds calculs dans le cas de sites avec beaucoup d'utilisateurs et catégories)
version 2
z0rglub a écrit:
1. status par défaut
Les permissions se gèrent pour les catégorie "private" (colonne status). Par défaut, une catégorie est :
- status = $conf['newcat_default_status'] si la catégorie parente est public
- status = private si la catégorie parente est private
2. changement de status
Pour changer le status d'une catégorie, 2 écrans : admin/cat_options pour gérer de manière globale, admin/cat_modify pour gérer une catégorie à la fois. La règle est la suivante :
- si le status passe à private, toutes les sous-catégories en héritent
- si le status passe de private à public, toutes les sur-catégories en héritent (dans ce sens là, le verbe est mal employé...)
3. ajustement des permissions
Les permissions sont gérées par groupe et par user. Pour une catégorie privée, les permissions déterminent si l'utilisateur ou le groupe peuvent accéder à la catégorie. 3 écrans permettent de gérer les permissions :
- admin/group_perm : pour un groupe donné, liste les catégories privées. Les catégories actuellement autorisées sont en verts, les interdites, en rouge.
- admin/user_perm : pour un utilisateur donné, liste les catégories privées. Les catégories actuellement autorisées sont en verts, les interdites, en rouge.
- admin/cat_perm : pour une catégorie privée donnée, liste les groupes et les utilisateurs. Pour chaque ligne (représentant un groupe ou un utilisateur) propose de passer à permis ou interdit. Pour faciliter la lecture des permissions en cours, un groupe ou un utilisateur ayant la permission est affiché en vert, s'il n'a pas la permission, en rouge.
Ce dernier écran me paraît important, mais je ne le trouve plus. Il est difficile, voire impossible à gérer avec un grand nombre d'utilisateurs. Ne pourrait-on pas imaginer un écran avec une liste multipage sur les groupes ou les utilisateurs ?
Règles de gestion :
- pour un groupe ou un utilisateur, passer une catégorie à interdit rend les sous-catégories interdites
- pour un groupe ou un utilisateur, passer une catégorie à autorisée rend les sur-catégories autorisées *
- pour un groupe, si on passe une catégorie à autorisée, tous les membres du groupe sont autorisés pour la catégorie + les catégories parentes *
- pour un groupe, si on passe une catégorie à interdite, pas de répercussion sur les membres
- la suppression d'un groupe ou l'exclusion d'un utilisateur à un groupe fait perdre les permissions (des membres) gagnés grâce au groupe
- un nouvel utilisateur récupère automatique des permissions de l'utilisateur "guest"
- lorsqu'un utilisateur rejoint un groupe, ses catégories interdites sont diminués des catégories autorisées au groupe
* c'est un peu dangereux, mais je considère que l'admin sait ce qu'il fait ou qu'il prend soin de ne créer que des catégories mère (catégorie ne contenant que des sous-catégories) ou catégories filles (catégories ne contenant que des éléments)
4. stockage des informations
La table user_access est supprimée, au profit de la table user_forbidden :
- user_forbidden liste les catégories interdites pour un utilisateur. Table avec données calculées.
- user_access liste les catégories privées autorisées pour un utilisateur
- group_access liste les catégories privées autorisées pour un groupe
La table user_forbidden contient 3 champs {user_id, categories, need_update}. Le champ categories est le strict équivalent au users.forbidden_categories de la branche 1.3
Les données de cette table ne sont recalculées que lors de l'affichage de la page par l'utilisateur et que la colonne need_update est à 'true'. La colonne est passée à "true" à diverses occasions :
- l'utilisateur rejoint ou quitte un groupe
- nouvelles ou obsoletes catégories privées
- changement de permissions de l'utilisateur
- changement de permissions d'un groupe dont l'utilisateur est membre
- ...
version 1
z0rglub a écrit:
1. status par défaut
Les permissions se gèrent pour les catégorie "private" (colonne status). Par défaut, une catégorie est :
- status = $conf['newcat_default_status'] si la catégorie parente est public
- status = private si la catégorie parente est private
2. changement de status
Pour changer le status d'une catégorie, 2 écrans : admin/cat_options pour gérer de manière globale, admin/cat_modify pour gérer une catégorie à la fois. La règle est la suivante :
- si le status passe à private, toutes les sous-catégories en héritent
- si le status passe de private à public, toutes les sur-catégories en héritent (dans ce sens là, le verbe est mal employé...)
3. ajustement des permissions
Les permissions sont gérées par groupe et par user. Pour une catégorie privée, les permissions déterminent si l'utilisateur ou le groupe peuvent accéder à la catégorie. 3 écrans permettent de gérer les permissions :
- admin/group_perm : pour un groupe donné, liste les catégories privées. Les catégories actuellement autorisées sont en verts, les interdites, en rouge.
- admin/user_perm : pour un utilisateur donné, liste les catégories privées. Les catégories actuellement autorisées sont en verts, les interdites, en rouge.
- admin/cat_perm : pour une catégorie privée donnée, liste les groupes et les utilisateurs. Pour chaque ligne (représentant un groupe ou un utilisateur) propose de passer à permis ou interdit. Pour faciliter la lecture des permissions en cours, un groupe ou un utilisateur ayant la permission est affiché en vert, s'il n'a pas la permission, en rouge.
Ce dernier écran me paraît important, mais je ne le trouve plus. Il est difficile, voire impossible à gérer avec un grand nombre d'utilisateurs. Ne pourrait-on pas imaginer un écran avec une liste multipage sur les groupes ou les utilisateurs ?
Règles de gestion :
- pour un groupe ou un utilisateur, passer une catégorie à interdit rend les sous-catégories interdites
- pour un groupe ou un utilisateur, passer une catégorie à autorisée rend les sur-catégories autorisées *
- pour un groupe, si on passe une catégorie à autorisée, tous les membres du groupe sont autorisés pour la catégorie + les catégories parentes *
- pour un groupe, si on passe une catégorie à interdite, pas de répercussion sur les membres
- la suppression d'un groupe ou l'exclusion d'un utilisateur à un groupe ne fait pas perdre les permissions (des membres) gagnés grâce au groupe
- un nouvel utilisateur récupère automatique des permissions de l'utilisateur "guest"
- lorsqu'un utilisateur rejoint un groupe, ses catégories interdites sont diminués des catégories autorisées au groupe
* c'est un peu dangereux, mais je considère que l'admin sait ce qu'il fait ou qu'il prend soin de ne créer que des catégories mère (catégorie ne contenant que des sous-catégories) ou catégories filles (catégories ne contenant que des éléments)
4. stockage des informations
La table user_access est supprimée, au profit de la table user_forbidden :
- user_forbidden liste les catégories interdites pour un utilisateur
- group_access liste les catégories privées autorisées pour un groupe
- users.forbidden_categories est supprimée, la récupération des catégories interdites devient simplissime avec le nouveau modèle, plus besoin de stocker des données calculées
Là comme ça, et après 2 heures de réflexions pour écrire ce post, je dirais que ça tient la route, j'aimerais le soumettre sur le forum français [...]
à vous