Discussion:SiteWeb:Prestations

Gestion des droits d'accès

Log irc mercredi 30 juin 2010 :

08:22 < mongolito404> Hoi
08:46 < madix> coin
09:11 < mongolito404> Est-ce que j'avance sur le remplacement de OG par "Taxonomy Access" ou "Taxonomy Access Lite" ? (cf. https://redmine.april.org/issues/140)
09:11 < mongolito404> Soit en choisir un des deux ("Taxonomy Access" et "Taxonomy Access Lite" probablement) et écrire le script de migration pour migrer le contenu OG en en protégeant l'accès (au lieu de le supprimer comme actuellement).
09:15 < olive> pas compris
09:16 < olive> ah. heu
09:16 < olive> t'as une préférence ?
09:17 < olive> :)
09:17 < mongolito404> Oui, j'ai une préférence pour Taxonomy Access Lite
09:18 < olive> je bouge sur un vrai pc pour lire le redmine
09:18 < olive> 5 min
09:22 < olive> mongolito404: si les besoins évoluent, tu penses que l'on pourra passer de TAL à TA ?
09:22 < olive> (sous entendu, "facilement")
09:23 < mongolito404> Oui, les deux modules se basent sur la catégorisation de nodes
09:23 < mongolito404> Donc passer de l'un à l'autre se résume à configurer le second pour qu'il se comporte comme le premier
09:23 < mongolito404> Les nodes eux même ne doivent pas être modifiés
09:25 < olive> fonce donc sur TAL alors :)
09:28 < mongolito404> Vendredi passé, j'avais posé une question qui est restée sans réponse.
09:28 < mongolito404> Sur www.april.org, il y a un vocabulaire de catégorie "Thème Membres", mais il n'est aossicé à aucune type de contenu.
09:28 < mongolito404> Par contre, ses termes sont utilisés pour classifier des pages.
09:28 < madix> mongolito404: je regarde pour OG
09:28 < mongolito404> Qqn sait si ces termes sont assignés au nodes par OG ou si c'est un reste du passé ?
09:28 < mongolito404> Exemples:  http://www.april.org/fr/categorie/themes-membres-0 et http://www.april.org/fr/categorie/themes-membres-1
09:28 < mongolito404> Voilà la question
09:29 < madix> je regarde
09:32 < madix> mongolito404: je ne comprends pas trop :) mais j'ai l'intuition que ce sont des restes du passé, des résidus de tests en gros
09:33 < olive> mongolito404: pour ma part, je n'en ai aucune idée
09:33 < madix> mongolito404: quel impact cela a sur la migration ?
09:33 < madix> eseyman: là ?
09:33 < eseyman> oui
09:33 < eseyman> madix: oui
09:34 < madix> eseyman: tu connais "Taxonomy Access" et/ou "Taxonomy Access Lite" ?
09:34 < eseyman> non, pas du tout.
09:35 < madix> vous utilisez quoi vous chez parinux pour restreindre l'accès à certaines pages ?
09:35 < madix> mongolito404: tu as déjà utilisé en prod l'un des modules ?
09:38 < mongolito404> madix: Pas d'impact sur la migration pour ce vocabulaire, mais je pourrais le ré-utiliser pour "Taxonomy Access Lite".
09:38 < mongolito404> Et non, je n'ai jamais utilisé l'un ou l'autre en prod.
09:39 < madix> je lis les pages concernant ces modules
09:39 < madix> mongolito404: et au niveau "activité de dev des modules" il y a des différences ? l'un est plus vivant que l'autre, mieux maintenu... ?
09:40 < madix> dans Drupal5 on a du installer un module view_unpublished je crois pour permettre la modification de node créés par un autre user
09:40 < madix> dans Drupal6 ça fonctionne différemment ?
09:41 < madix> je demande car le module view_unpublished a créé des trous de sécu :)
09:42 < mongolito404> Je crois que dans Drupal6 ont a la possibilité de voir un node non publié si on a le droit d'édition sur ce node
09:42 < mongolito404> view_unpublished est toujours dispo sur Drupal6
09:42 < eseyman> pour parinux, on utilise les rôles. On a animateur et administrateur
09:43 < mongolito404> eseyman: Oui mais quelle module est utiliser pour controller l'accès sur base de ces rôles ?
09:43 < madix> si on peut se passer de view_unpublished ce sera bien :)
09:43 < mongolito404> Par défaut Drupal n'a pas un contrôle d'accès très poussé
09:44 < eseyman> on utilise ensuite des types de contenus spécifiques
09:45 < eseyman> c'est pas très travaillé mais on n'a pas les contraintes de l'april, non plus
09:46 < eseyman> mongolito404: pour #132, http://wiki.parinux.org/drupaltravaux:index et http://bugzilla.parinux.org/show_bug.cgi?id=1
09:46 < madix> mongolito404: tu disais <mongolito404> Oui, j'ai une préférence pour Taxonomy Access Lite
09:46 < madix> mongolito404: pour quelle(s) raison(s) ?
09:47 < olive> madix: plus simple à configurer
09:47 < mongolito404> L'interface d'admin est plus simple
09:47 < mongolito404> et plus claieze
09:47 < mongolito404> *claire
09:49 < madix> mongolito404: ok
09:49 < madix> mongolito404: la partie remplaçant OG tu t'en occupes aujourd'hui ou vendredi ?
09:50 < mongolito404> madix: Si je ne m'en occupe pas adh, il faut que je trouve autre chose à faire
09:51 < madix> adh ?
09:51 < mongolito404> aujourd'hui
09:52 < madix> j'essaye de faire venir sur le salon un expert Drupal et module controle d'acces pour avoir un avis
09:52 < madix> ce genre de trucs je me méfie depuis OG :)
09:53 < madix> si quelqu'un a déjà l'expérience des deux ça peut être utile :)
09:53 < olive> en même temps, il me semble qu'il n'y a pas d'autre module envisageable, si ?
09:53 < madix> mongolito404: sinon, tu as déjà vu avec les admins pour la partie passage en prod (préparation d'un vserver...) ?
09:54 < mongolito404> madix: non
09:54 < madix> olive: je ne sais pas, je demanderai bien au responsable technique du site :)
09:54 < madix> theocrite: là ?
09:54 < madix> mongolito404: tu ne sais donc pas quel serveur physique ils veulent utiliser ?
09:54 < mongolito404> olive: COmme options je vois Taxonom Access, taxonomy Access Lite et Content Access.
09:55 < madix> ça en fait un 3ème :)
09:55 < olive> mongolito404: il me semble qu'on les avait écartés, non ?
09:55 < olive> hmm, je viens de voir que TA et TAL ne sont pas maintenus par les mêmes personnes.
09:55 < mongolito404> J'ai écarté Node Access qui n'est pas compatible avec Views
09:56 < mongolito404> Dans le README de TAL il justifie pourquoi i la fait TAL qui semble redondant avec TA
09:56 < olive> je regarde
09:58 < olive> (faut dire TAC et TAC_L en fait)
09:58 < mongolito404> J'ai, pour l'instant, écarté Content Access car il ne me semble pas offrir les fonctionnalité pour gérer simplement les droits d'accès voulus.
10:00 < olive> TAC_L m'a l'air propre
10:00 < olive> (Taxonomy Access Control Lite)
10:03 < madix> question : pour tac_lite il est écrit "A simple scheme based on taxonomy, roles and users controls which content is visible"
10:04 < madix> pour tac il est écrit "Five permission types (View, Update, Delete, Create, List)"
10:04 < madix> question bête donc : tac_lite gère que la visibilité d'un node ?
10:05 < madix> la partie View
10:06 < olive> mongolito404 ?
10:06 < mongolito404> Non TAC_L permet de configurer les droit view, update, delete
10:07 < mongolito404> De base, un utilisateur peut créer une node qu'il ne peut ensuite ni voir ni éditer
10:07 < mongolito404> Il y a un (récent) module additionnel pour empêcher ça
10:08 < madix> je ne comprends pas le "De base, un utilisateur peut créer une node qu'il ne peut ensuite ni voir ni éditer"
10:08 < madix> un user crée un node et ensuite il n'y a plus accès ?
10:09 < mongolito404> Oui
10:09 < madix> de base dans Drupal6 ?
10:09 < madix> désolé si je pose des questions cons :)
10:09 < mongolito404> Non avec TAC_L
10:09 < mongolito404> http://drupal.org/node/464116
10:10 < mongolito404> Mais il ya un module additionnel pour corriger le problème http://drupal.org/cvs?commit=383056
10:14 < mongolito404> Mais c'est récent comme dev.
10:15 < madix> c'est dans le cas où l'utilisateur crée un node dans un vocabulaire dont il n'a pas les droits de lecture donc ?
10:16 < madix> ce matin j'ai un peu de mal avec mes neurones
10:16 < mongolito404> Mais je ne pense pas que ce soit un problème bloquant. C'est clairement un problème d'utilisabilité, mais si la valeur par défaut est de laisser le node public, ca ne devrait pas être un problème.
10:17 < mongolito404> madix: Oui, par exemple un utilisateur non membre du CA pourrait créer une page réservé au membres du CA.
10:17 < mongolito404> Après création, en toute logique, il n'a pas accès à la page.
10:17 < madix> mongolito404: c'est une fonctionnalité marrante et potentiellement utile
10:18 < madix> mais je ne sais pas pourquoi il doit y avoir des effets de bords :)
10:19 < madix> dans tac_lite il y a aussi la restriction par user
10:19 < mongolito404> Oui, ce qu'il n'y a pas dans tac
10:19 < madix> oui
10:20 < mongolito404> Je ne sais pas si ca peut-être pratique pour l'april
10:20 < mongolito404> s/pratique/utile
10:20 < madix> ça peut
10:20 < mongolito404> Vous connaissez mieux vos besoins que mo
10:21 < madix> genre donner accès à 1 page à un utilisateur spécifique (lors de rédaction/validation de textes avec une autre structure)
10:21 < mongolito404> TAC_L gère les accès par catégorie
10:21 < madix> liot: on a une page wiki qui explique nos besoins concernant les restrictions d'accès ?
10:22 < mongolito404> Donc il est possible de donner, temporairement, à un utilisateur  les droits d'accès à une catégoire mais pas un une sule page.
10:24 < madix> ah oui, c'est de la restriction d'accès par catégorie
10:24 < madix> il n'y a pas de module qui fait les deux (par catégorie et par node) ?
10:24 < mongolito404> Mais évidement, vous pouvez créer une catégorie pour une autre structure et l'utiliser pour une seule page.
10:24 < mongolito404> madix: Non, je n'ai pas trouvé de combo.
10:25 < mongolito404> Il est peut-être possible de combiner TAC_L et Access Content pour obtenir l'effet voulsu, mais je ne sais pas si ils sont compatibles.
10:26 < madix> ok
10:26 < mongolito404> D'après http://drupal.org/node/485682#comment-2073714 TAC et AC ne sont pas compatibles
10:26 < madix> j'ai l'intuition que combiner deux modules de controle d'accès c'est prendre de gros risques :)
10:27 < mongolito404> madix: Oui
10:29 < madix> Content Access a l'air puissant non ?
10:29 < mongolito404> madix: Oui
10:29 < madix> pourquoi il ne convient pas en fait ?
10:31 < mongolito404> Je n'ai pas vérifier mais je ne pense pas qu'il puisse servir pour configurer des droits d'accès par catégorie de pages
10:32 < mongolito404> Je test
10:33 < madix> eseyman: olive vous connaissez Content Access ?
10:36 < mongolito404> Content Access est compatible avec ACL pour des droits d'accès par node, et avec Rules pour configurer les drotis d'accès aux nodes par événements.
10:36 < olive> madix: non
10:43 < eseyman> non plus
10:44 < madix> si je pige bien Content Access permet de configurer des droits d'accès par type de page principalement alors que les deux autres permettent de configurer par catégorie de contenu
10:44 < madix> right ?
10:47 < mongolito404> madix: Oui
10:47 < mongolito404> Avec le module Rules il est potentiellement possible de configurer une règle qui modifies les droits d'accès à un node en fonction se sa catégorie.
10:47 < mongolito404> Mais c'est plus de boulot
10:50 < mongolito404> A première vue, Content Access est plus robuste que TAC et TAC Lite (il ya même une suite de test automatisé, youpie)
10:50 < mongolito404> L(avantage de TAC Lite est d'être simple à mettre en place
10:52 < madix> j'avoue avoir du mal à évaluer les possibilités par rapport à nos pratiques actuelles et nos besoins
11:04 < madix> olive: qu'en penses-tu ?
11:05 < madix> mongolito404: tu es totalement bloqué tant qu'on a pas décidé ?
11:06 < mongolito404> madix: Pas complètement, je peux m'occuper de la migration Event => Caldendar + Date qui elle ne pose pas vraiment de question
11:06 < olive> madix: si j'ai bien suivi, vous décelez une limitation à TAC_Lite ?
11:07 < olive> (voire TAC tout court)
11:08 < madix> mongolito404: fais ça alors stp
11:08 < olive> il faut tester pour être sur ?
11:08 < madix> voilà, là j'ai du mal à voir ce qu'on pourrait faire avec ces trois modules
11:08 < mongolito404> "ça" == migration Event => Calendar + Date ?
11:08 < madix> mongolito404: oui
11:09 < mongolito404> ok
11:35 < madix[away]> je reviens vers 14h30 je pense
11:35 < madix[away]> olive: on se voit à 15h
11:36 < olive> yep
13:34  * mongolito404 se bat avec la gestion des timezone dans les modules event et date
14:27 < madix> back
14:29 < madix> mongolito404: tu as un pb ? Je crois me souvenir avoir du faire une modif dans le module event mais je ne sais plus trop quoi
14:30 < mongolito404> Non je me suis perdu dans la gestion des timezone mais maintenant c'est ok
15:05 < mongolito404> w00t, la migration Event -> Date + Calendar est faire, reste à écrire le test windmill :D
15:09 < madix> cool
15:09 < madix> je dois m'absenter avec olive, bbl
15:10 < olive> tu pourrais plus discret !
15:44 < mongolito404> re
15:45 < mongolito404> Quels sont les pages présentant des événements à conserver/à avoir sur le site post-migration ?
15:47 < mongolito404> http://www.april.org/event ?
16:13 < madix> mongolito404: toutes ? :)
16:14 < mongolito404> Oui mais quelles sont-elels exactement, je ne trouve que http://www.april.org/event
16:15 < madix> http://www.april.org/en/event/2010/06/30/month/all/all http://www.april.org/en/event/2010/05/01/month/all/all/1 ...
16:16 < madix> moi je clique sur Month pour remonter les évènements
16:16 < madix> je ne sais pas si une page les liste tous
16:29 < mongolito404> Ok, ca c'est aussi /event
16:30 < mongolito404> Qui avec out of the bow, avec Date + Calednar donne ceci: http://test.april.org/en/event/
16:32 < mongolito404> Qqn sait à quoi correspondent les couleurs jaune et rouge sur http://www.april.org/en/event ?
16:38 < eseyman> chaque évènement a son code couleur, attribué de manière aléatoire, de mémoire
16:44 < mongolito404> Grmbl, les dates ne sont pas toujours bine converties... http://www.april.org/en/stand-au-salon-solutions-linux-2010 vs. http://test.april.org/en/stand-au-salon-solutions-linux-2010
16:46 < olive> arg
17:47 < theocrite> "< madix> theocrite: là " <= Maintenant oui (mais ça a du ping timeouter depuis le temps)