Re: API autoriser

Le 25/11/2015 10:15, JLuc a écrit :
> Le 24/11/2015 20:01, David Fredette a écrit :
>> Le 2015-11-24 à 13:43, Gilles Vincent <[email protected] 
>> <mailto:[email protected]>> a écrit :
>> Moi, c’est un peu ce modèle de base que je veux revoir ! :P
>
> À part pour la partie déclarer_tables_objets_sql,
> il me semble que c'est pas tant que tu veux revoir le modèle de base,
> mais c'est que tu veux l'utiliser
> pour créer une nouvelle interface click'n'autorise.
>
> Je crois que c'est ce à quoi en viennent plusieurs commentaires.
>
> Donc à mon avis :
> ton interface click'n'autorise sera bienvenue.
> Elle a souvent été évoquée sur ces listes et aussitôt rejetée
> parceque personne était prêt à s'en coltiner la fabrication.
> (cherche "clicodrome" dans les archives...)
>
> Mais en complément avec l'extension de déclarer_tables_objets_sql
> ça semble bien intéressant.
> AMA C'est ce point là qu'il faudrait que tu discutes sur cette liste,
> dans un autre thread dédié, car pour le reste tu peux utiliser la zone
> pour proposer et déposer du code.
> Il faudra assurer la compatibilité avec les autres plugins en relation,
> éventuellement en les mettant à jour :
> 'autorité' bien sur, mais surtout aussi 'acces restreint'.
>
> JLuc
Réponse directe à David sur uen conception d'un plugin ACL
qui -s'appuyant sur une table spip_ACL -
générerait les autoriser_......  nécessaires a la volée
(ce qui garantit la compatibilité SPIP)

