Plugin Archivage des contenus : actions sur les objets

Dev
#1

La version 0.5.4 commence à fournir un mécanisme d’archivage stable et résilient. Maintenant j’en arrive à me poser des questions sur les actions classiques sur les objets en fonction du contexte d’archivage. En particulier, étant donné que l’archivage prend en compte la notion de parenté et propage ses actions sur les enfants, les actions standard de création, changement de statut, déplacement doivent être étudiées.

Le changement de statut :
C’est le cas le plus simple, le plugin Archivage de contenus interdit le changement en rendant non éditable le formulaire d’institution.

La création d’un objet :
Si l’objet n’a pas de parent, comme un auteur par exemple, le mécanisme d’archivage n’interfère en rien avec le mécanisme de création de l’objet.
Par contre, si l’objet possède une parenté, comme un article et sa rubrique, doit-on autoriser la création d’un objet dans un objet conteneur archivé et si oui, l’objet créé doit-il hériter de l’archivage de son conteneur ?
Étant donné que l’API objet ne permet pas de désigner l’autorisation de création d’un objet, le plugin n’est pas en mesure de savoir comment interdire le mécanisme de création.

Donc si on l’autorise, faut-il hériter de l’état d’archivage du conteneur ? Si oui, doit-on le conditionner au paramètre modifier_enfant qui permet de rendre indépendant des branches d’archivage.
Mon avis est que le mieux serait d’interdire la création mais si cela n’est pas possible de ne pas hériter de l’état d’archivage du conteneur. Et vous ?

Le déplacement d’un objet :
Le déplacement ne concerne lui que les objets appartenant à un conteneur et que l’on change de conteneur. A l’instar de la création, il n’y a pas d’autorisation standard surchargeable pour l’interdire.
De fait, il faut étudier les cas de déplacements, à savoir :

  1. déplacer un objet archivé dans un conteneur non archivé
  2. déplacer un objet archivé dans un conteneur archivé
  3. déplacer un objet non archivé dans un conteneur archivé

Mais pour un déplacement il faut prendre en compte que la propagation des enfants implique de conserver la racine initiatrice dans le contexte de chaque enfant. Déplacer un enfant ailleurs que dans la branche formée par la racine doit mener à modifier le contexte d’archivage de l’enfant sinon il réfèrera à une racine qui n’a plus de sens pour lui.

Pour l’instant, le plugin ne fait rien mais ce n’est pas satisfaisant. On pourrait imaginer :

  1. l’objet déplacé conserve son archivage et si il réfère à un héritage, celui-ci est supprimé
  2. l’objet déplacé conserve son archivage et suivant le paramètre modifier_enfants intègre la branche archivée du conteneur destination ou pas
  3. l’objet déplacé, suivant le paramètre modifier_enfants devient une archive héritant du conteneur destination ou demeure non archivé.

Tout cela n’est pas simple et c’est pourquoi vos avis sont plus que les bienvenus.
Merci d’avance.

#2

Étant donné que l’API objet ne permet pas de désigner l’autorisation de création d’un objet, le plugin n’est pas en mesure de savoir comment interdire le mécanisme de création.

on n’a pas autoriser_publier_dans ? au moins pour les rubriques.

Mon avis est que le mieux serait d’interdire la création mais si cela n’est pas possible de ne pas hériter de l’état d’archivage du conteneur. Et vous ?

il me parait logique qu’un objet archivé ne puisse pas être modifié, donc pas d’enfant dedans

Pour l’instant, le plugin ne fait rien mais ce n’est pas satisfaisant. On pourrait imaginer :

dans l’idéal, on ne devrait pas pouvoir déplacer un objet qui se trouve dans un objet archivé, de quelque manière que ce soit (pour moi archivage=gel). J’entend que cela n’est pas possible actuellement. A ce moment là, le 1 me paraitrait le plus cohérent.

#3

Bonjour,

Préalable : mon cas d’usage depuis des années (avec un mot clef Archive) est le suivant :

  • Archive sert à nécessiter un clic de plus côté public (sur un bouton Archives) pour voir les contenus archivés
  • Les rubriques et articles Archivés sont visibles pour tout le monde (ça n’est pas le plugin Accès Restreint)
  • Les rubriques ayant du contenu archivé ont un bouton Archives permettant d’aller voir la liste des articles archivés

