Nouveau paradigme pour le statut des objets #5731

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 ;)

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). ![statut4.png](/attachments/a1d03f19-d4e0-4f3e-ae6a-0c685e81c937) 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 ;)

statut4.png

32 KiB

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.

sur ce point je te rejoint

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é.

cela se discute. Pour la plupart du temps oui. Pour certaisn cas non l'archivage correspond bien à un etat dans le cycle de vie (ex : une isncripton à un evenement est en cours de traitement, elle passe ensuite à une inscription validée, et lorsque l'evenement est passé c'est archivée -> on n'est bien dans un etat de flux).

> 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. sur ce point je te rejoint > 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é. cela se discute. Pour la plupart du temps oui. Pour certaisn cas non l'archivage correspond bien à un etat dans le cycle de vie (ex : une isncripton à un evenement est en cours de traitement, elle passe ensuite à une inscription validée, et lorsque l'evenement est passé c'est archivée -> on n'est bien dans un etat de flux).

cela se discute. Pour la plupart du temps oui. Pour certaisn cas non l'archivage correspond bien à un etat dans le cycle de vie (ex : une isncripton à un evenement est en cours de traitement, elle passe ensuite à une inscription validée, et lorsque l'evenement est passé c'est archivée -> on n'est bien dans un etat de flux).

Non, je ne suis pas en ligne avec ta conclusion.
A partir du moment où tu ne restaures pas l'évènement que tu dis être dans l'état archivé ce n'est pas un archivage au sens où je l'entends.
On est juste en présence d'un état final de ton workflow : validée est juste un état intermédiaire dans ce cas et archivé pourrait s'appeler n'importe comment mais n'est pas un archivage au sens où je l'ai défini.

> cela se discute. Pour la plupart du temps oui. Pour certaisn cas non l'archivage correspond bien à un etat dans le cycle de vie (ex : une isncripton à un evenement est en cours de traitement, elle passe ensuite à une inscription validée, et lorsque l'evenement est passé c'est archivée -> on n'est bien dans un etat de flux). Non, je ne suis pas en ligne avec ta conclusion. A partir du moment où tu ne restaures pas l'évènement que tu dis être dans l'état archivé ce n'est pas un archivage au sens où je l'entends. On est juste en présence d'un état final de ton workflow : validée est juste un état intermédiaire dans ce cas et archivé pourrait s'appeler n'importe comment mais n'est pas un archivage au sens où je l'ai défini.

A partir du moment où tu ne restaures pas l'évènement que tu dis être dans l'état archivé ce n'est pas un archivage au sens où je l'entends.

