Nouveau paradigme pour le statut des objets

C'est un sujet qui me trotte depuis longtemps dans la tête et je profite d'une accalmie pour en faire part. Le constat de base est que pour moi, le statut d'un objet devrait représenter exclusivement son "cycle de vie", cad des états stables successifs dans la vie de l'objet et, être implémenté comme un workflow configurable.

Étant donné que les objets sont versatiles, cela peut nous mener à beaucoup de complexité in fine, mais si on se restreint un peu je pense qu'on peut arriver à un compromis acceptable sans mettre en œuvre une artillerie lourde.

La mise en œuvre actuelle du statut pose 3 problèmes principaux, à mon avis, que je vais détailler ci-après.

Premièrement, si on considère que le statut représente un état dans le cycle de vie de l'objet, cette logique est parfois dévoyée comme pour l'objet "auteur". Le statut est un mixte entre son cycle de vie (brièvement quand on s'enregistre) et un type qui fournit des autorisations d'accès. Il serait bon dans ce cas de distinguer les deux, le statut d'un coté et un niveau d'autorisation de l'autre.

Deuxième sujet, le périmètre du cycle de vie. De mon point de vue, la poubelle ou l'archive ne constitue pas un statut du cycle de vie mais une zone de "stockage" alternative de l'objet pour lequel le statut n'a pas changé et dans lequel il peut être restauré. Je ferais l'analogie avec un fichier word, possédant un attribut statut à draft ou approuvé que l'on déplace dans la poubelle de l'explorateur ou que l'on déplace dans un dossier pour archivage. C'est ainsi d'ailleurs que j'ai conçu le plugin "Archivage des objets" qui crée pour les objets un concept d'archivage hors statut (composé de plusieurs champs en BDD comme la date et le motif). De la même façon, on pourrait créer un champ "poubelle" et gérer ce champ dans les boucles.

Le troisième sujet concerne le workflow à proprement parlé. Aujourd'hui, celui de spip est un plat de nouilles (j'aime bien les pâtes) où tout est possible de n'importe quel état : c'est simple à représenter visuellement par une liste mais c'est ergonomiquement et pédagogiquement mauvais. Il serait plus lisible pour les utilisateurs et les utilisatrices d'avoir un bouton "proposer à la publication" ou "publier" que d'avoir à choisir entre plusieurs statuts. Outre le fait de proposer des boutons plutôt qu'une liste, la vision workflow pourrait être configurable au niveau des objets en développant l'actuelle. Ce qui pourrait être intéressant c'est :

• de connaitre les statuts initiaux et finaux voir de les standardiser un peu (prepa est toujours le premier statut non final, publie le statut ok final par défaut, refuse le statut final nok par défaut) et ainsi enclencher des mécanismes par défaut;
• définir des groupes pour la visualisation : visibles dans le privé, visibles par défaut dans le public, etc.
• définir les successeurs d'un statut pour identifier les transitions possibles
• et surement d'autres choses.

Cela permettrait à la fois de plus facilement définir de nouveaux workflows pour de nouveaux objets mais aussi de personnaliser le workflow d'un objet existant : par exemple, il n'est pas toujours utile de passer par un statut prop avant de publier de façon générale ou individuelle par article.

Le diagramme suivant est une représentation parmi d'autres de ce que cela pourrait donner sur l'objet article (je n'ai pas représenté le statut refuse).

J'ai conscience que c'est une orientation lourde de conséquences mais j'aime à croire qu'on a encore envie dans spip de se creuser les méninges sur les concepts ;)