Pourquoi je préfère le plugin d’Éric ?

  • Parce qu’il a une dimension d’héritage (actuellement uniquement au clic sur le bouton Archiver) et qu’il permet donc d’archiver une branche et non pas seulement une rubrique
  • Parce qu’il permet de consulter tout ce qui est archivé (entrée supplémentaire dans les menus de SPIP)
  • Parce qu’il sépare visuellement les contenus archivés ou non dans une rubrique

Ceci posé, même si la question de l’héritage peut se voir de manière générique, son application principale, ce sont les rubriques et leur contenu.
Quand on a le métier d’archiviste, on peut être amené à classer différemment le contenu archivé :

  • changement de catégorie (déplacement dans une autre rubrique)
  • création d’une nouvelle catégorie (création rubrique)
  • ajout d’un contenu (création ou déplacement d’un article)
  • changement de local d’un casier (déplacement d’une rubrique hors de la racine archivée)

Ceci me conduit à proposer la chose suivante :

  • considérer qu’Archivé est un attribut
  • dont les seules contraintes sont :
    • un filtrage dans les boucles et dans l’admin des contenus archivés ou non
    • une conservation du caractère archivé en cas de déplacement (si je déplace une rubrique ou un article archivé dans une rubrique non archivée, la rubrique ou l’article reste archivé)
    • un héritage du caractère archivé en cas de déplacement ou de création (si je déplace ou crée un article ou une rubrique dans une rubrique archivée, alors ce contenu est archivé, y compris le contenu de la rubrique)

Pourquoi c’est pertinent ?

  • Parce qu’il serait contrintuitif d’avoir du contenu non archivé dans une rubrique archivée
  • Parce qu’il serait contrintuitif d’enlever le caractère archivé à un contenu en le déplaçant, sachant que si c’était ce qui était désiré, il est toujours possible de désarchiver ensuite
  • Parce qu’il serait dangereux d’enlever automatiquement le caractère archivé avec les conséquences que cela aurait sur le site public

PS : cette discussion a commencé ici : Héritage du statut d'une rubrique pour les articles (#5) · Tickets · spip-contrib-extensions / archive_objet · GitLab
PS² : j’ai codé dans SoyezCréateurs en m’appuyant sur ce plugin 99% de ce que je décris ici

#4

Et autre argument de pourquoi c’est pertinent : parce que la grande force de SPIP, c’est d’être extrêmement peu contraignant sur le workflow.

Je serais donc d’avis qu’il ne faut même pas contraindre le changement de statut (en cours de rédac, publié…) d’un article placé dans une rubrique archivée.
Seulement interdire de désarchiver un article placé dans une rubrique archivé (primauté du caractère archivé du parent sur l’enfant).

#5

Je ne suis pas d’accord avec ce postulat car suivant la profondeur de la branche cela peut-être réaliste. Il existe le paramètre modifier_enfant qui permet d’activer ou de désactiver cette possibilité.

Oui, tout à fait, c’est pertinent de ne pas changer l’archivage dans ce cas, en particulier, en considérant les conséquences possibles sur le site.

Pour la création je suis plus dubitatif en particulier si il s’agit d’un enfant comme un article : pourquoi créer un contenu archivé ? La question se pose plus si on considère un objet conteneur hiérarchique comme les rubriques où là on peut imaginer créer une structure nouvelle pour ranger les archives.

C’est une faiblesse pas une force justement. Si on avait des workflows, les gens comprendrait mieux et les sujets tels celui que l’on débat seraient mieux appréhendés.