bah oui mais forcément si tu pose toi les conditions de définition des termes, on va pas être d'accord :) Tu dis que de ton point de vue l'archivage ne constitue pas un statut du cycle de vie, je te dis que ca depend des cas, tu me redis que non non. Bah on va tourner en rond. Mais si tu prend des pratiques "papier" tu vois que bien souvent on appel archivage l'étapt final d'un workflow (ex avec les pièces comptables : à traiter -> traitée -> archivée à la fin de l'exercice comptable -> detruite). Il n'est jamais question de penser que l'archivage puisse restaurer un etat précédent.

> A partir du moment où tu ne restaures pas l'évènement que tu dis être dans l'état archivé ce n'est pas un archivage au sens où je l'entends. bah oui mais forcément si tu pose toi les conditions de définition des termes, on va pas être d'accord :) Tu dis que de ton point de vue l'archivage ne constitue pas un statut du cycle de vie, je te dis que ca depend des cas, tu me redis que non non. Bah on va tourner en rond. Mais si tu prend des pratiques "papier" tu vois que bien souvent on appel archivage l'étapt final d'un workflow (ex avec les pièces comptables : à traiter -> traitée -> archivée à la fin de l'exercice comptable -> detruite). Il n'est jamais question de penser que l'archivage puisse restaurer un etat précédent.

Cela étant, en dehors du cas de l'archivage (dans ou hors workflow) je suis d'accord avec ton idée qu'on devrait plutot penser en terme de "workflow" avec des chemins de statut, et pas du saut de l'un à l'autre.

bah oui mais forcément si tu pose toi les conditions de définition des termes, on va pas être d'accord :) Tu dis que de ton point de vue l'archivage ne constitue pas un statut du cycle de vie, je te dis que ca depend des cas, tu me redis que non non. Bah on va tourner en rond.

Non je pose la définition de l'archivage telle que je la propose.
C'est un prérequis à partir duquel j'infère le reste bien entendu sinon tout est dans tout et réciproquement ;)

Tu peux appeler un état "archivé" mais ça ne correspond pas à une archive au sens de la définition initiale que je propose.
Et je maintiens que comme pour poubelle ce qui diffère d'un état du workflow d'une position dans une zone c'est le fait que ce soit réversible.
On peut sortir un document d'une boite d'archive, donc oui l'archivage n'est pas un état mais une zone où on met et retire des objets.

> bah oui mais forcément si tu pose toi les conditions de définition des termes, on va pas être d'accord :) Tu dis que de ton point de vue l'archivage ne constitue pas un statut du cycle de vie, je te dis que ca depend des cas, tu me redis que non non. Bah on va tourner en rond. Non je pose la définition de l'archivage telle que je la propose. C'est un prérequis à partir duquel j'infère le reste bien entendu sinon tout est dans tout et réciproquement ;) Tu peux appeler un état "archivé" mais ça ne correspond pas à une archive au sens de la définition initiale que je propose. Et je maintiens que comme pour poubelle ce qui diffère d'un état du workflow d'une position dans une zone c'est le fait que ce soit réversible. On peut sortir un document d'une boite d'archive, donc oui l'archivage n'est pas un état mais une zone où on met et retire des objets.

Mon avis en première lecture : il me semble que dans une immense partie des cas, on a des sites avec peu de gens, avec une équipe qui se connait et se parle, voire très très souvent avec même juste une unique personne. Et ça sans qu'on sache d'avance la ou les utilisations de comment vont s'organiser les gens.

Ce pourquoi il me semble que dans 80% des cas, une simple liste où les gens s'auto-organisent comme ils veulent suffit largement. UX unique super simple + très peu de code à maintenir = un noyau facile pour ce qui est le plus courant.

Ce qui n'empêche pas d'imaginer un plugin bien nommé "workflows", qui surchargerait totalement le form de statut et permettrait plein de déclarations explicites de chemins, de labels de boutons etc. Ça correspond à un vrai besoin, mais qui me semble plus rare, pour des grosses équipes et/ou pour des objets précis où on veut pas que les gens se trompent. Et pour ne pas avoir à faire plusieurs plugins proches j'irai même plus loin : le plugin devrait sûrement aussi pouvoir définir plusieurs workflows différents dans un même type d'objet SPIP, cloisonnés selon telle ou telle condition (exemple : un workflow par défaut pour les articles MAIS un workflow différent dans telle branche du site ; ou encore un workflow par défaut pour les réponses de Formidable MAIS pouvoir définir des workflows différents dans chaque formulaire, etc).

Exemple de workflows (ici de collectivités) :
https://catalogue.publik.love/workflows/
https://doc.entrouvert.org/wcs/dev/index.html#wf

Mon avis en première lecture : il me semble que dans une immense partie des cas, on a des sites avec peu de gens, avec une équipe qui se connait et se parle, voire très très souvent avec même juste une unique personne. Et ça sans qu'on sache d'avance la ou les utilisations de comment vont s'organiser les gens. Ce pourquoi il me semble que dans 80% des cas, une simple liste où *les gens s'auto-organisent comme ils veulent* suffit largement. UX unique super simple + très peu de code à maintenir = un noyau facile pour ce qui est le plus courant. Ce qui n'empêche pas d'imaginer un plugin bien nommé "workflows", qui surchargerait totalement le form de statut et permettrait plein de déclarations explicites de chemins, de labels de boutons etc. Ça correspond à un vrai besoin, mais qui me semble plus rare, pour des grosses équipes et/ou pour des objets précis où on veut pas que les gens se trompent. Et pour ne pas avoir à faire plusieurs plugins proches j'irai même plus loin : le plugin devrait sûrement aussi pouvoir définir plusieurs workflows différents dans un même type d'objet SPIP, cloisonnés selon telle ou telle condition (exemple : un workflow par défaut pour les articles MAIS un workflow différent dans telle branche du site ; ou encore un workflow par défaut pour les réponses de Formidable MAIS pouvoir définir des workflows différents dans chaque formulaire, etc). Exemple de workflows (ici de collectivités) : https://catalogue.publik.love/workflows/ https://doc.entrouvert.org/wcs/dev/index.html#wf

Ce pourquoi il me semble que dans 80% des cas, une simple liste où les gens s'auto-organisent comme ils veulent suffit largement. UX unique super simple + très peu de code à maintenir = un noyau facile pour ce qui est le plus courant.

Ben l'aspect simple du code et du noyau ça reste à prouver.
Je pense que ça bave plus partout dans l'implémentation actuelle que si on adoptait une logique comme celle que je propose.
Après simplifier le noyau pour exporter la complexité dans les plugins c'est un concept avec lequel j'ai du mal mais c'est une autre discussion.

Ce qui n'empêche pas d'imaginer un plugin bien nommé "workflows",

Je ne pense pas que ce soit faisable dans la structure actuelle sans tordre les concepts dans tous les sens.
Justement, le but de la proposition c'est de mettre des bases plus solides pour le faire en proposant une logique light de workflow configurable.

> Ce pourquoi il me semble que dans 80% des cas, une simple liste où les gens s'auto-organisent comme ils veulent suffit largement. UX unique super simple + très peu de code à maintenir = un noyau facile pour ce qui est le plus courant. Ben l'aspect simple du code et du noyau ça reste à prouver. Je pense que ça bave plus partout dans l'implémentation actuelle que si on adoptait une logique comme celle que je propose. Après simplifier le noyau pour exporter la complexité dans les plugins c'est un concept avec lequel j'ai du mal mais c'est une autre discussion. > Ce qui n'empêche pas d'imaginer un plugin bien nommé "workflows", Je ne pense pas que ce soit faisable dans la structure actuelle sans tordre les concepts dans tous les sens. Justement, le but de la proposition c'est de mettre des bases plus solides pour le faire en proposant une logique light de workflow configurable.

Ben l'aspect simple du code et du noyau ça reste à prouver.

Je suis d’accord…

Il y a surtout beaucoup d’implicite dans le core.

Déclarer un workflow et utiliser les transitions associées permettrait de clarifier bien des situations dans le code.

Et évidemment donc, il faut regarder du côté de symfony/workflow

> Ben l'aspect simple du code et du noyau ça reste à prouver. Je suis d’accord… Il y a surtout beaucoup d’implicite dans le core. Déclarer un workflow et utiliser les transitions associées permettrait de clarifier bien des situations dans le code. Et évidemment donc, il faut regarder du côté de [symfony/workflow](https://symfony.com/doc/current/components/workflow.html)

Des boutons pour les principales transitions de phase statutaire d'un objet, c'est sympa et ça simplifie l'UI.
Mais les critères pour le "oui c'est un statut" et le "non c'en est pas un" me semblent arbitraires.
Je comprend pas comment décider que "proposé" ou "publié" sont des statuts mais pas "archivé" ou "poubelle".
Car oui les droits d'un auteur et les états d'un article ne sont pas de la même nature, mais ça ne me choque pas.
Car un auteur et un article ne sont pas non plus de la même nature.

Des boutons pour les principales transitions de phase statutaire d'un objet, c'est sympa et ça simplifie l'UI. Mais les critères pour le "oui c'est un statut" et le "non c'en est pas un" me semblent arbitraires. Je comprend pas comment décider que "proposé" ou "publié" sont des statuts mais pas "archivé" ou "poubelle". Car oui les droits d'un auteur et les états d'un article ne sont pas de la même nature, mais ça ne me choque pas. Car un auteur et un article ne sont pas non plus de la même nature.

Et évidemment donc, il faut regarder du côté de symfony/workflow

Oui surement d'un point de vue technique une fois les bases d'une nouvelle approche définie.
Mon objectif est d'abord une réflexion sur les concepts.
En outre, j'ai déjà regardé cette librairie pour des besoins que tu connais, ben c'est du lourd et du brutal ;).

