PS mais j'avoue n'avoir encore que "relu", et pas "etudié" ton travail.
j'ai donc certainement l'opportunité de changer d'avis
Ça serait peut-être bien de commencer par la ...
A la lecture de tes réponse, une grosse partie à été écrit pour rien et ne s'applique pas du tout à ma proposition !! ;).
Premiere reflexion : ta structure $table_des_droits me parait avoir une
vue trop restrictive et n'est pas extensible ; je dis cela en vieil
habitué des structurations de BDD (normalisation), la
sélection-firltrage peut s'opérer par SQL (donc plus rapidement, surtout
sur de grosses populations d'objets et/ou d'individus) sans avoir à
décoder l'array sérialisé "droits" ; par contre, je reprends ton idée de
"libellé" du droit pour mieux expliquer son usage (cela pourrait être
inscrit dans l'initialisation des constantes du plugin pour reprendre
les droits standard, puis étendu par un autre pipeline pour mise à
dispositon des plugins qui ne voudraient pas ecrire dans la BDD
directement !)
Tu parles de quelle partie ici…
Actuellement, j'ai 2 choses… J'ai le pipeline acl qui génère un array avec la liste de tout les droits disponible et le seul stockage que j'ai dans la base de données, c'est dans le nouveau champ acl qui s'ajoute a spip auteur.
Question d'éviter de faire une requête sql a chaque fois, je me suis dis qu'en mettant ça dans le champ acl, il doit y avoir moyen soit de mettre le contenu de ce champs en cache ou directement dans la balise SESSION et de le déserializer une seule fois lors du login (et par la suite, forcer la MAJ lors de la MAJ des droits)…
Actuellement, la seule chose qui s'inscrit dans la BDD, c'est vraiment les droits de chaque auteurs qui s'insère dans spip_auteurs dans le champs acl…
Donc s'il y a plus efficace que ce que je décris ci-haut, je suis ouvert… Mais si tu peux être un peu plus concret dans ta proposition de cette gestion (genre bout de code ou exemple tiré d'un autre plugin ou ….) parce que pour l'instant, je ne suis pas certain de suivre ton raisonnement…
Cette structure de BDD, sous réserve de définir une fois dans le core
les héritages de hiérarchie entre droits, satisfait à la reprise des
fonctionnements existants, et des droits "0minirezo"....
Mais en-dehors des fonctions d'interface d'administration liant à la BDD
/et avant de relire le code/ pas d'autres changements fonctionnels ; il
reste juste a voir comment ajouter le traitement des exceptions
temporaires dans la BDD (cf. le cham "options".
Parles-tu de la structure d'information qui est stocké dans le champs acl de spip_auteurs ?
Tu entends quoi par exception temporaire ?
Je ne comprends pas bien la Phase 1-6 "mettre en place un systeme de
fonction étendue"
De base, le système vérifie par exemple, si l'utilisateur a le droit "modifier_rubrique" (par exemple) … Mais je veux qu'on puisses ajouter dans l'interface des options étendue comme par exemple, si un user a des droits sur des rubriques, que l'on puisse sélectionner une ou plusieurs rubriques qu'il aura le droit de voir, modifier, supprimer (de façon unique pour chaque droit) …
Ainsi, il faut a la voir pouvoir surcharger le formulaire d'édition des droits pour que si le droit "voir_rubrique" est sélectionné, un élément de l'interface va permettre de sélectionner une ou plusieurs rubrique qui sera assigné au droit, et également, les fonctions qui effectueront la validation au de la de simplement posséder le droit pour s'assurer que la rubrique fait bien partie de celle qu'il a le droit de voir/modifier/supprimer…
Dans 90% des cas, je crois que le simple fait que le droit soit sélectionné sera suffisant mais le 10% de cas particulier est très important a gérer…
En regardant quelque peu le code de SPIP et des plugins, je crois
pouvoir affirmer que le systeme d'un autoriser_bdd() que j'evoque reste
totalement compatible en co-existence avec l'existant (dès lors que les
dev-core acceptent de rajouter deux lignes dans le code de
ecrire/inc/autoriser[114] pour tester l'existence de
autoriser_bdd_dist() et le OR sur les deux resultats), y compris avec
des plugins non encore connus, ce qui repond à l'objection de JLuc.
Ici, j'ai rien compris……
En outre le stockage en BDD d'une table spip_acl (sur le modèle des
tables de liens déja souvent utilisé en SPIP) telle que je l'ai définie
peut parfaitement se satisfaire ensuite me semble-t-il d'une mise en
cache de fonctions d'autorisations pré-compilées pour accélerer le
systeme, ce qui eviterait donc une surchagee de la BDD à l'exploitation…
Tu parles ici d'avoir une table acl plutôt que le pipeline pour avoir la liste de tout les droits ou tu verrais une table acl pour gérer les droits associé aux utilisateur pour gérer leur droits individuel et avoir plus de souplesse pour gérer les ajouts ???
