Re: API autoriser

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



>> 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
>
>
>