Adapter SPIP pour un Intranet

 Le contexte

Dans l’antenne d’une association régionale, en ces temps de Covid-bronchiolite-etc, la responsable locale souhaite mettre en place un espace de travail collaboratif, partagé entre ses animateurs, ses bénévoles, son adjointe et même un groupe-projet d’étudiants qui pourraient ainsi journaliser leurs réflexions, bien sûr en respectant des confidentialités particulières, et enfin informer en toute transparence sa hiérarchie distante.

 Formalisation des besoins fonctionnels

Confidentialité extérieur**

Première précaution, le contenu de cet Intranet doit rester confidentiel, d’accès réservé aux seules personnes nominativement autorisées par la/les personnes responsables responsables (administrateur).

Détails personnels des auteurs

La gouvernance souhaiterait faciliter le lien direct entre animateurs, en publiant en interne les villes de résidence et numéros de téléphone personnels entre animateurs [1], mais aussi gérer les possesseurs de clé du local, et leur signature de la Charte Informatique indispensable.

Organisation d’une structure en ’secteurs’

SPIP organise les articles par rubriques, gérées par secteur ou rubrique de premier niveau ; il faut penser/comprendre que la gestion organisationnelle de tous les objets éditoriaux est fondée, en SPIP et avec les plugins, sur un découpage en Rubriques (et en Zones d’accès) : voir la gestion de Accès Restreint. : chaque partie en accès différencié (selon habilitations) est gérée dans un secteur propre.

Gestion de groupes d’intervenants

Les autorisations d’accès seront données à des membres individuellement habilités, identifiés et inscrits comme auteur SPIP, dont le statut d’auteur définira en grande partie les droits d’accès en consultation, et puis de rédaction pour modifier les articles dans certaines rubriques :

• droit de modifications : cela dépend essentiellement des Statuts d’auteur, et sont réparties entre administrateur [2], auteurs rédacteurs [3], et visiteur [4] ; enfin la publication finalisant des articles dans une rubrique spécifique est permise pour des Administrateurs restreints
• habilitations distinctes : tous les membres de cette structure locale n’ont pas forcément à ’tout’ voir et connaitre, en particulier certaines informations des projets stratégiques de l’antenne, ou les éléments de suivi financier des conventions de l’antenne...
  Par exemple, les stagiaires-étudiants d’un groupe-projet n’auront accès que à leur espace de travail pour rédiger les rapports d’avancement....
• modifications collaboratives : autoriser la coopération selon les groupes d’auteurs-rédacteurs évoqués ci-dessus, va nécessiter que :
  • les autres rédacteurs du groupe puissent intervenir pour modifier-amender un article après sa rédaction [5] et par les administrateurs qu’un article "en rédaction’, donc lorsqu’il est passé par son auteur initial au statut d’article "Proposé".
  • tous les membres d’un groupe doivent pouvoir modifier les articles de leur collègue, après rédaction initiale, mais avant ’fermeture’ lors de la validation par le ou les Administrateur ; nous verrons que ces dernières exigences sont... moins faciles à automatiser !

Ergonomie publique adaptée

Les squelettes de la dist permettent déjà une consultation facile du contenu publié sur le site, et comme SPIP intègre son moteur de recherche textuel dans toutes ces pages, il n’y a pas besoin de créer de nouveaux squelettes dans un premier temps, la mise en œuvre de ces fonctionnalités dans l’espace public reste jusqu’à présent limitée à des modifications marginales des squelettes originaux (voir aussi Présentation de la dist (SPIP3.1)).

Personnalisation thème et CSS

Bien sûr, vous pourrez d’abord appliquer un thème et/ou modifier les CSS pour mettre le site aux couleurs de la structure.
Toutefois, on ci-après propose une amélioration cosmétique un peu plus complexe à programmer /avec un pipeline/ pour la mise en exergue des zones de saisie : le fonds blanc uniforme des formulaires de saisie rend parfois difficile d’identifier immédiatement les champs à remplir dans l’espace privé ; un simple CSS peut aider vos utilisateurs.
Les administrateurs et webmestres SPIP prennent facilement l’habitude de travailler presque uniquement dans l’espace privé, qui offre effectivement toutes les facilités d’accès et de modification aux contenus en-cours d’élaboration-rédaction ; mais cette interface est inadaptée aux visiteurs occasionnels, et comme l’une des principales facilites de SPIP est justement la personnalisation progressive de l’interface publique par la modification des squelettes...

Pour développer la participation des rédacteurs inscrits, mais visiteurs professionnels, on a jugé préférable de montrer les titres de ces articles en-cours dans l’interface publique : à charge aux intéressés de se connecter pour réagir...ce sera l’occasion de montrer comment Utiliser des modèles de SPIP [6] pour généraliser cet affichage public facilement.