Je veux bien le mettre en paramétrage avec par défaut le blocage mais je ne suis pas du tout d’accord sur l’approche car c’est justement lié au statut comme je l’ai expliqué dans le ticket Nouveau paradigme pour le statut des objets (#5731) · Tickets · spip / spip · GitLab. C’est un peu comme la création pourquoi changer le statut d’un contenu ou d’un conteneur archivé ? L’archivage n’est pas un masquage mais une opération mettant de coté des contenus existants.

C’est le cas par défaut mais le paramètre modifier_enfant peut casser ce fonctionnement.

#6

A contrario, le problème des workflow figés, c’est la perte d’humanité et l’argument classique de « je peux pas, c’est la machine ».

#7

Non c’est n’importe quoi ça. En quoi il y a plus d’humanité à laisser faire n’importe quoi sans comprendre ? Le workflow permet de guider les gens donc de les aider, je trouve ça plus « humain » non ?

Je ne comprends pas cette logique de dire que permettre tout est le fait d’une empathie absolue surtout qu’on ne choisit pas une transition (comme tous les boutons du reste de l’espace privé) mais un état destination.
C’est juste une facilité pour le développeur et une difficulté pour l’utilisateur ou l’utilisatrice.

#8

Le 03/06/2024 à 10:45, Eric Lupinacci via Discuter de SPIP a écrit :

Non c’est n’importe quoi ça. En quoi il y a plus d’humanité à laisser faire n’importe quoi sans comprendre ? Le workflow permet de guider les gens donc de les aider, je trouve ça plus « humain » non ?

Parce que tu ne peux pas prévoir tous les cas possibles d’avance, et que laisser les humains décider entre eux, en discutant entre humains de quoi faire, c’est ça qui fait qu’on peut avoir des outils informatiques « qui aident un peu » (à telle ou telle tâche) sans pour autant contraindre les gens .

Dans la majorité des cas, SPIP est utilisé par des gens seuls, ou des petites équipes, et seulement dans de très rares cas par des immenses structures avec plein de monde où il faut contrôler tout dans le moindre détail.

Ce pourquoi je pense aussi que par défaut ça doit rester souple et juste laisser les gens décider entre eux, aller, revenir, se tromper parfois mais dans 99% des cas sans gravité. Et avoir un système méga carré cloisonné seulement en plugins pour des cas rares de structure… un peu inhumaine (grosse boite de centaines de gens, plein de hiérarchie et de droits précis à respecter).

À la base SPIP c’est en premier lieu pour gérer un média en commun, en équipe qui se connait et se parle entre elleux, pas pour gérer un site du CEA (ce qui est possible aussi mais ça vient en plus).

–
RastaPopoulos

1 « J'aime »
#9

Bah, on va en rester là car ce n’est pas le sujet du fil et que je pense que ça va mal tourner.
A part ça quelque chose sur l’archivage parce que ça m’aiderait plus, le sujet n’étant lui pas trivial ?

#10

Je vois ce genre d’argument de plus en plus… et avec la multiplication des espaces de discussion (après l’éparpillement des lieux de doc) ça devient impossible de savoir où est le bon endroit pour porter un avis… et ça fait taire les avis contraires en avortant les discussions.
Dommage.

Ce point de vue éclaire certaines problématiques évoquées plus haut en rapport avec les fonctionnalités de l’archivage et les choix à faire… C’est large mais c’est pertinent.

1 « J'aime »
#11

Remarque parfois il suffit de lire le fil plutôt que d’accuser d’emblée. J’ai donné le lien du sujet sur les workflows dans les tickets spip. La j’essaye d’avoir un peu de retour sur un plugin compliqué dont je pensais qu’il intéresserait plus de gens et a part jacques a priori non.

Pour ta deuxième remarque j’ai perdu mon décodeur. Je ne comprends pas ton sous-entendu

#12

En disant « ce n’est pas le sujet du fil » ou « c’est pas ici qu’il faut en parler », souvent la discussion ne se poursuit pas et parfois c’est bien dommage. « c’est n’importe quoi ça. » écrivais tu péremptoire, puis « ce n’est pas le sujet du fil et que je pense que ça va mal tourner. » écrivais tu au mieux défaitiste et au pire auto-prophète de l’embrouille.

« tu ne peux pas prévoir tous les cas possibles d’avance, et que laisser les humains décider entre eux, en discutant entre humains de quoi faire, c’est ça qui fait qu’on peut avoir des outils informatiques « qui aident un peu » (à telle ou telle tâche) sans pour autant contraindre les gens »
Je trouve que ça mérite ton attention.

1 « J'aime »
#13

Oui ce n’est pas le sujet du fil, ça n’empêche pas d’en discuter sur quelques posts mais si ensuite ça devient le sujet principal je serais le seul embêté. Je te rassure j’en ai plus :wink:

Après, sur le sujet du workflow je respecte les avis constructifs mais je pense que certains sont un peu du foutage de gueule. Me dire que c’est KISS de laisser les gens choisir un état pas forcément compréhensible de prime abord plutôt qu’une action avec un verbe qui l’est c’est se mettre dans la position du connaisseur de spip et pas des utilisateurs, et faire un cas particulier alors que toutes les autres actions de spip sont des verbes.
On a l’impression que le KISS prend la forme qui arrange… Et puis le KISS c’est la négation de la vie, de la réalité. Sans vouloir lancer un débat politique c’est un peu le mal de notre société qui devient de plus en plus binaire, enfin quand ça l’arrange.

Je crois que j’ai un peu répondu au paragraphe précédent. Mais ça aussi c’est la novlangue qui veut refermer le débat : c’est plus humain, c’est du complotisme, c’est ci ou c’est là.
Je pense que c’est le plus gros foutage de gueule dans ce post : je demande à plus se rapprocher d’une logique réelle et c’est moi qui suit accusé de m’éloigner de l’humain. Ben voyons.

Et puisqu’on digresse, alors allons-y. Je pense que nous avons ces discussions sans lendemain parce que nous avons abandonné dans spip le fait de se poser des questions sur son évolution fonctionnelle en renvoyant ça dans les plugins. Il suffirait que les plugins dist deviennent des plugins sans dist et spip deviendrait un squelette désincarné.

Je sais que beaucoup ne sont pas d’accord avec ça mais je n’en reste pas moins convaincu que penser spip comme un « squelette minimal » sans âme est une erreur à long terme.

#14

Foutage pour foutage… :stuck_out_tongue:
=> C’est fermer des workflows très définis qui est binaire, alors que choisir des états ouverts et libres d’alternance, ça l’est moins.
=> Le KISS c’est avant tout pour le dev, ne pas maintenir de machinerie complexe par défaut quand ça peut rester simple avec juste des états libres. Et faire du complexe en plugins pour les sites où ça sera utile.
=> SPIP sans squelette minimal est justement conçu en premier lieu pour des médias avec des petites équipes de personnes assez horizontales qui se connaissent et se parlent entre elles (et même parfois des gens tout seul ! très souvent !). Donc c’est très exactement mon propos de revenir à ce pourquoi il est fait en premier lieu avant de parler de machine à gaz ultra carrées et cloisonnées côté dev (« on peut faire ceci cela dans tel ordre précis et faut modifier du PHP si on veut autoriser autre chose »).

Se « rapprocher d’une logique réelle », c’est donc définir UNE logique réelle en tant que dev, et ne pas en déroger dans les workflows. C’est une fonctionnalité qui est parfaitement recevable et qui est utile majoritairement sur des gros sites avec beaucoup de comptes et une structure plutôt hiérarchisée : moi-même j’ai fait des sites pour plusieurs structures où ils auraient besoin de workflows un peu carré, je vois très bien pour qui ça serait utile. Mais justement ce pour quoi SPIP a été conçu au départ, il me semble que c’est là où faut laisser plus de souplesse et d’horizontalité, et ne pas bloquer trop de choses par défaut.

1 « J'aime »
#15

Tu me fais dire ce que je n’ai pas dit.

Si tu veux continuer le plat de nouilles de spip actuel tu peux très bien.
Mais si on avait une approche « workflow » pour les statuts on pourrait faire ce qu’on veut par exemple dans une rubrique spécialisée avec une gestion plus rigoureuse sachant que par défaut le plat de nouilles est toujours disponible.
Et pour ajuster les statuts ça serait aussi plus simple.

Donc je ne dis pas qu’il faut imposer un autre workflow par défaut mais instaurer une logique de workflow où chacun pourrait choisir son processus.
Par contre, je reste convaincu que la poubelle devrait sortir des statuts tout comme l’archivage. Et pour les auteurs scinder les droits et le statut serait humain ;).

#16

Je pense qu’on a fait le tour et que ce fil ne produira plus d’idées supplémentaires. Je vais le fermer.
Néanmoins, je vais ouvrir un autre fil sur l’API Objet car ce plugin met en lumière il me semble quelques lacunes qu’il seraient bon de combler et qui ne sont pas liées au statut.

1 « J'aime »
#17