> Et évidemment donc, il faut regarder du côté de [symfony/workflow](https://symfony.com/doc/current/components/workflow.html) Oui surement d'un point de vue technique une fois les bases d'une nouvelle approche définie. Mon objectif est d'abord une réflexion sur les concepts. En outre, j'ai déjà regardé cette librairie pour des besoins que tu connais, ben c'est du lourd et du brutal ;).

Mais les critères pour le "oui c'est un statut" et le "non c'en est pas un" me semblent arbitraires.
Je comprend pas comment décider que "proposé" ou "publié" sont des statuts mais pas "archivé" ou "poubelle".

Je ne pense pas vraiment.
Mais c'est vrai que c'est un choix conceptuel et donc j'ai proposé une analogie avec les fichiers que je trouve assez juste.
En particulier, je ne me rappelle personne me dire tiens j'ai passé ce truc en statut poubelle mais plutôt je l'ai mis dans la poubelle ce qui dénote d'une action de déplacement pas d'un changement de statut.

Donc la proposition c'est d'adopter cette logique de zone poubelle ou zone archive au même titre que l'on a conçu le contraire jusqu'à aujourd'hui.
Je n'ai aucun doute qu'on peut toujours trouver des arguments plus ou moins licites pour ou contre.

Car oui les droits d'un auteur et les états d'un article ne sont pas de la même nature, mais ça ne me choque pas.

C'est pas la question que ça te choque ou pas.
La question est : est-ce de même nature ? La réponse est évidemment non dans ce cas.

Car un auteur et un article ne sont pas non plus de la même nature.

Ce sont des objets qui possèdent un cycle de vie. Et quand on dit cycle de vie c'est qu'on passe d'un état à un autre. Je ne suis pas sur que passer de rédacteur à administrateur soit une promotion ;).

> Mais les critères pour le "oui c'est un statut" et le "non c'en est pas un" me semblent arbitraires. > Je comprend pas comment décider que "proposé" ou "publié" sont des statuts mais pas "archivé" ou "poubelle". Je ne pense pas vraiment. Mais c'est vrai que c'est un choix conceptuel et donc j'ai proposé une analogie avec les fichiers que je trouve assez juste. En particulier, je ne me rappelle personne me dire tiens j'ai passé ce truc en statut poubelle mais plutôt je l'ai mis dans la poubelle ce qui dénote d'une action de déplacement pas d'un changement de statut. Donc la proposition c'est d'adopter cette logique de zone poubelle ou zone archive au même titre que l'on a conçu le contraire jusqu'à aujourd'hui. Je n'ai aucun doute qu'on peut toujours trouver des arguments plus ou moins licites pour ou contre. > Car oui les droits d'un auteur et les états d'un article ne sont pas de la même nature, mais ça ne me choque pas. C'est pas la question que ça te choque ou pas. La question est : est-ce de même nature ? La réponse est évidemment non dans ce cas. > Car un auteur et un article ne sont pas non plus de la même nature. Ce sont des objets qui possèdent un cycle de vie. Et quand on dit cycle de vie c'est qu'on passe d'un état à un autre. Je ne suis pas sur que passer de rédacteur à administrateur soit une promotion ;).

On dit "On met à la poubelle" mais est-ce que le langage courant français est un critère déterminant ?
Le nommage des fonctionnements SPIP et le choix des icônes s'appuient sur des métaphores, qui facilitent la découverte et l'usage à l'intérieur d'une certaine zone de validité.
En dehors de cette zone, filer la métaphore (et le langage courant qui va avec) peut amener de super nouveaux développements auxquels on avait pas pensé avant... mais ça peut aussi se révéler inadapté.
Et comme ça me semble un gros chantier avec peut être une perte de simplicité et peut être des conséquences sur l'existant, ça vaudrait le coup de mieux comprendre formellement à l'avance l'intérêt et les limites de la dissociation envisagée.

On dit "On met à la poubelle" mais est-ce que le langage courant français est un critère déterminant ? Le nommage des fonctionnements SPIP et le choix des icônes s'appuient sur des métaphores, qui facilitent la découverte et l'usage à l'intérieur d'une certaine zone de validité. En dehors de cette zone, `filer la métaphore` (et le langage courant qui va avec) peut amener de super nouveaux développements auxquels on avait pas pensé avant... mais ça peut aussi se révéler inadapté. Et comme ça me semble un gros chantier avec peut être une perte de simplicité et peut être des conséquences sur l'existant, ça vaudrait le coup de mieux comprendre formellement à l'avance l'intérêt et les limites de la dissociation envisagée.

On dit "On met à la poubelle" mais est-ce que le langage courant français est un critère déterminant ?
Le nommage des fonctionnements SPIP et le choix des icônes s'appuient sur des métaphores, qui facilitent la découverte et l'usage à l'intérieur d'une certaine zone de validité.

J'ai du mal à comprendre tes remarques : en quoi mettre quelque chose dans une poubelle c'est du langage français ?
Je suis un peu désarçonné que tu parles de métaphore pour un geste que tu fais tous les jours.

En dehors de cette zone, filer la métaphore (et le langage courant qui va avec) peut amener de super nouveaux développements auxquels on avait pas pensé avant... mais ça peut aussi se révéler inadapté.
Et comme ça me semble un gros chantier avec peut être une perte de simplicité et peut être des conséquences sur l'existant, ça vaudrait le coup de mieux comprendre formellement à l'avance l'intérêt et les limites de la dissociation envisagée.

On est loin de décider quoique ce soit sur l'implémentation, c'est pas mon propos du moment.
J'essaye plus de lancer une réflexion mais j'ai l'impression qu'il faut que je me justifie de la lancer.
Ça me paraitrait plus intéressant de débattre du sujet lui-même non ? Enfin je ne sais plus là...

> On dit "On met à la poubelle" mais est-ce que le langage courant français est un critère déterminant ? > Le nommage des fonctionnements SPIP et le choix des icônes s'appuient sur des métaphores, qui facilitent la découverte et l'usage à l'intérieur d'une certaine zone de validité. J'ai du mal à comprendre tes remarques : en quoi mettre quelque chose dans une poubelle c'est du langage français ? Je suis un peu désarçonné que tu parles de métaphore pour un geste que tu fais tous les jours. > En dehors de cette zone, `filer la métaphore` (et le langage courant qui va avec) peut amener de super nouveaux développements auxquels on avait pas pensé avant... mais ça peut aussi se révéler inadapté. > Et comme ça me semble un gros chantier avec peut être une perte de simplicité et peut être des conséquences sur l'existant, ça vaudrait le coup de mieux comprendre formellement à l'avance l'intérêt et les limites de la dissociation envisagée. On est loin de décider quoique ce soit sur l'implémentation, c'est pas mon propos du moment. J'essaye plus de lancer une réflexion mais j'ai l'impression qu'il faut que je me justifie de la lancer. Ça me paraitrait plus intéressant de débattre du sujet lui-même non ? Enfin je ne sais plus là...

Un article, comme un fichier, est une succession d'octets. Physiquement, c'est une succession de champs magnétiques localisés sur un support de mémoire et accédés via des flux électriques - et je simplifie, car c'est un assemblage extrêmement complexe !
Nommer "poubelle" l'état d'un tel assemblage, c'est une métaphore qui en simplifie l'usage et le rend accessible.
Mais "la carte n'est pas le territoire", et je crois justement être pleinement dans ce ticket en proposant d'abandonner cette métaphore pour explorer le sujet, et donc d'interroger, indépendamment de l'expression "mettre à la poubelle" : qu'est-ce qui, dans le fond, différencierait 2 sortes de statuts, flux ou états ?

