Version 6 — Décembre 2019 — YannX
L’API proposant l’adjonction de Roles aux liens, avec son pendant sur les Documents et en particulier son exemple de premier plugin Roles d’auteurs, invite immédiatement le webmestre utiliser ces suggestions.... Mais il reste à compléter les autorisations correspondantes.. et donc à plonger dans ces fonctions/fonctionnalités.
mais je ne suis pas sûr que l’approche envisagée dans cet article, mêlant Statuts, Rôles et Autorisations, ne soit très pérenne, car cela mélange torchons sales et serviettes propres... ;-)
L’origine de cette réflexion : développer dans un site collaboratif privé, une solution de ’contributeur’ selon le ’rôle’ des auteurs intervenants sur des articles, et permettant de garder trace des modifications proposées/apportées dans quelques rubriques spécifiques (au sein de zones d’accès restreint : cela règle le problème de l’authentification en Wiki pur).
Le statut SPIP des auteurs n’est pas modifié par l’API Rôles, qui ne fait que rajouter un champ complémentaire ; comme il n’est pas question d’aller modifier les sources de SPIP, il faudra compléter ce statut, et donc « récupérer » aussi les valeurs de Zone et de Role de l’auteur connecté
Les autorisations suivent une syntaxe basique détaillée dans SPN-705, correspondant à divers cas, également détaillés dans SPN-438 ; rappelons donc les paramètres de la balise #AUTORISER
et de la la fonction (à commencer par le $faire ce qui nous intéresse) :
function autoriser_dist($faire, $type='', $id=0, $qui = NULL, $opt = NULL)
Pour gérer un article, première cible de notre réflexion, il convient d’aborder plusieurs autorisations spécifiques [1]
- la création d’un article : on gardera sans doute la forme d’origine : réservée aux rédacteurs inscrits, tout en l’étendant à l’espace public (squelettes Rubrique
et Article
),
- sa visualisation avant publication (dans le privé et/ou dans le public) : il serait « pénible » de devoir rajouter tous les comptes d’auteurs autorisés, éventuellement intéressés, comme auteurs de cet article ; certes il est nécessaire qu’ils puissent l’apercevoir, mais ils ne prendront un rôle sur cet article qu’en y participant effectivement (par co-redaction, commentaire ou ajout de documents liés, et optionnellement commentés..),
- le commentaire ajouté à l’article (en public ou en privé) : on voudra sans doute garder ces commentaires d’avant publication dans ceux de l’espace privé ...
- la modification de son contenu (mais tous ne sont pas forcement autorisés à modifier, ou du moins a voir leur modification directement intégrée), et on voudra en garder le versionning...
- l’ajout de documents sans modifications,
- l’ajout de commentaires ciblés sur l’article (meme chose : en public ou en privé ?) ; de plus, on pourrait apprécier de pouvoir « localiser » le commentaire en regard du paragraphe ciblé
- l’opportunité de ’figer’ un article pour limiter aux commentaires publics..
- la possibilité de garder un article privé pour un petit groupe d’organisateurs
(pour préparer collaborativement un jeu-mystère... : par une zone restreinte spécifique ?)
- et plus généralement la gestion des statuts de l’article
On voit que certaines de ces opérations viennent apporter des précisions ou contradictions aux autorisations habituelles :
-
En-cours d’analyse...
Des références à (re)-lire :
- http://marcimat.magraine.net/Statuts-sur-les-objets rappelle quelques notions utiles..
Et d’autres études :
- https://contrib.spip.net/Formulaire-d-ajout-modification-d-articles-cote-public
- https://contrib.spip.net/ciautoriser-plugin-Pipeline-pour-autoriser
- https://contrib.spip.net/Le-plugin-Autorite
- https://contrib.spip.net/Plugin-Duplicator