Cet article est initialement dédié à une question posée sur IRC (exposée ci-dessous), mais pourrait s’étendre à d’autres aspects, en compléments de Les autorisations basiques.
Voir aussi les plugins Diogène, Autorité et Autorisation dans SPIP.
Le problème d’origine
Lorsqu’on autorise l’accès du back-office à des auteurs déclarés comme simples rédacteurs, ceux-ci peuvent alors accéder à toutes les informations des autres auteurs du site (en particulier déjà à leur e-mail, ce qui constitue une première indiscrétion).
De plus, si le site utilise aussi le plugin Coordonnées, l’interface privée donne possibilité de consulter toutes les données personnelles enregistrées : adresse, téléphone, etc ......
Principe de solution
A ce jour d’avant 11 Novembre 2018, la solution mise en commun est construite sur le principe montré ci-dessous (tout en restant incomplète et imparfaite [1]), voir ci-dessous.
On rajoutera un code source définissant des autorisations, inspiré du code ci-dessous proposé par MisterGraphX dans l’inclure du fichier mes_fonctions pour masquer certains éléments de menu back-office.
Dans un premier temps, seul le code originel -qui ne répond pas au même besoin : à adapter- reste publié ici pour mémoire, en espérant que les commentaires du source vous suffiront !
- // A placer dans mes_options
- // Masquer des entrée du menu de l'espace privé à des Admins NON webmestre
- // https://contrib.spip.net/Autorisations-Dans-Spip#nh2
- // API autoriser : https://www.spip.net/fr_article5528.html
- // Autorisation des items de premier niveau du bandeau
- // https://code.spip.net/autodoc/tree/ecrire/inc/autoriser.php.html#function_autoriser_menugrandeentree_dist
- function autoriser_menugrandeentree($faire, $type, $id, $qui, $opt) {
- // var_dump('faire: ' .$faire . ' - type: ' .$type.' - QUI ? '.print_r($qui,1));
- if($type == 'menupublication'
- || $type == 'menuactivite'
- || $type == 'menuconfiguration'
- ){
- return $qui['statut'] == '0minirezo' AND $qui['webmestre'] == 'oui';
- }
- }
- return $qui['statut'] == '0minirezo';
- }
- function autoriser_auteurs_menu($faire, $type, $id, $qui, $opt) {
- return $qui['statut'] == '0minirezo' AND $qui['webmestre'] == 'oui';
- }
- function autoriser_compositions_menu($faire, $type, $id, $qui, $opt) {
- return $qui['statut'] == '0minirezo' AND $qui['webmestre'] == 'oui';
- }
- function autoriser_mediabox_menu($faire, $type, $id, $qui, $opt) {
- return $qui['statut'] == '0minirezo' AND $qui['webmestre'] == 'oui';
- }
L’exemple ci-dessus est enregistré pour mémoire, car il est issu d’un dialogue sur le canal IRC et sur la liste....
En résultats recherchés, on masque certains choix de menus dans l’interface privée [2]...
Solution intermédiaire
Par exemple, dans l’implantation voulue [3] le rédacteur ne peut plus accéder aux autres fiches auteur par ./ecrire/?exec=auteur&id_auteur=xx
Ainsi, voici la surcharge de fonction d’autorisation à opérer pour masquer les fiches des autres rédacteurs :
- // Pour voir une fiche auteur : être admin complet (non restreint), ou bien il s'agit de sa propre fiche
- function autoriser_auteur_voir($faire, $type, $id, $qui, $opt) {
- if (
- (($qui['statut'] == '0minirezo') && !$qui['restreint'])
- or ($qui['id_auteur'] == $id)
- ) {
- return true;
- }
- else return false;
- }
Du coup, il est possible de faire une fonction de camouflage de l’email (ci-dessous), que vous pourriez utiliser comme filtre complémentaire dans vos squelettes [4] :
- // masquer un email si on est pas autorisé
- function camoufler_email($email,$id) {
- include_spip('inc/autoriser');
- // on camoufle sauf autorisation
- if (!autoriser('voir','auteur', $id)) {
- $email = spip_substr($email,0,3) . "*****";
- }
- return $email;
- }
Mais ! Tout rédacteur a toujours la vision des adresses mails via la page ./ecrire/?exec=auteurs
Une solution simple (que vous trouveriez en relançant avec le paramètre ./ecrire/?exec=auteurs&var_mode=inclure
) : surcharger la noisette correspondante des squelettes du privé (organisés sous Z) !
Il vous suffira donc de rajouter un test de statut sur la ligne correspondante en
- ../squelettes/prive/objets/liste/auteurs.html[50]
- _ <td class='email'>[(#SESSION{statut}|=={0minirezo}|oui)[<a href='mailto:(#EMAIL)'>[(#EMAIL|couper{30})]</a>]]</td>
Modifications autorisées aux auteurs
Enfin, un exemple complétant les autorisations à leurs auteurs pour la modification des articles (ou autres objets) déjà publiés [5]
- // tous les auteurs associés à un objet article sont autorisé à le modifier (même si l'objet est publié)
- function autoriser_article_modifier($faire, $type, $id, $qui, $opt) {
- return false;
- if ($qui['statut'] == '0minirezo')
- return true;
- $T_auteurs = sql_allfetsel('id_auteur','spip_auteurs_liens', array('id_objet='.$id, 'objet="article"'));
- $T_auteurs = array_column($T_auteurs,'id_auteur');
- }
L’inverse = forcer une relecture obligatoire
Le work-flow de SPIP oblige un rédacteur à demander la publication de son article finalisé par un administrateur, qui peut être lui-même si l’auteur est déjà administrateur ou webmestre, ce qui est fréquent !
Or on peut légitimement vouloir dans Edition-gestion d’Auteurs, pour des questions d’éthique [6] par exemple, qu’une relecture soit obligatoire même pour la rédaction par un administrateur, ce qui revient à interdire à un administrateur auteur d’articles, de basculer ses articles au statut publié.
Pour cela il faut surcharger une fonction d’autorisation... en se souvenant que le changement de statut d’un objet est une autorisation particulière depuis SPIP 2/3, exemple autoriser('instituer', $objet, $id_objet, '', array('statut' => $statut))
; il faut donc surcharger la fonction d’autorisation, plutôt uniquement pour les articles, donc définir autoriser_article_instituer()
dans mes_options.
Une telle autorisation pourrait donc s’écrire comme ci-dessous (sauf qu’il s’agira plutôt de controler l’autorisation de publierdans
! [7]) :
- function autoriser_article_instituer($faire, $type, $id, $qui, $opt='') {
- // si statut (nouveau) = 'publie' il faut 0minirezo ET (pas auteur) OU webmestre)
- $liste_auteurs = sql_select('id_objet','auteurs_liens','objet'="article" && 'id_objet' = "$id");
- // sinon --- à tester --
- return autoriser('instituer',$type,$id,$opt);
- }
En réalité, cela ne suffira pas dans SPIP, car un rédacteur peut aussi gérer les auteurs déclarés pour un article : il lui suffira donc de se retirer de la liste, de publier, puis de se rajouter...
Ce dernier exemple illustre bien la difficulté de verrouiller complètement un système !
Article publié le 8 novembre 2018, et actualisé en février 2020 Provisoire (à compléter...) .
Répondre à cet article