Un article, comme un fichier, est une succession d'octets. Physiquement, c'est une succession de champs magnétiques localisés sur un support de mémoire et accédés via des flux électriques - et je simplifie, car c'est un assemblage extrêmement complexe ! Nommer "poubelle" l'état d'un tel assemblage, c'est une métaphore qui en simplifie l'usage et le rend accessible. Mais ["la carte n'est pas le territoire"](https://fr.wiktionary.org/wiki/la_carte_n%E2%80%99est_pas_le_territoire), et je crois justement être pleinement dans ce ticket en proposant d'abandonner cette métaphore pour explorer le sujet, et donc d'interroger, indépendamment de l'expression "mettre à la poubelle" : qu'est-ce qui, dans le fond, différencierait 2 sortes de statuts, flux ou états ?

Il me vient que la dissociation en plusieurs champs permet d'avoir plusieurs valeurs en même temps : par exemple publié mais poubelisé (lorsque passé de mode), ou proposé mais archivé. Et c'est facile alors de restaurer l'état antérieur lorsqu'on sort de la poubelle ou de l'archive.

Mais pourquoi s'arrêter là spécifiquement ? Car on peut aussi imaginer qu'un article soit proposé (une demande de validation est en cours) mais publié (déjà visible, en tant qu'article proposé) ou pas.

Et donc la spécificité de 'poubelle' ou 'archivé' ne m'apparaît pas,
mais au passage, ce post amène l'éventualité que 'statut' soit multivalué.

Il me vient que la dissociation en plusieurs champs permet d'avoir plusieurs valeurs en même temps : par exemple `publié` mais `poubelisé` (lorsque passé de mode), ou `proposé` mais `archivé`. Et c'est facile alors de restaurer l'état antérieur lorsqu'on sort de la poubelle ou de l'archive. Mais pourquoi s'arrêter là spécifiquement ? Car on peut aussi imaginer qu'un article soit `proposé` (une demande de validation est en cours) mais `publié` (déjà visible, en tant qu'article proposé) ou pas. Et donc la spécificité de 'poubelle' ou 'archivé' ne m'apparaît pas, mais au passage, ce post amène l'éventualité que 'statut' soit multivalué.

Il me vient que la dissociation en plusieurs champs permet d'avoir plusieurs valeurs en même temps : par exemple publié mais poubelisé (lorsque passé de mode), ou proposé mais archivé. Et c'est facile alors de restaurer l'état antérieur lorsqu'on sort de la poubelle ou de l'archive.

Abah quand même, ça fait 15 fois qu'on le dit et c'était tout l'objet du débat sur la liste quand ya eu la conception du plugin Archivage d'objets 😂

Mais pourquoi s'arrêter là spécifiquement ? Car on peut aussi imaginer qu'un article soit proposé (une demande de validation est en cours) mais publié (déjà visible, en tant qu'article proposé) ou pas.

Non mais la prise de tête… là t'inventes des concepts et tu tords complètement le sens des mots de ce qui existe : "proposé" s'appelle explicitement "proposé à la publication" donc c'est très explicite que ça peut pas être déjà publié… Tant que t'y es ça peut être brouillé et publié aussi ?… Ça n'a plus aucun sens dans ce cas…

> Il me vient que la dissociation en plusieurs champs permet d'avoir plusieurs valeurs en même temps : par exemple `publié` mais `poubelisé` (lorsque passé de mode), ou `proposé` mais `archivé`. Et c'est facile alors de restaurer l'état antérieur lorsqu'on sort de la poubelle ou de l'archive. Abah quand même, ça fait 15 fois qu'on le dit et c'était tout l'objet du débat sur la liste quand ya eu la conception du plugin Archivage d'objets 😂 > Mais pourquoi s'arrêter là spécifiquement ? Car on peut aussi imaginer qu'un article soit `proposé` (une demande de validation est en cours) mais `publié` (déjà visible, en tant qu'article proposé) ou pas. Non mais la prise de tête… là t'inventes des concepts et tu tords complètement le sens des mots de ce qui existe : "proposé" s'appelle explicitement "proposé *à la publication*" donc c'est très explicite que ça peut pas être déjà publié… Tant que t'y es ça peut être brouillé et publié aussi ?… Ça n'a plus aucun sens dans ce cas…

Certaines combinaisons n'ont certainement pas de sens. Et alors ?

La poubelle dans son acceptation habituelle n'est pas qu'un lieu de stockage puisqu'avec SPIP dist elle a pour conséquence de dépublier. Mais d'ailleurs, "stocker un article", ne serait-ce pas encore une métaphore qui se prend les pieds dans la lettre ?

La notion de "statuts initiaux" et "finaux" est propre à certains flux mais certains workflows sont cycliques et n'ont pas de statuts finaux.

Ya une différence dans l'exigence de généralité selon qu'on veut faire un plugin pour un besoin particulier ou modifier le noyau.

Je partage mes questionnements car je ne comprend pas les critères de dissociation des statuts (ou je les trouve arbitraires, ou trop spécifiques quitte à élargir le périmètre) et peut être car je crains les complications que ça induirait.

Mais je trouve intéressant la possibilité de définir des workflows.
Et aussi la piste des statuts multivalués, comme des états superposés, qui feraient entrer SPIP dans l'ère quantique LOL.
"publié" ET "poubellisé".

Certaines combinaisons n'ont certainement pas de sens. Et alors ? La poubelle dans son acceptation habituelle n'est pas qu'un lieu de stockage puisqu'avec SPIP dist elle a pour conséquence de dépublier. Mais d'ailleurs, "stocker un article", ne serait-ce pas encore une métaphore qui se prend les pieds dans la lettre ? La notion de "statuts initiaux" et "finaux" est propre à certains flux mais certains workflows sont cycliques et n'ont pas de statuts finaux. Ya une différence dans l'exigence de généralité selon qu'on veut faire un plugin pour un besoin particulier ou modifier le noyau. Je partage mes questionnements car je ne comprend pas les critères de dissociation des statuts (ou je les trouve arbitraires, ou trop spécifiques quitte à élargir le périmètre) et peut être car je crains les complications que ça induirait. Mais je trouve intéressant la possibilité de définir des workflows. Et aussi la piste des statuts multivalués, comme des états superposés, qui feraient entrer SPIP dans l'ère quantique LOL. "publié" ET "poubellisé".

Mes quelques centimes : sujet très intéressant.

Il y a forcément des décisions arbitraires ou des parallèles avec le "monde réel" qui ont des limites, si on bloque là-dessus ça n'en finira jamais (je ne vise personne en particulier :p).

Pour aider à mieux cerner la proposition et à se faire un opinion, ça aiderait si on pouvait imaginer quelques exemples de workflows en prenant des objets ayant des cycles de vie assez différents.

On a déjà un exemple à priori pour les articles, mais pour les commandes, les abonnements ou les tickets, ça pourrait donner quoi ?

