Re: API autoriser

En fait j'ai vraiment l'impression que tu veux étendre ce que fait la
Fabrique (qui est largement basée du plugin Autorité que mentionne Fil)

2015-11-24 19:40 GMT+01:00 David Fredette <[email protected]>:

>
> Le 2015-11-24 à 13:30, Gilles Vincent <[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]
> >:
>
>> Le 2015-11-24 à 11:42, Gilles Vincent <[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 sur 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
>
>