Et certains adaptations plus ergonomiques ne seront pas encore automatisées : ainsi pour qu’un article soit modifiable par les autres auteurs du groupe, nous verrons qu’il faudrait que ceux-ci soient préalablement rajoutes comme auteurs de l’article : mais cela n’est pas disponible en standard [7].

Enfin pour faciliter l’identification entre membres qui ne se connaissent pas encore, une personnalisation des auteurs est aussi proposée, apportée par un ensemble de ’badges’, s’appuyant sur un système de mots-clés, indiquant leur statut dans l’association qui ne sera sans doute pas décrit dans cet article... déjà bien assez long !

Quelques limitations

Il n’a pas été souhaité de :
 mettre en place un système directement Wiki [8] en rédaction libre directement dans l’espace public, laissant plutôt travailler en FramaPad,
 gérer dans l’immédiat les participations des membres aux activités(actuellement dépendantes des mails croisés, pas toujours lus), et leurs statistiques de participations d’un simple clic individuel ; à partir du plugin Réservations(dont le nom ne traduit pas le caractère "facultatif"), et sur la base d’une programmation annoncée par un administrateur, il est en effet facile d’installer sous SPIP un écran de saisie individualisée pour partager les venues aux réunions prévues ou ateliers [9], dont les CR seront bien sûr mis en-ligne privée et consultables sur cet Intranet [10].
 à noter aussi qu’il serait théoriquement possible, d’après les plugins disponibles pour SPIP, d’intégrer un stockage NextCloud à la gestion de l’Intranet réservé aux membres (formule à approfondir...).

 Comment faire

La majeure partie du travail consiste à intégrer quelques plugins SPIP parmi les plus courants, en particulier : Iintranet/Extranet, les deux plugins de Champs Extras, le plugin Accès Restreint, Autorité,... sans oublier de les configurer !

Confidentialité : le plugin Intranet

L’installation et configuration immédiate de ce plugin constitue un garde-fou de sécurité pour la totalité de votre Intranet....
Dans un second temps, l’usage du plugin Accès Restreint s’imposera sans doute (voir ci-après).

Compléter les Auteurs : Champs Extras

Après installation des deux plugins, il faudra ajouter quelques champs définis : la Ville, le téléphone, un champ à cocher pour la clé (voir deux types de clés : boite et/ou local ?) [11], et un champ date de signature de la Charte Informatique [12]

Structuration en secteurs

Un travail de réflexion impliquant des responsables de l’association doit aboutir à une arborescence en secteurs, puis rubriques et sous-rubriques, définies en fonction d’une clarté de navigation d’accès pour que les visiteurs puissent trouver facilement l’information voulue.... sans oublier des zones confidentielles pour des besoins particuliers, et un secteur protégé pour mémoriser la journalisation technique et les améliorations du site (partagé entre Webmestre et autres Administrateurs pour la traçabilité technique).
Cette structuration dépend de chaque activité et du fonctionnement de l’organisation, en sachant que SPIP permet très facilement de déplacer des articles ou des rubriques complètes dans l’arborescence crée : celle-ci peut devoir s’adapter aux contraintes d’accès par groupes, à analyser ci-dessous.

Gestion des Groupes et Zones : Accès Restreint

Installation du plugin accès restreint et configuration : interdire la lecture des documents joints (pour une protection d’accès analogue à celle de leurs objets de base, les articles de rattachement).

L’identification des zones

Définir une zone par groupe :
 Administrateurs permanents (auxquels on ajoutera peut-être les Visiteurs institutionnels hiérarchiques)..
 le projet Stagiaires : ajouter les Permanents (et la hiérarchie ?),
aux étudiants définis comme rédacteurs et administrateurs restreint de cette rubrique.
 des zones selon vote arborescence de secteurs...
 rajouter une zone "Communs" [13] comprenant tous les auteurs (sauf les visiteurs = extérieurs) pour gérer en interne les réunions, partager informations communes, etc...

Attention aux superpositions

Le fonctionnement des habilitations du plugin Accès Restreint est traditionnellement "restrictif par cumul" (c’est-à-dire qu’il opère un "ET Logique" entre toutes les zones concernées pour donner ou non autorisation de lecture à l’auteur connecté !).
En d’autres termes, pour qu’un article d’une rubrique "couverte par plusieurs zones" soit accessible à un auteur, il faut que cet auteur soit déclaré dans toutes les zones couvrantes Alors restez simple : une zone par rubrique !
Et vérifier régulièrement que votre couverture de confidentialité est totale, en utilisant un navigateur différent en mode non-connecté à votre SPIP [14].

Autoriser les modifications : plugin Autorité