Mes quelques centimes : sujet très intéressant. Il y a forcément des décisions arbitraires ou des parallèles avec le "monde réel" qui ont des limites, si on bloque là-dessus ça n'en finira jamais (je ne vise personne en particulier :p). Pour aider à mieux cerner la proposition et à se faire un opinion, ça aiderait si on pouvait imaginer quelques exemples de workflows en prenant des objets ayant des cycles de vie assez différents. On a déjà un exemple à priori pour les articles, mais pour les commandes, les abonnements ou les tickets, ça pourrait donner quoi ?

La poubelle dans son acceptation habituelle n'est pas qu'un lieu de stockage puisqu'avec SPIP dist elle a pour conséquence de dépublier.

Non pas du tout.
L'état dépublié n'existe pas.
On dépublie parce qu'on met dans une archive ou parce qu'on considère l'objet obsolète mais un état dépublié n'a pas de sens sémantique.

Mais d'ailleurs, "stocker un article", ne serait-ce pas encore une métaphore qui se prend les pieds dans la lettre ?

Je ne comprend pas.

La notion de "statuts initiaux" et "finaux" est propre à certains flux mais certains workflows sont cycliques et n'ont pas de statuts finaux.

Alors non parce que le workflow est une implémentation du concept de cycle de vie des objets (si on veut en définir un pour un objet donné).
Par définition j'exclus la poubelle et l'archivage de ce cycle de vie pour les raisons expliquées.
Ensuite, le cycle de vie c'est un graphe états-transitions : il y a toujours un état initial et un état final et si ils sont identiques c'est qu'en fait il n'y a pas vraiment de cycle.

Ya une différence dans l'exigence de généralité selon qu'on veut faire un plugin pour un besoin particulier ou modifier le noyau.

Je ne comprend pas.
Il n'y a pas plus d'arbitraire dans cette proposition que la solution actuelle de SPIP.

Je partage mes questionnements car je ne comprend pas les critères de dissociation des statuts (ou je les trouve arbitraires, ou trop spécifiques quitte à élargir le périmètre) et peut être car je crains les complications que ça induirait.

C'est un autre sujet.
Tu cherches une vérité ultime dictée par je ne sais quelle explication de la nature.
On est dans de la modélisation qui n'est jamais la vérité mais une interprétation du réel.
Pour la complexité je ne partage pas tes craintes : du changement donc du boulot oui.

Mais je trouve intéressant la possibilité de définir des workflows.
Et aussi la piste des statuts multivalués, comme des états superposés, qui feraient entrer SPIP dans l'ère quantique LOL.
"publié" ET "poubellisé".

On a fait un pas en avant là...

> La poubelle dans son acceptation habituelle n'est pas qu'un lieu de stockage puisqu'avec SPIP dist elle a pour conséquence de dépublier. Non pas du tout. L'état dépublié n'existe pas. On dépublie parce qu'on met dans une archive ou parce qu'on considère l'objet obsolète mais un état dépublié n'a pas de sens sémantique. > Mais d'ailleurs, "stocker un article", ne serait-ce pas encore une métaphore qui se prend les pieds dans la lettre ? Je ne comprend pas. > La notion de "statuts initiaux" et "finaux" est propre à certains flux mais certains workflows sont cycliques et n'ont pas de statuts finaux. Alors non parce que le workflow est une implémentation du concept de cycle de vie des objets (si on veut en définir un pour un objet donné). Par définition j'exclus la poubelle et l'archivage de ce cycle de vie pour les raisons expliquées. Ensuite, le cycle de vie c'est un graphe états-transitions : il y a toujours un état initial et un état final et si ils sont identiques c'est qu'en fait il n'y a pas vraiment de cycle. > > Ya une différence dans l'exigence de généralité selon qu'on veut faire un plugin pour un besoin particulier ou modifier le noyau. Je ne comprend pas. Il n'y a pas plus d'arbitraire dans cette proposition que la solution actuelle de SPIP. > Je partage mes questionnements car je ne comprend pas les critères de dissociation des statuts (ou je les trouve arbitraires, ou trop spécifiques quitte à élargir le périmètre) et peut être car je crains les complications que ça induirait. C'est un autre sujet. Tu cherches une vérité ultime dictée par je ne sais quelle explication de la nature. On est dans de la modélisation qui n'est jamais la vérité mais une interprétation du réel. Pour la complexité je ne partage pas tes craintes : du changement donc du boulot oui. > > Mais je trouve intéressant la possibilité de définir des workflows. > Et aussi la piste des statuts multivalués, comme des états superposés, qui feraient entrer SPIP dans l'ère quantique LOL. > "publié" ET "poubellisé". On a fait un pas en avant là...

Mes quelques centimes : sujet très intéressant.

Il y a forcément des décisions arbitraires ou des parallèles avec le "monde réel" qui ont des limites, si on bloque là-dessus ça n'en finira jamais (je ne vise personne en particulier :p).

Oui. C'est une modélisation.

Pour aider à mieux cerner la proposition et à se faire un opinion, ça aiderait si on pouvait imaginer quelques exemples de workflows en prenant des objets ayant des cycles de vie assez différents.

On a déjà un exemple à priori pour les articles, mais pour les commandes, les abonnements ou les tickets, ça pourrait donner quoi ?

Oui, c'est aussi ce que je voulais présenter dans le lancement du fil mais j'ai eu la flemme.
Je vais essayer de faire quelques exemples de cycle de vie et de configuration possible.

> Mes quelques centimes : sujet très intéressant. > > Il y a forcément des décisions arbitraires ou des parallèles avec le "monde réel" qui ont des limites, si on bloque là-dessus ça n'en finira jamais (je ne vise personne en particulier :p). Oui. C'est une modélisation. > > Pour aider à mieux cerner la proposition et à se faire un opinion, ça aiderait si on pouvait imaginer quelques exemples de workflows en prenant des objets ayant des cycles de vie assez différents. > > On a déjà un exemple à priori pour les articles, mais pour les commandes, les abonnements ou les tickets, ça pourrait donner quoi ? Oui, c'est aussi ce que je voulais présenter dans le lancement du fil mais j'ai eu la flemme. Je vais essayer de faire quelques exemples de cycle de vie et de configuration possible.