@ suivre (intéret YannX)
>
>
>
>>> 2015-11-24 19:40 GMT+01:00 David Fredette 
>>> <[email protected] 
>>> <mailto:[email protected]>>:
>>>
>>>
>>>     Le 2015-11-24 à 13:30, Gilles Vincent <[email protected] 
>>> <mailto:[email protected]>> a écrit :
>>>
>>>>     Bonjour, ça me semble compliqué ce que tu proposes.
>>>>     Il me semble que l'ajout de statuts personnalisés peut se faire 
>>>> dans SPIP en surchargeant le fichier
>>>>     ecrire/base/objets.php
>>>>     (comme n'importe quel plugin) :)
>>>>     Est-ce que j'ai tord ?
>>>
>>>     Je ne suis pas sur de comprendre ce que tu expliques…
>>>
>>>     Si tu parles par exemple, d’ajouter simplement un statut 
>>> d’auteur en utilisant par exemple :
>>>
>>>     $GLOBALS['liste_des_statuts']['info_utilisateur_intranet'] = 
>>> 'intranet’;
>>>
>>>     oui, on peut ajouter ce statut de façon très simple… Mais quand 
>>> vient le temps de dire ce que ce statut a le droit
>>>     de faire, c’est là qu’il faut écrire des fonctions pour chaque 
>>> objet et ça que j’essaie d’éliminer…
>>>
>>>     Dans le cadre d’un spip qui ne gère que 3 statut, ok, le 
>>> fonctionnement actuel, ça fait le travail… Mais, dans mon
>>>     cas, avec des intranet, il n’est pas rare que j’ai 10 statuts… 
>>> Alors pour chaque statut, je dois faire le tour des
>>>     objets de cet intranet et écrire des fonctions pour le nouveau 
>>> statut…
>>>
>>>     Avec ce que je décris ci-bas, les droits sur les objets sont a 
>>> même la table des objets et mes utilisateurs qui
>>>     administrent ces intranets peuvent se créer autant de statut 
>>> qu’ils veulent et assigne les droits qu’ils veulent a
>>>     chaque statut, sans avoir a écrire aucune nouvelle fonction…
>>>
>>>     J’ai besoin d’ajouter un nouveau droit pour un objet, je 
>>> l’ajoute a déclarer_tables_objets_sql et après, mes
>>>     administrateur d’intranet (non-programmeur) peuvent aller faire 
>>> le tour de leur propres statut qu’ils ont créé
>>>     pour décider qui aura ce droit et qui ne l’aura pas…
>>>
>>>>
>>>>     2015-11-24 18:52 GMT+01:00 David Fredette 
>>>> <[email protected] 
>>>> <mailto:[email protected]>>:
>>>>
>>>>         Le 2015-11-24 à 11:42, Gilles Vincent 
>>>> <[email protected] <mailto:[email protected]>> a écrit :
>>>>
>>>>         > Bonjour,
>>>>         >
>>>>         > il n'y a pas de tel groupe à ma connaissance.
>>>>         > Tu es sur la bonne liste de diffusion si tu veux 
>>>> communiquer par mail.
>>>>         > Sinon, tu peux aussi échanger surirc.spip.net 
>>>> <http://irc.spip.net/> avec marcimat, Cerdic, etc..
>>>>         > Quelles sont tes idées ?
>>>>         >
>>>>
>>>>         Ok… Je me lance avec mes réflexion actuel sur l’API 
>>>> autoriser. D’abord avec mes constats au sujet de l’API
>>>>         puis mes réflexions…
>>>>
>>>>         Comme j’arrive dans le sujet, il est possible qu’il y a des 
>>>> éléments la-dedans qui auront déjà été discuté
>>>>         par ceux qui discute sur cette liste depuis longtemps, 
>>>> soyez indulgent de ce côté ! ;)
>>>>
>>>>         Il est également possible que mes constats soient faux, 
>>>> n’hésitez pas a me faire par de fonctionnalités que
>>>>         j’aurais manqué au travers de mes différentes lectures sur 
>>>> le sujet…
>>>>
>>>>         Et finalement, si jamais les besoins que moi je ressens 
>>>> pour faire évoluer l’API autoriser de spip sort des
>>>>         besoin de spip lui-même et sont des besoins qui sont 
>>>> vraiment plus spécifique à mes besoins, n’hésitez pas à
>>>>         me le dire, et je me ferais un plugin pour surcharger cela 
>>>> et utilisera bien celui qui veut a partir de là ! ;)
>>>>
>>>>         Mes constats sur l’API Autoriser actuellement…
>>>>
>>>>         Dans le contexte ou on gère 3 statut de base (0minirezo, 
>>>> 1comite, 6forum) et que tout nouveau statut d’auteur
>>>>         est de base considéré comme un statut visiteur, l’API 
>>>> actuel fonctionne relativement bien… Mais, comme je
>>>>         l’ai dis précédemment, dans un contexte ou je me sers de 
>>>> SPIP pour gérer des intranet, ces 3 statuts sont
>>>>         nettement insuffisant et ne permet pas d’avoir beaucoup de 
>>>> souplesse à moins de se mettre a écrire pleins de
>>>>         fonction et/ou de surcharger des fonctions actuel…. Il est 
>>>> d’ailleurs très difficile avec son concept actuel
>>>>         de créer une interface dans l’espace privé pour pouvoir 
>>>> créer de nouveau statut et d'assigner a ce statut des
>>>>         droits spécifique, les droits n’existant pas autrement que 
>>>> par création de fonctions…
>>>>
>>>>         Si je prends exemple au niveau de mes intranet, si dans mon 
>>>> intranet, j’ai des objet factures, clients,
>>>>         commandes, formulaires, etc, etc, et que je souhaite 
>>>> déléguer a une personne la gestion des utilisateurs pour
>>>>         qu’il puisse gérer les droits d’accès pour créer un droit « 
>>>> comptabilité » et assigner des droits sur les
>>>>         objet factures sans que cette personne ai accès au reste, 
>>>> c’est impossible de créer ce droit « comptabilité »
>>>>         sans passer par de la programmation…
>>>>
>>>>         Donc pour pouvoir arriver a créer des statut d’auteur « 
>>>> personnalisé » il faut commencer par être en mesure
>>>>         d’avoir une liste des droits disponible pour chaque objet. 
>>>> La première idée qui me vient donc en tête, c’est
>>>>         d’ajouter cela lors de la déclaration des objets par le 
>>>> pipeline declarer_tables_objets_sql …
>>>>
>>>>         Si dans cette table on ajout a notre objet quelque chose de 
>>>> ce genre :
>>>>         $tables[‘spip_mon_objet_quelconque’]
>>>>                 … blabla définition de la table …
>>>>                 … blabla les statut pour l’objet …
>>>>                 … blabla autres …
>>>>
>>>>                 ‘dtoits_autorisations’ => array(
>>>> ‘creer’ => array(
>>>> ‘texte_de_langue’ => ‘fichier
>>>>         de langue:string’,
>>>> ‘restreindre_rubrique’ =>
>>>>         ‘oui ou non’ /* Pour décider si pour ce droit, on peut 
>>>> choisir un secteur ou si c’est le droit point final */
>>>>
>>>>         ‘autres_options_qui_pourait_etre_interessante’ => ‘…'
>>>> ),
>>>> ‘modifier’ => array(
>>>> …..
>>>> ),
>>>> etc….
>>>>                                                         );
>>>>
>>>>
>>>>         En faisant cela, il devient possible d’écrire une fonction 
>>>> du genre :
>>>>
>>>>         liste_droit_objet($objet)
>>>>
>>>>         et ainsi récupérer une liste de droits disponible pour un 
>>>> objet en particulier…
>>>>
>>>>         Cela laisse même la possibilité pour un autre plugin qui 
>>>> aurait besoin d’ajouter un droit sur un objet
>>>>         existant pour xyz raison, d’aller l’ajouter en passant par 
>>>> le pipeline déclarer_tables_objets_sql …
>>>>
>>>>         Dans la fonction liste_droit_objet, on pourrait introduire 
>>>> certains droits de base ou exceptionnel comme
>>>>         webmestre ou des éléments de ce genre…
>>>>
>>>>         Ensuite pour compléter cette gestion de droits, 
>>>> j’ajouterait une table, par exemple spip_statut_auteur … qui
>>>>         se définirait a peu près comme ceci :
>>>>
>>>>         id_statut
>>>>         Titre
>>>>         libelle (le nom du droit, mais qui sera associé au statut 
>>>> de l’auteur… A moins qu’a partir de là, les droits
>>>>         des auteurs passent par une table de liens… Ça permettrait 
>>>> même qu’un utilisateur ai plus d’un droit… Mais au
>>>>         niveau de la structure de spip, l’utilisation du champ 
>>>> statut ne doit pas être si simple a remplacer…  )
>>>>         liste_des_droits qui serait un peu comme les meta de SPIP, 
>>>> un serialize (c’est comme ça qu’on dit ?? ;P ) des
>>>>         droits par objet que ce nouveau statut d’auteur peut faire …
>>>>
>>>>
>>>>         En gros, la base de mon idée est là… plutôt que d’avoir un 
>>>> paquet de fonction éparpillé un peu partout pour
>>>>         gérer les droits sur les objets spip, on pourrait avoir une 
>>>> seule fonction qui vérifie si la personne a un
>>>>         droit en fonction de son (ou ses) statut, et l’ensemble des 
>>>> droits possible pourrait être assigné a des
>>>>         nouveau statuts… On peut inclure les statuts de base 
>>>> (0minirezo, 1comite, 6forum)de spip actuel déjà dans la
>>>>         table par défaut, et après, on peut créer autant de statut 
>>>> que l’on veut en décidant des droits assigné a
>>>>         chaque statut…
>>>>
>>>>         Si cette idée allume quelque choses et est d’intérêt pour 
>>>> le coeur de SPIP, je suis partant pour écrire le
>>>>         code qui va avec, mais j’aimerais bien avoir de l’aide pour 
>>>> choisir les bons termes, les bon nom de fonction,
>>>>         etc, afin que celui puisse être éventuellement intégré au 
>>>> coeur de SPIP…
>>>>
>>>>         Si cette approche n’est pas intéressante pour le Core, 
>>>> alors je le ferais comme plugin, mais s’il y en as qui
>>>>         ont des suggestions pour la nomenclature, je suis preneur ! :)
>>>>
>>>     --
>>>     David Fredette
>>>
>>>
>>
>> -- 
>> David Fredette
>>
>>
>>
>
>
> _______________________________________________
> liste: http://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip
>
>


-- 
YannX
http://www.spippourlesnuls.fr