Pour permettre aux rédacteurs de modifier/compléter les articles de leur groupe, installer donc le plugin Autorité, et configurer juste le choix Rédacteur modifie proposé ; nul doute qu’en fonction de vos besoins, vous y trouverez d’autres paramétrages à adapter...

Une noisette d’appel des Articles en modèle

On souhaite garder la convivialité et l’ergonomie de l’interface public, mais il faut aussi donner accès aux articles "proposés" en plus des articles "publiés" dans la navigation courante SPIP affichant des articles, c’est-à-dire :
 la page de squelette sommaire, avec les articles récents,
 la page de squelette plan
 la page de squelette résultats de recherche,
 et ultérieurement les pages de squelette par mots-clés.

Pour cela, il faut d’abord identifier la noisette concernée, par exemple dans la page sommaire, le bloc d’origine est appelé dans le fichier de squelette sommaire.html par l’instruction <code><INCLURE{fond=inclure/recents,env,ajax} /> qui contient

Pour afficher tant les articles "publiés" que les "proposés", il suffit de modifier la boucle BOUCLE_articles pour rajouter un critère <BOUCLE_articles(ARTICLES) .... {statut IN #LISTE{publie,prop} }> [15]

Et, puisqu’on sélection des articles publiés ou proposés, cela serait sympa d’afficher l’icône de statut d’article : justement, il suffit d’une ligne SPIP pour ce faire :
[(#STATUT|puce_statut{article,#ID_ARTICLE,#ID_RUBRIQUE}) ] : facile !

Enfin, le lien d’appel-consultation des articles #URL_ARTICLE utilisé ci-dessus n’est applicable qu’à un article "publié" ; si nous voulons aussi fournir un lien valide pour les rédacteurs (et administrateurs) habilités à modifier l’article —parce qu’ils en sont "auteur"— il faut dans ce cas faire appel à une URL vers l’espace privé [16] ! Dans ce cas, au lieu d’appeler #URL_ARTICLE, il faut appeler [#URL_ECRIRE{article_edit,id_article=#ID_ARTICLE}].

Pour intégrer plus complètement cet appel dans le squelette, nous allons utiliser [#URL_ECRIRE{article_edit,id_article=#ID_ARTICLE}(#AUTORISER{edter,article,#ID_ARTICLE})]})], la clause complémentaire e balise#AUTORISER contrôlant le droit de l’auteur connecté dans cette session à éditer cet article [17].

Bon, il resterait encore une amélioration à apporter (mais elle ne semble pas possible si simplement à ma connaissance,), ce serait qu’a l’enregistrement de la page modifiée, le retour se fasse à la page d’origine du public (avec un paramètre du genre #URL_PAGE=#SELF .... à voir si !), sans oublier le cas d’un blocage de SPIP (erreur de connexion ou "erreur technique" : cela arrive ;-) !

Bien, on met au point cette noisette dans le ./inclure/recents.html qui a été recopié dans le dossier ./squelettes/ par usage du plugin rubrique 884,...... (à vos tests), et il n’y a plus qu’a en généraliser l’usage !...

Pour cela, on transforme la noisette en un "modèle SPIP " que l’on va appeler article_appel : c’est tres compliqué = copiez le code correspondant dans un fichier ./modeles/article_appel.html :

Il reste juste à faire un ’Recherche et Remplace’ dans les squelettes....en remplaçant le bloc d’appel par
[(#MODELE{article_appel, id_article=#ID_ARTICLE}|)], dans les fichiers identifiés...

Quelques CSS complémentaires

Pour faciliter l’identification des champs de saisie sur fond blanc, l’idée est de faire mieux ressortir ces zones, en leur attribuant un fonds de couleur ; ici on choisit un fond jaune... [18] ; l’instruction CSS à utiliser est justement :

(à rajouter aussi dans ./squelettes/css/perso.css)
Personnellement je préfère .formulaire_spip input {background-color:#FFFF99;} plus pâle..

Les rédacteurs apprécieront peut-être de retrouver cette personnalisation CSS dans l’espace privé : mais pour ajouter automatiquement la référence à une feuille de style perso_prive.css pour l’espace privé de SPIP, il semble qu’il me faille encore rajouter une "bidouille" dans le mes_options.php : ajouter =

L’autre solution serait de rajouter la ligne SPIP correspondante (soit :

dans une copie du fichier ./prive/squelettes/inclure/head.html à copier modifiée dans ./squelettes/prive/squelettes/inclure/head.html (ou ./prive/squelettes/head/dist.html) appelant les styles Z du privé... ->
Voir aussi : https://programmer.spip.net/ Personnaliser les CSS de l’espace prive

Voilà ! On arrête les modifications à ce point....dense !

Je Remercie Loiseau2nuit qui a pris le temps d’une relecture complète de cet article, et suggéré et réalisé plusieurs correction de la rédaction initial !