Par défaut, je considère que la poubelle et l'archivage sont des changements de zone et ne font donc plus partis du cycle de vie des objets.
A cet égard, il faut aussi avoir un moyen (configuration ou mieux autorisation car c'est plus souple) pour dire si on accepte ou pas ces transferts (poubelle ou archivage) pour un objet. En effet, certains objets comme les taxons jusqu'au genre ne doivent pas être supprimés.

Si on considère les articles, le cycle de vie pourrait devenir le suivant :

L'interface de gestion pourrait devenir elle :

Pour les tickets le cycle de vie pourrait s'exprimer ainsi :

On voit que les identifiant des états ne sont pas les mêmes mais on pourrait réutiliser ceux de l'article, en particulier, l'état initial pourrait s'appeler prepa et avoir un libellé "Ouvert".

Dans le commentaire qui suit je donne quelques éléments sur la modélisation et l'implémentation que l'on peut imaginer.

Par défaut, je considère que la poubelle et l'archivage sont des changements de zone et ne font donc plus partis du cycle de vie des objets. A cet égard, il faut aussi avoir un moyen (configuration ou mieux autorisation car c'est plus souple) pour dire si on accepte ou pas ces transferts (poubelle ou archivage) pour un objet. En effet, certains objets comme les taxons jusqu'au genre ne doivent pas être supprimés. Si on considère les articles, le cycle de vie pourrait devenir le suivant : ![](https://git.spip.net/attachments/a1d03f19-d4e0-4f3e-ae6a-0c685e81c937) L'interface de gestion pourrait devenir elle : ![article-statut.png](/attachments/08726819-26bc-4801-bf3d-afce408e53ab) Pour les tickets le cycle de vie pourrait s'exprimer ainsi : ![ticket-statut.png](/attachments/e691c90a-e35f-4861-abda-f793ccc6bda3) On voit que les identifiant des états ne sont pas les mêmes mais on pourrait réutiliser ceux de l'article, en particulier, l'état initial pourrait s'appeler prepa et avoir un libellé "Ouvert". Dans le commentaire qui suit je donne quelques éléments sur la modélisation et l'implémentation que l'on peut imaginer.

article-statut.png

20 KiB

ticket-statut.png

17 KiB

Concepts de base

En premier lieu, le cycle de vie d'un objet est une machine à états finis (machine état-transition), à savoir, un type simple de workflow. En particulier:

il possède toujours un état initial,
à un instant donné, la machine est dans un seul état,
pour faire une transition, seul l'état courant est à considérer.

Un état possède un ensemble d'attributs:

un identifiant, aujourd'hui c'est une chaine comme prepa, prop ou publie.
un libellé qui exprime plus précisément l'état pour un objet donné? Pour spip c'est un item de langue associé au module de l'objet (type-objet_fr.php).
un type, initial, intermédiaire ou final.
et pour spip on pourrait imaginer un indicateur de visibilité dans le privé et dans le public de façon à simplifier les affichages
une liste de transitions possibles à partir de l'état (à voir si cela est nécessaire en lien avec l'état suivant l'implémentation choisi).
un traitement d'entrée dans l'état ou un traitement de sortie de l'état.

Une transition définit le passage d'un état à un autre et nécessite:

un identifiant, qui peut être optionnel si on considère que par défaut il est composé par l'état de départ et l'état d'arrivée (par exemple prepa_to_prop).
un libellé qui rappelle pour spip les texte des boutons instituer.
un condition d'exécution de la transition.
voire une commande à exécuter lors de la transmission.

De fait, une machine à états finis ou cycle de vie pour notre cas, est une composition d'états et de transitions associée à un objet.
On pourrait parler plus précisément de type de machine d'états associé ou associable à un type d'objet, et d'instance de ce type associée à un objet donné.

Une machine d'états pourrait donc posséder les attributs suivants:

un type, qui peut être matérialisé par un identifiant chaine comme "article-revue" pour le cycle actuel des articles
une liste d'états
une liste de transitions
un contexte lié principalement à l'objet concerné par le cycle de vie et qui peut se limiter au type et à l'id de l'objet.
l'état courant

Implémentations possibles

On pourrait utiliser la configuration de l'API objet pour injecter les éléments décrits ci-dessus. C'est surement pas le plus pérenne ni le plus évolutif.

En outre, l'un des intérêt de mettre en place une telle logique de cycle de vie est de pouvoir proposer plusieurs types de cycle pour un même objet. Par exemple, on pourrait définir un cycle "article-revue-simple" sans l'état prop, le choix pouvant être fait par article ou par rubrique ou autrement.

L'autre possibilité est donc de considérer une machine à états comme un objet en tant que tel et d'affecter un tel objet à chaque objet éditorial concerné comme les articles. Cela demande donc à définir comment on gère la persistance de ces objets machine d'états pour chaque objet éditorial.

Il faut aussi prévoir une configuration pour les types de machine d'états en php comme les objets spip (pipeline) ou par d'autres moyens (JSON, par exemple). La configuration des objets devra elle aussi évoluer ne serait-ce que pour indiquer les machines d'états associables, par défaut, etc.

@marcimat a rappelé la librairie symfony des workflows. J'ai aussi identifié une autre librairie qui je trouve implémente plus clairement les concepts d'états, de transitions, etc., à savoir, izzum-statemachine. Maintenant, je trouve que pour notre spip, avoir une librairie adaptée serait plus simple et éviterait de se perdre dans les méandres des généricités de ces librairies.

## Concepts de base En premier lieu, le cycle de vie d'un objet est une machine à états finis (machine état-transition), à savoir, un type simple de workflow. En particulier: * il possède toujours un état initial, * à un instant donné, la machine est dans un seul état, * pour faire une transition, seul l'état courant est à considérer. Un état possède un ensemble d'attributs: * un **identifiant**, aujourd'hui c'est une chaine comme prepa, prop ou publie. * un **libellé** qui exprime plus précisément l'état pour un objet donné? Pour spip c'est un item de langue associé au module de l'objet (type-objet_fr.php). * un **type**, initial, intermédiaire ou final. * et pour spip on pourrait imaginer un **indicateur de visibilité** dans le privé et dans le public de façon à simplifier les affichages * une **liste de transitions** possibles à partir de l'état (à voir si cela est nécessaire en lien avec l'état suivant l'implémentation choisi). * un **traitement d'entrée** dans l'état ou un **traitement de sortie** de l'état. Une transition définit le passage d'un état à un autre et nécessite: * un **identifiant**, qui peut être optionnel si on considère que par défaut il est composé par l'état de départ et l'état d'arrivée (par exemple prepa_to_prop). * un **libellé** qui rappelle pour spip les texte des boutons instituer. * un **condition** d'exécution de la transition. * voire une **commande** à exécuter lors de la transmission. De fait, une machine à états finis ou cycle de vie pour notre cas, est une composition d'états et de transitions associée à un objet. On pourrait parler plus précisément de **type de machine d'états** associé ou associable à un type d'objet, et d'instance de ce type associée à un objet donné. Une machine d'états pourrait donc posséder les attributs suivants: * un **type**, qui peut être matérialisé par un identifiant chaine comme "article-revue" pour le cycle actuel des articles * une liste d'états * une liste de transitions * un **contexte** lié principalement à l'objet concerné par le cycle de vie et qui peut se limiter au type et à l'id de l'objet. * l'**état courant** ## Implémentations possibles On pourrait utiliser la configuration de l'API objet pour injecter les éléments décrits ci-dessus. C'est surement pas le plus pérenne ni le plus évolutif. En outre, l'un des intérêt de mettre en place une telle logique de cycle de vie est de pouvoir proposer plusieurs types de cycle pour un même objet. Par exemple, on pourrait définir un cycle "article-revue-simple" sans l'état prop, le choix pouvant être fait par article ou par rubrique ou autrement. L'autre possibilité est donc de considérer une machine à états comme un objet en tant que tel et d'affecter un tel objet à chaque objet éditorial concerné comme les articles. Cela demande donc à définir comment on gère la persistance de ces objets machine d'états pour chaque objet éditorial. Il faut aussi prévoir une configuration pour les types de machine d'états en php comme les objets spip (pipeline) ou par d'autres moyens (JSON, par exemple). La configuration des objets devra elle aussi évoluer ne serait-ce que pour indiquer les machines d'états associables, par défaut, etc. @marcimat a rappelé la librairie symfony des workflows. J'ai aussi identifié une autre librairie qui je trouve implémente plus clairement les concepts d'états, de transitions, etc., à savoir, [izzum-statemachine](https://github.com/rolfvreijdenberger/izzum-statemachine). Maintenant, je trouve que pour notre spip, avoir une librairie adaptée serait plus simple et éviterait de se perdre dans les méandres des généricités de ces librairies.

