Re: API autoriser

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 ?

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