Dans le cadre de la refonte de Contrib je réfléchis à la mise en place d’un système d’archivage pour les articles et les rubriques.
La solution actuelle via des sous-rubriques dédiées et un mot-clé me parait pas satisfaisante ni ergonomiquement ni intellectuellement.
Je me penche donc sur le plugin Archive, qui, il me semble a connu pas mal de discussions et peu d’aboutissements.
En lisant des trucs ça et là, j’avais d’abord cru comprendre que le but était initialement de ne pas perturber le statut des articles en utilisant un statut d’archive propre.
Ensuite, en lisant le code je découvre que le plugin fournit bien un nouveau statut d’article nommé archive mais crée toujours le champ du statut d’archive propre et de sa date qui est mis à jour suite au passage au statut d’article archive. Soit.
Sinon le plugin semble pas trop mal fonctionner si on exclu les notices et le fait qu’il ne couvre que les articles contrairement à son slogan (en anglais).
Donc je suis assez dubitatif : à quoi sert le statut d’archive propre si on utilise le statut de publication de l’article pour passer en archive ?
Si il y a eu une inflexion vers l’utilisation du statut de publication de d’article quel a été le rationnel pour en arriver là ?
J’avoue que je préférerais avoir un statut archive propre qui soit activé ou désactivé afin de conserver toujours le statut de publication de l’article. Mais ce débat a surement déjà eu lieu et avant de refaire un tour le mieux serait de connaitre la raison.
Si quelqu’un a un peu d’historique je suis preneur.
Merci
Oui mais le fait de modifier le statut pour l’archivage me parait pas la bonne solution.
On perd le statut de publication (par exemple refusé) alors qu’on veut juste à un moment mettre les articles dans un lieu moins accessible.
D’où mon intérêt pour le champ archive oui/non tel qu’il semblait exister à un moment donné.
Je n'ai pas regardé ce qui a été fait récement sur ce plugin, n'en
ayant plus l'utilité. Je n'ai donc pas idée de l'état du code actuel.
Une des raisons du plugins était que considérer l'information
"archivée" comme un statut était un non sens. Car un objet peut être
en brouillon, publié , ... et être archiver à un moment donné. Le fait
de l'archiver ne remet pas en cause son état précédent.
Car autrement il est impossible de restaurer à l'identique l'objet
archivé. Il y avait aussi une notion de date pour savoir quand cela
avait eu lieu et donc permettre des affichages conditionnels des
archives.
Je n’ai pas regardé ce qui a été fait récement sur ce plugin, n’en
ayant plus l’utilité. Je n’ai donc pas idée de l’état du code actuel.
Une des raisons du plugins était que considérer l’information
« archivée » comme un statut était un non sens. Car un objet peut être
en brouillon, publié , … et être archiver à un moment donné. Le fait
de l’archiver ne remet pas en cause son état précédent.
Car autrement il est impossible de restaurer à l’identique l’objet
archivé. Il y avait aussi une notion de date pour savoir quand cela
avait eu lieu et donc permettre des affichages conditionnels des
archives.
Ben oui, on est absolument d’accord.
Sauf qu’aujourd’hui le plugin Archive utilise le statut de publication de l’article et basta.
Il y a bien deux autres champs qui tendraient à prouver ce que tu dis sauf qu’ils ne sont pas ou plus utilisés.
Une des raisons du plugins était que considérer l'information
"archivée" comme un statut était un non sens. Car un objet peut être
en brouillon, publié , ... et être archiver à un moment donné. Le fait
de l'archiver ne remet pas en cause son état précédent.
Car autrement il est impossible de restaurer à l'identique l'objet
archivé. Il y avait aussi une notion de date pour savoir quand cela
avait eu lieu et donc permettre des affichages conditionnels des
archives.
Ben oui, on est absolument d'accord.
Sauf qu'aujourd'hui le plugin Archive utilise le statut de publication de l'article et basta.
Il y a bien deux autres champs qui tendraient à prouver ce que tu dis sauf qu'ils ne sont pas ou plus utilisés.
Vu que le code d'origine je l'ai pondu je me sens rassuré qu'il en
reste un bout
D'où mon interrogation.
Il faudrait reprendre les échanges sur la liste, mais j'ai
l'impression l'intention de base du plugin a été mal comprise. Il y
avait il me semble aussi une volonté de fusionner avec un autre
plugin.
Et comme j'ai laissé le plugin en open bar je n'ai pas du tout regardé
son évolution.
Vu ce que tu dis il faudrait probablement reprendre le code et le
réorienter sur son approche initiale.
Une des raisons du plugins était que considérer l'information
"archivée" comme un statut était un non sens. Car un objet peut être
en brouillon, publié , ... et être archiver à un moment donné. Le fait
de l'archiver ne remet pas en cause son état précédent.
Car autrement il est impossible de restaurer à l'identique l'objet
archivé. Il y avait aussi une notion de date pour savoir quand cela
avait eu lieu et donc permettre des affichages conditionnels des
archives.
Sauf qu'aujourd'hui le plugin Archive utilise le statut de publication de l'article et basta.
Il y a bien deux autres champs qui tendraient à prouver ce que tu dis sauf qu'ils ne sont pas ou plus utilisés.
Une solution pourrait être de changer le statut de l'objet en archive, pour qu'il ne soit plus publié côté public, mais en même temps de stocker son statut actuel (prepa, prop, refuse...) dans un champ statut_originel, ce qui garde l'info, et permet plus tard de le désarchiver en remettant le statut d'origine.
Sauf qu’aujourd’hui le plugin Archive utilise le statut de publication
de l’article et basta.
Il y a bien deux autres champs qui tendraient à prouver ce que tu dis
sauf qu’ils ne sont pas ou plus utilisés.
Une solution pourrait être de changer le statut de l’objet en archive,
pour qu’il ne soit plus publié côté public, mais en même temps de
stocker son statut actuel (prepa, prop, refuse…) dans un champ
statut_originel, ce qui garde l’info, et permet plus tard de le
désarchiver en remettant le statut d’origine.
Oui c’est possible et je l’ai envisagé aussi.
Mais en fait ça demande ensuite à avoir un bouton pour revenir au statut avant archive ce qui demande donc à rendre inopérant le formulaire de statut ou à le personnaliser.
Je ne suis pas sur que ce soit plus simple juste pour ne pas trop modifier la logique des boucles.
Je pense vraiment que l’archivage doit être géré à part du statut de publication, mon seul souci c’est de savoir si je reprends le plugin Archive en ce sens sachant qu’il existe le plugin Archstatut qui utilise déjà le statut archive ou est ce que je développe un autre plugin avec une autre préfixe etc.
Je trouverais plus logique d’utiliser Archive mais j’aimerais avoir des vis de ceux qui l’utilisent.
Après, je me dis quand même que cette fonctionnalité est suffisamment basique pour intégrer le core ou la dist.
la notion d'archivage (à mon sens) n'est pas liè à un processus de
publication contrairement aux statuts. Les statuts sont des étapes
dans les vie d'une publication, l'archivage est un autre concept.
C'est pourquoi pour moi c'est bien une information séparée.
J'ai souvenir au début de ce plugin qu'avait été abordé la
problématique d'intégrer au core. C'était l'époque du dégraissons le
mammouth. Cela n'avait pas de sens d'être intégré en natif; Je pense
toujours que cela devrait être isolé. La base n'a pas besoin de ce
concept pour fonctionner.
Et comme je l'ai dit j'ai laissé le plugin en open bar, ce serait avec
plaisir de reprendre un peu le code. Mais clairement vu tous mes
autres trucs en cours, je préfères laisser la main aux personnes qui
voudront bien coder
Je trouverais plus logique d'utiliser Archive mais j'aimerais avoir des
vis de ceux qui l'utilisent.
Il me semble l'avoir utilisé ya très longtemps et moi aussi je me
souviens parfaitement d'un champ séparé du statut. Et je suis
parfaitement pour rester dans ce sens.
Avec "statut_originel", si on désactive le plugin, ça va laisser un
statut qui n'existe pas sur les objets, et ça va même tout niquer à
priori. Si on désinstalle ça lance une fonction dédié qui peut remettre
au propre avant de partir mais si on désactive uniquement, c'est tout pété !
Et un champ dédié permettrait de le rendre utilisable sur tous les
objets plus facilement aussi. Dès qu'il y a ce champ, dans pre_boucle ou
masque les résultats et hop, quelque soit l'objet.
Vu que c'était déjà comme ça au début, je suis plutôt pour garder un
seul même plugin et pas s'éparpiller.
C'est donc à lui d'en dire plus et d'argumenter s'il faut avoir du
détail… Vu que du coup, tout le monde a plutôt l'air d'être pour la
conception de départ, sauf lui
Dans le cadre de la refonte de Contrib je réfléchis à la mise en place d'un système d'archivage pour les articles et les rubriques.
La solution actuelle via des sous-rubriques dédiées et un mot-clé me parait pas satisfaisante ni ergonomiquement ni intellectuellement.
Et que penses-tu de plugin Masquer ?
Il utilise un mot clef (mais ça pourrait être un champ supplémentaire via Extra ou autre)
Et le pipeline pre_boucle pour masquer ce qui doit l'être.
Et un modificateur {tout_voir} pour pouvoir quand même lister le contenu dans le public.
Il me semble l’avoir utilisé ya très longtemps et moi aussi je me
souviens parfaitement d’un champ séparé du statut. Et je suis
parfaitement pour rester dans ce sens.
C’est aussi mon cas.
Je crois qu’on est pas mal dans ce cas.
Avec « statut_originel », si on désactive le plugin, ça va laisser un
statut qui n’existe pas sur les objets, et ça va même tout niquer à
priori. Si on désinstalle ça lance une fonction dédié qui peut remettre
au propre avant de partir mais si on désactive uniquement, c’est tout pété !
Et un champ dédié permettrait de le rendre utilisable sur tous les
objets plus facilement aussi. Dès qu’il y a ce champ, dans pre_boucle ou
masque les résultats et hop, quelque soit l’objet.
Ouep, c’est aussi mon avis.
Le mécanisme archive / désarchive devient très simple en plus.
Vu que c’était déjà comme ça au début, je suis plutôt pour garder un
seul même plugin et pas s’éparpiller.
Je préfère aussi.
Mais ça dépend de l’utilisation qui est faite aujourd’hui du plugin Archive.
C’est donc à lui d’en dire plus et d’argumenter s’il faut avoir du
détail… Vu que du coup, tout le monde a plutôt l’air d’être pour la
conception de départ, sauf lui
Le jeu. 24 oct. 2019 à 14:59, RealET <real3t@gmail.com> a écrit :
Eric Lupinacci a écrit le 12/10/2019 à 20:56 :
Hello,
Dans le cadre de la refonte de Contrib je réfléchis à la mise en place
d’un système d’archivage pour les articles et les rubriques.
La solution actuelle via des sous-rubriques dédiées et un mot-clé me
parait pas satisfaisante ni ergonomiquement ni intellectuellement.
Et que penses-tu de plugin Masquer ? https://contrib.spip.net/Plugin-masquer
Il utilise un mot clef (mais ça pourrait être un champ supplémentaire
via Extra ou autre)
Et le pipeline pre_boucle pour masquer ce qui doit l’être.
Et un modificateur {tout_voir} pour pouvoir quand même lister le contenu
dans le public.
Ouais je comprends pas ce plugin.
Masquer pour quelle raison ?
C’est un peu un mécanisme qui ne dit pas pourquoi on le fait.
En tout cas pas de mot-clé.
Et on veut un archivage.
Donc je pense qu’on va rester sur Archive ou un autre plugin du même type.
Le jeu. 24 oct. 2019 à 14:59, RealET <real3t@gmail.com <mailto:real3t@gmail.com>> a écrit :
Eric Lupinacci a écrit le 12/10/2019 à 20:56 :
> Hello,
>
> Dans le cadre de la refonte de Contrib je réfléchis à la mise en
place
> d'un système d'archivage pour les articles et les rubriques.
> La solution actuelle via des sous-rubriques dédiées et un mot-clé me
> parait pas satisfaisante ni ergonomiquement ni intellectuellement.
Et que penses-tu de plugin Masquer ? Plugin « masquer » - SPIP-Contrib
Il utilise un mot clef (mais ça pourrait être un champ supplémentaire
via Extra ou autre)
Et le pipeline pre_boucle pour masquer ce qui doit l'être.
Et un modificateur {tout_voir} pour pouvoir quand même lister le
contenu
dans le public.
Ouais je comprends pas ce plugin.
Masquer pour quelle raison ?
C'est un peu un mécanisme qui ne dit pas pourquoi on le fait.
En fait, il ne préjuge pas de la raison.
Mais il permet très bien l'usage "archivage"
Comme on peut même renommer le mot clef...
En tout cas pas de mot-clé.
C'est pour ça que je disais que ça pouvait être transformé pour utiliser un champ dans la base.
Et on veut un archivage.
- conserver le statut de l'article
- l'exclure de la navigation standard
- pouvoir le consulter quand même (si squelette prévu pour) en étant prévenu de son statut d'archive
Si c'est ça que tu entends par "archivage", ce plugin répond au cahier des charges.
Le jeu. 24 oct. 2019 à 14:45, RastaPopoulos <rastapopoulos@spip.org <mailto:rastapopoulos@spip.org>> a écrit :
Il me semble l'avoir utilisé ya très longtemps et moi aussi je me
souviens parfaitement d'un champ séparé du statut. Et je suis
parfaitement pour rester dans ce sens.
C'est aussi mon cas.
Je crois qu'on est pas mal dans ce cas.
Au vu de vos échanges sur le côté "Archive", cette séparation en 2 me parait correcte et plus pertinente qu’un statut 'archive'.
Il y a aussi des plugins de "Dépublication" qui sont proches, mais plus avec l’idée de ne plus rendre accessible le contenu ensuite, au bout d’une certaine période de temps. Il y en a sur la zone, et j’en ai un aussi sur Magraine / Depublication · GitLab (il ajoute un statut 'depublie' et 2 champs).