Juste pour intervenir sur le choix technique, la lib https://github.com/rolfvreijdenberger/izzum-statemachine n'est maintenue que par deux personnes et n'a pas reçu de modification depuis 2017. Peut-être que c'est super stable et dans un "état" fini, ya plus rien à faire (cf les cycles de vie ^^), mais ça questionne par rapport à un package maintenu par symfony.

Juste pour intervenir sur le choix technique, la lib https://github.com/rolfvreijdenberger/izzum-statemachine n'est maintenue que par deux personnes et n'a pas reçu de modification depuis 2017.

Ah ben remarque vu le sujet et l'ampleur des fonctions supportées je ne vois que le café qui manquerait.
Sinon, mon avis qui n'est surement pas partagé est que ces librairies sont une bonne source d'inspiration pour développer la notre, plus adaptée à nos besoins plutôt modestes.

> Juste pour intervenir sur le choix technique, la lib https://github.com/rolfvreijdenberger/izzum-statemachine n'est maintenue que par deux personnes et n'a pas reçu de modification depuis 2017. Ah ben remarque vu le sujet et l'ampleur des fonctions supportées je ne vois que le café qui manquerait. Sinon, mon avis qui n'est surement pas partagé est que ces librairies sont une bonne source d'inspiration pour développer la notre, plus adaptée à nos besoins plutôt modestes.

pour développer la notre

c'est justement ce qu'on souhaite éviter en allant vers composer, mais rien n'empêche de développer nos trucs en se basant sur des libs maintenues par des communautés actives.

> pour développer la notre c'est justement ce qu'on souhaite éviter en allant vers composer, mais rien n'empêche de développer nos trucs en se basant sur des libs maintenues par des communautés actives.

Puisqu'il est question de "revue" dans ton exemple, pile poil j'ai un objet qui utilise un champ statut_revue en plus du champ statut. Ce champ a pour valeurs nouvelle, rubriquee, reecrite, relue, valide, publiee, repoussee (à un numéro ultérieur), rejetee (poubelle).
L'UI ne restreint pas les transitions entre ces statuts (c'est un SELECT exhaustif comme pour les statuts des articles actuellement), mais elle propose une facilité pour certaines transitions.
Certaines transitions sont en effet facilitée par la notion de flux de travail = un chantier d'édition sur un lot d'objets filtrés selon leur statut_revue, l'un après l'autre, c'est à dire que pour quitter un objet lorsque le travail a été effectué, on peut immédiatement passer à l'objet suivant dans le chantier en changeant aussi son statut_revue (ou pas).
C'est donc une navigation filtrée, éditrice et enregistreuse et qui transitionne l'état.
Les principaux chantiers sont "Rubriquer", "Reecrire", "Relire", "Valider". Pour chaque chantier est associée le statut_revue cible (enregistré par défaut lors du passage à la suivante) et la liste des statut_revue concernés : les statut_revue moins avancés, qui sont proposés par la navigation dans le chantier.
Par exemple dans le chantier "reecrire", la navigation enregistreuse ne propose que les statut_revue "nouvelle" et "rubriquee" et enregistre un statut "reecrite" lors de la validation et du passage au suivant dans la sélection.

Ça matche pas exactement ta proposition, mais ça fait clairement écho à certains de ses éléments.

Puisqu'il est question de "revue" dans ton exemple, pile poil j'ai un objet qui utilise un champ `statut_revue` en plus du champ `statut`. Ce champ a pour valeurs `nouvelle`, `rubriquee`, `reecrite`, `relue`, `valide`, `publiee`, `repoussee` (à un numéro ultérieur), `rejetee` (poubelle). L'UI ne restreint pas les transitions entre ces statuts (c'est un SELECT exhaustif comme pour les statuts des articles actuellement), mais elle propose une facilité pour certaines transitions. Certaines transitions sont en effet facilitée par la notion de `flux de travail` = un chantier d'édition sur un lot d'objets filtrés selon leur `statut_revue`, l'un après l'autre, c'est à dire que pour quitter un objet lorsque le travail a été effectué, on peut immédiatement passer à l'objet suivant dans le chantier en changeant aussi son `statut_revue` (ou pas). C'est donc une navigation filtrée, éditrice et enregistreuse et qui transitionne l'état. Les principaux chantiers sont "Rubriquer", "Reecrire", "Relire", "Valider". Pour chaque chantier est associée le statut_revue cible (enregistré par défaut lors du passage à la suivante) et la liste des statut_revue concernés : les statut_revue moins avancés, qui sont proposés par la navigation dans le chantier. Par exemple dans le chantier "reecrire", la navigation enregistreuse ne propose que les statut_revue "nouvelle" et "rubriquee" et enregistre un statut "reecrite" lors de la validation et du passage au suivant dans la sélection. Ça matche pas exactement ta proposition, mais ça fait clairement écho à certains de ses éléments.

c'est justement ce qu'on souhaite éviter en allant vers composer, mais rien n'empêche de développer nos trucs en se basant sur des libs maintenues par des communautés actives.

Je sais mais je n'adhère pas à cette logique si elle doit être systématique.
Apporter de la complexité uniquement parce qu'on a pas besoin de la maintenir est loin des objectifs d'échelon d'apprentissage que l'on prônait il y a un certain temps. Il y a un juste milieu à trouver.

