mviewer / mviewerstudio

mviewer generator
GNU General Public License v3.0
15 stars 25 forks source link

MEG-158 Amélioration panneau historique des modifications #158 #193

Closed spelhate closed 1 year ago

spelhate commented 1 year ago

En mode avancé actuellement on a ça : image

Dans le cas présent, on a deux versions publiées, mais une seule apparaît comme publiée (La première) car nous n'avons pas dépublié entre temps. /!\ Si on publie dans dé-publier préalablement rien n'indique qu'une version est publiée.

ce qu'on souhaite

Gaetanbrl commented 1 year ago

test lié à issue #158 (close)

A vérifier : Evolution hors besoin / spécifications initiales qui demandait de voir le statut d'une application et non pas les versions

Rappel du fonctionnement spécifié :

On peut publier une première fois une application et modifier le fichier sans republier. Dans ce cas, les modifications ne sont pas liées à la version publiée. Il faut alors recliquer sur "publier" pour que les dernières modifications soient visible dans la version "publiée".

Reste cependant à détailler pour être certain de cerner les besoins :

- Distinguer la version publiée active

@spelhate est-ce bien ta demande qu'en tant qu'utilisateur :

Je souhaite pouvoir voir à quelle sauvegarde (version) correspond la version actuellement publiée ?

- Distinguer toutes les versions publiées

Actuellement en effet, on a que la première publication et la dépublication (infos déjà hors cadre du besoin initial) affichées dans le tableau des version.

Ta demande est-elle bien la suivante :

  1. Je souhaite de voir toutes les fois où il a été cliqué sur "publié" sans avoir "dépublier" auparavant ?
  2. Je souhaite savoir quelle changement est intégré dans la version actuellement publiée ?

- Publier = nouvel enregistrement ?

A chaque fois que l'on clique sur "publier" => On va copier le XML de brouillon connu par le serveur (= dernière sauvegarde), notamment pour garder l'information de la meta dc:relation à jour dans le xml de brouillon et de publication.

Voici des exemples :

Parcours 1 - Ce cas là est bien pris en compte :

  1. Je modifie le titre pour avoir "titreABC"
  2. Je sauvegarde
  3. Je publie
  4. La publication affiche le titre "titreABC"

Parcours 2 - Modification non prise en compte :

  1. Suite au parcours 1 précédent, je modifie une seconde fois le titre pour avoir "titreXYZ"
  2. Je publie
  3. La publication affiche le titre "titreABC" car c'est l'information stockée en brouillon (la sauvegarde n'ayant pas eu lieu)
Gaetanbrl commented 1 year ago

Proposition @spelhate :

image

image

Gaetanbrl commented 1 year ago

Suite au correctif sur la branche issue-161-rebase (et uniquement cette branche !) :

Aperçu lorsqu'on publie une version (badge En ligne) mais qu'on a rajouté ensuite une modification qui n'est pas encore publiée (cochée comme active en brouillon). On voit notamment toutes les versions ou modifications qui sont dans la version actuellement publiée (badge En ligne) :

image

Après avoir recliqué sur "Publier" on voit qu'on est bien ISO entre la version brouillon et la version En ligne car la ligne en orange (= version publiée) est bien la ligne active (cochée) :

image

lecault commented 1 year ago

Mise en évidence dernière version publiée => ok Enregistrement à la publication => ok Distinguer les versions publiées => juste écrit version publiée pas de tag spécifique. Pas bloquant pour ma part.

Il y a un truc qui me perturbe c'est le fait d'avoir en ligne sur toutes les versions antérieures (ça me dérange pas sur brouillon). Car si je reviens sur une version antérieure avec le badge en ligne, elle n'est pas automatiquement publiée. Proposition : n'avoir le badge en ligne ou brouillon que sur la dernière version.

cas 1 : image

cas 2 : image

=> à valider avec @spelhate

Gaetanbrl commented 1 year ago

@lecault

le fait d'avoir en ligne sur toutes les versions antérieures

Le tag permet de mettre en évidence que tout ce qui est antérieur en date est compris dans la version "publiée" surlignée / mise en évidence en orange.

Distinguer les versions publiées => juste écrit version publiée pas de tag spécifique. Pas bloquant pour ma part.

"version publiée" est un tag classique avec un message "standard" spécifique aux tags et commits réalisés au clic sur "publier". Il n'existe pas de "tag spécifique", seul le message est personnalisé et commun pour les publications.

Car si je reviens sur une version antérieure avec le badge en ligne, elle n'est pas automatiquement publiée.

Non en effet, ca permet de conserver la version publiée. La logique de base est de devoir faire une action pour "valider" la publication et re publier une version. Ce cas d'usage a déjà été validé pour avoir 1 modification du brouillon = 1 clic sur "publier" pour re publier et éviter d'écraser la version publiée avec un brouillon.

Par exemple :

  1. Je fais une v1 finalisée => Je clique sur "publier" => Mes utilisateurs voient la carte.
  2. Finalement, la v1 convient mais je veux tout refaire pour fabriquer une v2 tout en laissant la v1 disponibles aux utilisateurs le temps que je fasse ma v2. => Je restaure, je fais ma v2 et là ensuite je publie ma v2 pour remplacer ma v1 sans provoquer d'interruption pour les utilisateurs.
spelhate commented 1 year ago

Il y a un truc qui me perturbe c'est le fait d'avoir en ligne sur toutes les versions antérieures (ça me dérange pas sur brouillon). Car si je reviens sur une version antérieure avec le badge en ligne, elle n'est pas automatiquement publiée. Proposition : n'avoir le badge en ligne ou brouillon que sur la dernière version.

Je pense la même chose.

Gaetanbrl commented 1 year ago

Modification disponible sur gis.jdev.fr branche issue-160 :

image

Gaetanbrl commented 1 year ago

A fermer @spelhate @lecault ?

spelhate commented 1 year ago

Ok pour moi.