Les autorisations basiques

 Rappel de la syntaxe commune

Récapitulons les paramètres de la balise #AUTORISER et de la fonction correspondante (depuis Autorisations Dans Spip) :
function autoriser_dist($faire, $type='', $id=0, $qui = NULL, $opt = NULL)

API pour les fonctions et balises d’autorisation :

• $qui est :
  • vide (on prend alors visiteur_session, voir [143] function autoriser_dist())
  • un $id_auteur (on regarde dans la base)
    qui est traduit par autoriser_dist en un tableau décrivant l’auteur $qui
• $faire est une action (’modifier’, ’publier’...) : insensible à la casse, indiquée sans quote pour #AUTORISER
• $type est un type d’objet ou nom de table (’article’)
• $id est l’id de l’objet sur lequel on veut agir
• $opt (inutilisé en général) = options sous forme de tableau associatif
  // (par exemple pour préciser si l’autorisation concerne tel ou tel champ)

Le retour d’un test d’autorisation est : vide si refusé, ou un espace pour valider (et afficher les parties conditionnelles !), comme tout retour de balise...
le retour de certaines fonctions est un vrai booléen : attention !

Et pour mémoire, les statuts standard sont bien '0minirezo'  ,   '1comite'     , '6forum' sans oublier '5poubelle' ; si vous voulez ajouter d’autres statuts, vous pourriez bien avoir à reprendre TOUTES les fonctions d’autorisation....

Vous avez vu ci-dessus comment nommer les fonctions d’autorisation selon leur champ d’application ; reste à remplir le contenu en programmation PHP, ce que nous verrons ci-dessous !

 Le code des fonctions d’autorisations

Pour rechercher des exemples, en attendant d’utiliser cet article, le plus simple était peut-être de ’faire son marché’ dans ecrire/inc/autoriser.php : on l’a fait pour vous !
Nota Bene : attention, les pseudo-noms de fonction utilisés ci-après n’existent pas réellement sous SPIP !

 autoriser-webmestre($qui) : #AUTORISER{webmestre}
facile : il suffit d’écrire   return autoriser('webmestre');
D’ailleurs, cette fonction existe déjà dans le Code de SPIP !

 autoriser-admin() : #AUTORISER{configurer}
tout aussi facile : c’est le retour standard de autoriser('configurer') soit :
 $qui['statut'] == '0minirezo'  and  !$qui['restreint'];

 autoriser-restreint() : sur une rubrique ciblée, qu’il faudrait preciser
toujours aussi facile : vous trouverez la fonction acces_restreint_rubrique($id_rubrique)
(mais celle-ci traite uniquement l’auteur connecté, de façon booléenne !)
Sinon il faudrait définir une fonction function autoriser_restreint($id_rubrique) avec
 ($qui['statut'] == '0minirezo')  and  in_array($id_rubrique,$qui['restreint']);.

 autoriser-redige() : droits du rédacteur
_ en s’inspirant de autoriser_article_creer, vous pourrez utiliser
  return in_array($qui['statut'], array('0minirezo', '1comite')));
(mais attention au cas où vous voudriez utiliser d’autres statuts personnalisés)....

 autoriser-prive() : l’accès général à l’espace privé #AUTORISER{ecrire} est :
isset($qui['statut']) and in_array($qui['statut'], array('0minirezo', '1comite')).

 autoriser-visiteur() (donc même dans l’espace public) : pas de fonction [1], la balise #SESSION ou une variable php à tester par isset($GLOBALS['visiteur_session']['id_auteur']).

Attention à quelques mini-pièges des autorisations standard dans SPIP ; j’ai noté :
 un Admin Restreint reste ’restreint’ même en étant rétrogradé en Rédacteur,
 un Administrateur rétrogradé de Webmestre pourrait encore voir le menu Développement (?),
 ....
Donc souvent, les autorisations de consultation des menus (ex. autoriser_auteurs_menu proviennent d’autorisations d’actions (ex. autoriser('voir', '_auteurs', $id, $qui, $opt);)...