Re: API autoriser

Le 24/11/2015 17:16, David Fredette a écrit :
> Je me demandais s’il y avait un groupe de travail ou un endroit ou il y a des réflexions de faite concernant l’évolution
> de l’API « autoriser » …
> J’utilises beaucoup SPIP pour gérer des intranets entre autre, et l’API actuel est fonctionnel, mais quand on ajoutes
> plusieurs type d’objet, je trouves qu’il devient lourd a gérer…
> J’ai des réflexions et des idées, mais avant de me mettre a écrire du code pour moi tout seul, je me demandais s’il y
> avait déjà des gens qui travaillais sur l’évolution de cet API et si je pourrais m’y joindre ! :)

Tes propositions sont intéressantes.

Pour ma part aujourd'hui j'ai aus gambergé sur les autorisations :
non pas pour cause de trop d'objets et statuts prédéfinis,
mais pour cause de règles complexes car dépendant de nombreux facteurs
pour attribuer ou non les autorisations ;
et parce que je voudrais savoir mieux, après avoir utilisé une autorisation,
pour laquelle des raisons internes cette autorisation a été refusée ou accordée.

Pour filer ton exemple d'intranet, une réponse à une demande
de 'pourquoi un accès à l'intranet de la comptabilité est refusé'
serait "pas_dans_le_service_compta" ou "habilitation_périmée"
selon les règles de décision.

Pour cela j'ai voulu utiliser #AUTORISER en lui passant un paramètre
(soit $type soit $opt soit une valeur du tableau $opt si c'est un tableau)
valant 'pourquoi', pour indiquer qu'on voulait la raison et non le résultat.

* @example
* ```
* [(#AUTORISER{modifier,rubrique,#ID_RUBRIQUE}) appel normal, résultat booléen-spipien ]
* [(#AUTORISER{modifier,rubrique,#ID_RUBRIQUE,'',pourquoi}) résultat chaine car ici on veut savoir pourquoi ! ]
* [(#AUTORISER{statistiques,pourquoi})
* ...  sucre syntaxique lorsqu'il n'y a qu'un seul ou peu d'arguments :
* ...  ça évite les '' pour les arguments non utilisés]
* [(#AUTORISER{rubrique_modifier,pourquoi,#ID_RUBRIQUE}) idem ]

J'ai créé une fonction balise_AUTORISER
car la version _dist convertit tout résultat en ' ' et ''
et là il faut l'éviter dans les cas où le paramètre vaut 'pourquoi'.

ça élargit donc un peu l'API

Les fonctions d'autorisations qui acceptent le 'pourquoi'
doivent tester la présence de ce paramètre et lorsqu'il est là renvoyer
une chaîne à afficher telle quelle,
ou bien qui pourra servir de clé de chaine de langue
ou bien être testée pour d'autres traitements comme le debuging
ou la personnalisation, dans les squelettes, de l'action ou du message
d'acceptation ou de refus.

Pour faciliter ce dernier usage j'ai fait 2 balises #SWICH et #CASE.
Je les mettrai quelque part sur la zone (si elles y sont pas déjà...)
car elles peuvent servir dans d'autres contextes.


Au passage l'ordre des paramètres pour #AUTORISER
est l'action, puis le type,
alors que dans le nom des fonctions d'implémentation c'est l'inverse.
Ce serait à éviter si jamais yavait une grosse refonte de l'API !

JL