Re: API Autoriser ! ;)

Le 21/08/2016 à 16:01, David Fredette a écrit :
>
> Envoyé de mon iPhone
>
>> Le 21 août 2016 à 09:33, YannX SPIP <[email protected]> a écrit :
>>
>>> Le 21/08/2016 à 14:47, David Fredette a écrit :
>>> Il y a une option pour demander que pour les 3 statut d'auteur de base de spip passe par le système "original"...
>> Pour mémoire, j'ai récupéré la discussion initiale du 25/10/2015 sur
>> Spip-dev
>>> Également, j'essaie de faire en sorte que cela conserve sensiblement la même structure pour que cela puisse, à terme remplacer le système actuel sans trop de heurt ...
>> Si j'ai bien compris une remarque de Fil il suffit d'ecrire une fonction
>> autoriser()) qui surchargerait la fonction du core pour...
> C'est ce que j'ai commencer a faire dans ce que j'ai soumis ! Et avant d'aller trop loin, c'est là que je demande des avis !!
>
>
>>> Ça fait parti de la doc et des commentaires dans les fichiers... Et je suis ouvert aux commentaires pour aider à cela ...
>>>
>>> Je crois qu'il y aurait moyen de faire en sorte que seule une déclaration des droits utilisé par le plugin dans le nouveau pipeline acl soit nécessaire ...
>>>
>>> Mon but n'est pas de tout casser ...
>> Je complète déjà  un article de Carnet pour faire un peu le point des
>> diverses initiatives :
>> https://contrib.spip.net/4821
>>
> J'ai regarder la plupart de ces plugins et ils ont tous à priori le même défaut, ils sont associer à un statut d'auteur pour décider de ce que la personne peut ou ne peut pas faire ...
Accès restreint fonctionne un peu différement, en associant DES auteurs 
à un nom de zone !
Et je proposais un jour de créer dans ce plugin la fonction 
autoriser_zones_dist(),
qui pourrait donner lieu à la programmation assez simple de tous droits
dans les squelettes.

> Ce à quoi j'espère en venir, c'est d'avoir une liste des droit disponible, de pouvoir faire des groupes qui rassemble différents droits, de pouvoir assigner un ou plusieurs groupe de droit à un utilisateurs et pouvoir compléter d dans la fiche d'un utilisateur de façon granulaire ce à quoi un utilisateur a accès ou pas ...
J'avais conçu mon ébauche d'idée (je n'en ai pas retrouvé mes docs 
ecrites de l'epoque)
a peu près dans le meme objectif, et avec les caractères génériques prévus,
cela permet d'interfacer directement une gestion de groupes avec toute 
autorisation spéciale.


> Donc on pourrait avoir un auteur qui peut écrire des articles sans pouvoir les publier sur l'espace public, mais qui aurait aussi accès aux statistiques, à traiter des bon de commande sans voir les paiements effectuées , le tout en sélectionnant seulement les droits dans la fiche de l'utilisateur sans devoir programmer de fonctions ...
A l'inverse, pour pouvoir y associer 'tous' les droits traditionnels, 
soit on les inscrit "à la mano" dans l'interface (d'ou ma réflexion d'en 
reconstituer uen hiérarchie plus complète),
soit on les saisit manuellement dans la table ACL (directement inspirée 
des systèmes de gestion des droits utilisés dans tous les gros 
progiciels de gestion RH, FI, etc...
Le systeme de droits presente uen gestion plus facile par des zones 
génériques par défaut
(en appliquant les filtrages SQL d'une manière analogue aux surcharges 
SPIP d'autorisations).
> Et je crois qu'en ajoutant la déclaration des droits disponible pour chaque plugins ainsi que de la base de spip au pipeline acl on peut y arriver sans changer la façon d'utiliser la balise autoriser dans les squelettes ni la façon d'écrire des fonction supplémentaire pour valider un peut plus que juste si l'utilisateur a le droit ou pas !
>
> On éviterais probablement l'écriture de beaucoup de fonction très basique ( les fonctions n'étant plus nécessaire à la validation des droits) tout en les conservant pour des éléments plus pointilleux !
Oui /juste a bien définir le ET/OU dans la fonction core-racine 
autoriser() entre les retour,
des fonctions autoriser_ traditionnelles et les calculs-fonctions 
d'après la table ACL

maintenant uen gestion par table, c'est très bien, mais la multiplicité 
(explosion combinatoire) oblige :
- à des valeurs par défaut (par les caractères génériques), qui seraient 
introduites par le core
(ou rajoutées autoamtiquement par les plugins (en sélectionnant le nom 
de plugin dans le cham "options")
- a des ecrans/squelettes d'interface plus élaborés que l'actuelle 
selection d'auteurs
(déja rapidement pénible, par exemple qd on doit sélectionner a la main 
tous les inscrits depuis telle année.... ;-))
mais cela ne represnete pas uen grande difficulté technique : juste 
ecrire d'autres noisettes dans le privé

PS mais j'avoue n'avoir encore que "relu", et pas "etudié" ton travail.
j'ai donc certainement l'opportunité de changer d'avis

@+

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