Changer le fonctionnement actuel de spip_auteurs

Bonjour,

Au fur et à mesure des versions SPIP il y a des manques et des incohérences sur la notion d’auteurs dans SPIP qui créent quelques impasses.

Ces propositions visent à un éclaircissement et un élargissement des possibles. En plus d’éviter de devoir gérer des termes non inclusifs (auteur/rédacteur/administrateur etc)

Actuellement une entité auteur regroupe ce qui permet

  • de se connecter (notion de compte)
  • d’être lié à un objet en tant qu’auteur autrice (notion de création)
  • de renseigner des informations personnelles (notion de profil)
  • d’avoir des autorisations de gestion des objets suivants son statut (notion de gestion)

Cela fait beaucoup de choses pour un seul objet !

Ce fil est ouvert dans le but de regrouper les idées et essayer d’être concis dans les attentes qui permettraient plus de lisibilité du code et des fonctionnalités

Proposition principale

  • scinder la table spip_auteurs

A vous lire …

Fil intéressant et vaste sujet !
Je ne rebondis que sur une idée/besoin auxquels je suis confronté régulièrement :

L’association d’auteurs à des rubriques via spip_auteurs_liens implique qu’il s’agit d’auteurs de type « administrateur restreint » et donc soit de devoir se passer de créditer les auteurs/autrices d’une rubrique, soit de leur accorder des droits non souhaités pour pouvoir les créditer :frowning:

Il me semble que roles_auteurs et rôles de manière générale permettent de traiter tout ou partie de ce problème (pour le cas spécifiques de rubriques, je ne sais pas), mais porter tout ce travail sur le typage de liaisons au sein du core est-il prévu en SPIP 5 ?

@Pierre_Jean intéressant ta remontée sur les droits des auteurs SPIP

Concernant ce qui est prévu ou pas sur SPIP5, à priori ce n’est pas prévu, c’est une proposition que je lance qui peut faire plouf ou rebondir :slight_smile:

Je vais essayer de donner mon avis en espérant avoir compris la question (je ne participe pas au dev de Spip, je suis un utilisateur disons avancé, je gère plusieurs 10aines de Spip, encore plus de Wordpress, des Drupal, des Prestashop, des Thelia et quelques Joomla avec aussi un peu de Laravel).

Ce qui m’a fait réagir c’est l’objectif principal « scinder la table spip_auteurs » alors que perso je viens de faire l’inverse dans mon propre CRM (j’ai regroupé la table des « contacts » avec la table des « users » car les uns pouvaient facilement avoir besoin de devenir les autres) et que je suis confronté très souvent à la multiplication des tables contenants des « personnes », par ex. dans Wordpress les comptes Wordpress qu’il faut synchroniser avec les comptes WPforo d’un plugin de forum au travers d’une usine à gaz au fonctionnement assez périlleux.

Donc perso mon avis est qu’au contraire il vaut mieux regrouper tout ce qui concerne des « personnes » dans une seule table et ensuite attribuer à ces personnes des rôles, des droits, des profils, des fonctions, des liens, l’idée générale étant de rassembler en une table tout ce qui est soumis au RGPD, à la sécurité, etc… Ça nécessite évidemment une ergonomie claire et efficace pour éviter de donner des droits d’accès admin à un simple visiteur, il y a un risque certain et je pense que c’est vraiment l’ergonomie qui peut le mitiger. Et il faudrait par contre envisager de changer spip_auteurs par quelque chose de plus générique genre spip_comptes ou spip_contacts (et d’ailleurs je pense que le plugin organisations&contacts gagnerait à ce que la table des contacts soit fusionnée avec les auteurs …)

Voilà c’était mon avis pour ce qu’il vaut, encore merci pour le travail de tous·tes sur Spip que j’essaye de promouvoir à chaque projet.

À quelles manques et incohérences fais tu référence ?

Je listais plus haut ceci
un objet auteur permet actuellement

  • de se connecter (notion de compte)
    
  • d’être lié à un objet en tant qu’auteur autrice (notion de création)
    
  • de renseigner des informations personnelles (notion de profil)
    
  • d’avoir des autorisations de gestion des objets suivants son statut (notion de gestion)
    

et peut-être j’en oublie …

On a donc un objet auteur qui représente plusieurs entités :
compte d'accès / créateur d'une œuvre / profil personnel / gestion d'autorisations

Ainsi avec ces 2 notions compte d'accès et créateur d'une œuvre regroupées dans la table spip_auteurs, l’utilisateurice lambda va très souvent confondre des auteurs liés à des objets dans le sens auteurice d’une œuvre, alors qu’il n’y a nul besoin d’email ni de login dans ce cas là.

Iel doit alors ignorer ces champs login/pass et parfois en ajouter d’autres pour le profil personnel, on se retrouve avec des auteurs d’œuvres (Annie Ernaux) dont le nom comprend aussi le prénom mélangé avec des auteurs administrateurs du site qui ont login et pass configuré.
Donc il y a déjà deux usages distincts sur une même table.

Mais aussi, la masculinisation des gestion d'autorisations est problématique. auteur/rédacteur/administrateur/développeur etc. On devrait pouvoir trouver mieux autrement. (Phase questionnement). Et devrait pouvoir être étendu plus facilement en notion de user/group/auth quitte à adopter l’anglais, why not.

Quand je disais faire disparaitre auteur, j’entends scinder ces notions par quelques chose comme spip_users et spip_profils.

Encore une fois, j’ouvre une brêche pour tenter juste de réfléchir comment faire, qu’est qu’on imagine plus tard, qu’est-ce qui manque, gêne etc.

spip_users serait uniquement dédié aux accès avec login/pass pour greffer facilement les autorisations d’édition des objets via l’idée user/group/auth et non plus rédacteur/auteur/administrateur restreint. Il existe des autorisations sur les objets comme voir/ecrire/modifier dont on aurait une liste à cocher pour un compte. Ou bien un rôle assigné pour les précocher ?

Et dans ce cas, on n’aurait pas à se préoccuper de PGP la date de naissance ou de l’adresse postale, qui iraient dans spip_profils.

Dans spip_profils on peut alors avoir « Annie Ernaux » rattachée en tant qu’autrice ou rédactrice à un article.

wala wala, quelques idées