Remarque c'est pas encore le sujet la librairie à utiliser, là je faisais surtout une référence parce que ça implémente bien les concepts de mon point de vue.

> c'est justement ce qu'on souhaite éviter en allant vers composer, mais rien n'empêche de développer nos trucs en se basant sur des libs maintenues par des communautés actives. Je sais mais je n'adhère pas à cette logique si elle doit être systématique. Apporter de la complexité uniquement parce qu'on a pas besoin de la maintenir est loin des objectifs d'échelon d'apprentissage que l'on prônait il y a un certain temps. Il y a un juste milieu à trouver. Remarque c'est pas encore le sujet la librairie à utiliser, là je faisais surtout une référence parce que ça implémente bien les concepts de mon point de vue.

Mes deux centimes.

Sur l'immense majorité des sites que je gère pour mes clients (non, en fait sur la totalité), que ce soient des institutionnels ou des magazines en ligne, il n'y a aucun besoin de workflow : il n'y a pas d'équipe rédactionnelle avec des circuits de validation hiérarchiques stricts, où un objet éditorial suivrait un chemin avec des états successifs.
Il y a juste un ou des webmestres et/ou des admins restreints qui publient eux même, et qui valident (publient) éventuellement les articles proposés par des rédacteurs / journalistes.
Et la gestion des statuts actuelle ne pose aucun souci.

Mes deux centimes. Sur l'immense majorité des sites que je gère pour mes clients (non, en fait sur la totalité), que ce soient des institutionnels ou des magazines en ligne, il n'y a aucun besoin de workflow : il n'y a pas d'équipe rédactionnelle avec des circuits de validation hiérarchiques stricts, où un objet éditorial suivrait un chemin avec des états successifs. Il y a juste un ou des webmestres et/ou des admins restreints qui publient eux même, et qui valident (publient) éventuellement les articles proposés par des rédacteurs / journalistes. Et la gestion des statuts actuelle ne pose aucun souci.

Et la gestion des statuts actuelle ne pose aucun souci.

Voui ça va dans le sens de mon premier avis en première lecture.

J'ai déjà vu passer quelques appels d'offre qui demandaient des workflows plus carrés, mais c'est très très rares, et encore plus concernant les articles (certaines fois ça concernaient plutôt les téléformulaires, où là ça parait plus évident).

Mais pour les sites déjà faits, jamais eu besoin, et jamais eu de demande des gens allant dans ce sens.

Il me semble qu'il faut distinguer le besoin intellectuel de concevoir des machines hyper rigoureuse, et les besoins exprimés. Il faut partir des besoins des gens.

Attention je le redis, je ne dis pas que ça n'existe pas, j'ai bien dit dès le début que je sais que c'est un besoin qui existe. Mais… un besoin plutôt rare. D'où la proposition précédente de concevoir et tester ça dans un plugin en premier lieu (quitte à surcharger quelques éléments tant que plugin), qui sera une fonctionnalité en soi, et si vraiment ça met en joie moult monde, on verra à l'intégrer en core.

> Et la gestion des statuts actuelle ne pose aucun souci. Voui ça va dans le sens de mon premier avis en première lecture. J'ai déjà vu passer quelques appels d'offre qui demandaient des workflows plus carrés, mais c'est très très rares, et encore plus concernant les articles (certaines fois ça concernaient plutôt les téléformulaires, où là ça parait plus évident). Mais pour les sites déjà faits, jamais eu besoin, et jamais eu de demande des gens allant dans ce sens. Il me semble qu'il faut distinguer le besoin intellectuel de concevoir des machines hyper rigoureuse, et les besoins exprimés. Il faut partir des besoins des gens. Attention je le redis, je ne dis pas que ça n'existe pas, j'ai bien dit dès le début que je sais que c'est un besoin qui existe. Mais… un besoin plutôt rare. D'où la proposition précédente de concevoir et tester ça dans un plugin en premier lieu (quitte à surcharger quelques éléments tant que plugin), qui sera une fonctionnalité en soi, et si vraiment ça met en joie moult monde, on verra à l'intégrer en core.

Attention je le redis, je ne dis pas que ça n'existe pas, j'ai bien dit dès le début que je sais que c'est un besoin qui existe. Mais… un besoin plutôt rare. D'où la proposition précédente de concevoir et tester ça dans un plugin en premier lieu (quitte à surcharger quelques éléments tant que plugin), qui sera une fonctionnalité en soi, et si vraiment ça met en joie moult monde, on verra à l'intégrer en core.

Je pense comme expliqué plus haut que cette approche serait bénéfique pour éviter à spip un code compliqué voire peu évolutif (et donc plus difficilement maintenable).
Donc ce n'est pas juste une lubie.

Maintenant, je ne vais pas m'échiner à expliquer ce qui parait inutile, passons à autre chose...

> Attention je le redis, je ne dis pas que ça n'existe pas, j'ai bien dit dès le début que je sais que c'est un besoin qui existe. Mais… un besoin plutôt rare. D'où la proposition précédente de concevoir et tester ça dans un plugin en premier lieu (quitte à surcharger quelques éléments tant que plugin), qui sera une fonctionnalité en soi, et si vraiment ça met en joie moult monde, on verra à l'intégrer en core. Je pense comme expliqué plus haut que cette approche serait bénéfique pour éviter à spip un code compliqué voire peu évolutif (et donc plus difficilement maintenable). Donc ce n'est pas juste une lubie. Maintenant, je ne vais pas m'échiner à expliquer ce qui parait inutile, passons à autre chose...

Ha bon ?

Merci @Eric d'ouvrir cette discussion. Pour ma part, j'utilise SPIP que comme framework, car je code que des applications métiers. Je n'utilise jamais l'espace privé. Je passe mon temps à détourner/enrichir les statuts des objets. Sur mon dernier projet, j'ai justement pensé qu'il faudrait enrichir SPIP d'un workflow.
Comme le souligne @marcimat , partir d'une lib maintenue par un équipe serait un gros plus, pour ne pas dire, indispensable.

si vraiment ça met en joie moult monde

🙂🙂

Merci @Eric d'ouvrir cette discussion. Pour ma part, j'utilise SPIP que comme framework, car je code que des applications métiers. Je n'utilise jamais l'espace privé. Je passe mon temps à détourner/enrichir les statuts des objets. Sur mon dernier projet, j'ai justement pensé qu'il faudrait enrichir SPIP d'un workflow. Comme le souligne @marcimat , partir d'une lib maintenue par un équipe serait un gros plus, pour ne pas dire, indispensable. > si vraiment ça met en joie moult monde 🙂🙂

Labels Milestones

Nouveau paradigme pour le statut des objets #5731

Concepts de base

Implémentations possibles