Produits Entr'ouvert » w.c.s.

Tu verrais un truc automatique sur toute modif (i.e. on déplace un champ, nouvelle version, on en modifie le libellé, nouvelle version, etc.) ou plutôt la possibilité à l'utilisateur d'"enregistrer" explicitement le formulaire/workflow ?

Enregistrement explicite. Sinon ça me semble compliqué à gérer, trop de
versions.

Thomas me fait remarquer qu'il vaut mieux utiliser la date pour identifier une version plutôt qu'un système de numérotation de version classique. Bien mieux pour les utilisateurs.

De mon côté, en terme de fonctionnalité, je pensais m'inspirer de la notion de snapshot qui existe dans les projets Ardour, il y a juste un titre qui est demandé à l'utilisateur (qui est peut-être même prérempli avec la date/heure).

Ça me va aussi (même si garder un horodatage indépendant du nom me
semble pas idiot).

Pour le nom des snapshots, j'imagine que c'est lors de l'export ("donnez un nom de version").

Mais ensuite, quand on importe, le nom apparait... et devra disparaitre à la première modification (ou alors on indique : "a été importé le xxx sous le nom bidule, et a été modifié x fois depuis").

Bref, pourquoi pas, mais pour moi la notion de "date de dernière modif" reste pertinente.

Thomas Noël a écrit :

Pour le nom des snapshots, j'imagine que c'est lors de l'export ("donnez un nom de version").
Mais ensuite, quand on importe, le nom apparait... et devra disparaitre à la première modification (ou alors on indique : "a été importé le xxx sous le nom bidule, et a été modifié x fois depuis").
Bref, pourquoi pas, mais pour moi la notion de "date de dernière modif" reste pertinente.

Ah heu mais bon, je comprends tout d'un coup que votre notion de "snapshot" n'est pas que lors de l'import/export, et je me tais, donc.

C'est quoi que tu mets derrière ces notions d'import/export ?

Pour moi la fonctionnalité ici elle est :

• je travaille sur un formulaire
• à un moment je clique dans la barre latérale sur le bouton "enregistrer un snapshot"
• ça ouvre une boite de dialogue qui me demande "quel nom ?"

Et plus tard, après avoir fait une boulette :

• je clique dans la barre latérale sur le bouton "snapshots"
• ça m'affiche une liste des snapshots, avec leurs noms et dates
• je sélectionne un snapshot
• je clique sur "revenir à ce snapshot"

Oui, je m'étais trompé d'idée, la tienne est la bonne, implémentons cela.

Moi je pensais à "je prends le formulaire de la recette pour le mettre en prod, et j'ai un indicateur sur chaque plateforme qui me dit que c'est bien exactement la même version sur les deux". Ceci dit, je pense que la fonctionnalité que je décris ici ("faire en sorte que le numéro de version + sa date s'affiche, s'exporte et s'importe" sera utile dans le cas que je décris (mise en prod d'un formulaire). Sans doute est-ce un autre ticket à faire une fois qu'on aura la notion de snapshot terminée.

Comme j'aime bien ne pas être d'accord pour moi la bonne solution c'est la conservation automatique d'un historique juste avec des dates, et éventuellement la description du changement si on peut « modification champ(s) x, y, z », « suppression », « création » et la possibilité de revenir à une version, créant dans l'historique une entrée « restauration version du yyyy-mm-dd hh:mm:ss »; c'est bien plus pratique. Le fait d'obliger les gens à penser à faire un snapshot, en plus en lui donnant un nom, c'est anti-ergonomique au possible. L'historique ce qui se rapproche le plus d'un bouton « Undo » qu'on pourrait même implémenter en renvoyant simplement à la version n-1.

Au niveau implémentation je ferai ça avec une unique table et/ou répertoire qui contiendrait l'historique de tout, avec un index pour pouvoir filtrer par type d'objet/identifiant d'objet, on peut y stocker le pickle de l'objet directement dans un champ blob.

Pour moi il faudrait aussi renommer le ticket, c'est pas du versionning dont on parle mais d'historicisation, le versionning ça serait plutôt ce que veut Thomas, qui pourrait d'ailleurs faire l'objet d'un autre ticket parce que c'est intéressant.

Comme j'aime bien ne pas être d'accord

Le problème n'est pas que tu sois pas d'accord mais que tu raisonnes
sans te figurer le besoin d'utilisateurs qui sont très éloignés de tes
propres pratiques, et auquel je suis pour ma part directement confronté.

pour moi la bonne solution c'est la conservation automatique d'un
historique juste avec des dates, et éventuellement la description du
changement si on peut « modification champ(s) x, y, z »,

Je fabrique des formulaires, je ne suis pas informaticien, chaque fois
que je déplace un champs, une version est créée dans l'historique, je
m'y perds totalement, je ne sais plus quelle version correspond à quoi.
Et non avoir une liste des modifs à côté ne va pas beaucoup m'aider : il
faudrait que je lise ces listes, ce qu'assurément je ne vais pas faire,
préférant cliquer partout.

Le vendredi 13 juin 2014 à 19:14 +0200, redmine@entrouvert.com a écrit :

Pour moi il faudrait aussi renommer le ticket, c'est pas du
versionning dont on parle mais d'historicisation, le versionning ça
serait plutôt ce que veut Thomas, qui pourrait d'ailleurs faire
l'objet d'un autre ticket parce que c'est intéressant.

J'ai pas de problème avec le fait que tu renommes le truc (même si en ce
qui me concerne le besoin d'un "vrai" versionning m'échappe)

Benjamin Dauvergne a écrit :

Comme j'aime bien ne pas être d'accord pour moi la bonne solution c'est la conservation automatique d'un historique juste avec des dates [...]

Cette possibilité était dans ma première question, ça me va bien qu'elle soit reconsidérée. Tu offrirais quoi comme réponse à "Sinon ça me semble compliqué à gérer, trop de versions." ?

À noter que je ne reprends explicitement pas la question de l'implémentation, ce qui m'intéresse c'est de d'abord définir la fonctionnalité.

(Parce qu'en terme d'implémentation, après, on peut très bien tout enregistrer et que la fonctionnalité revienne à "nommer" une révision, et que l'interface n'affiche que celles-ci. En se donnant ainsi la marge pour d'autres évolutions, type "annuler").

Frédéric Péters a écrit :

Benjamin Dauvergne a écrit :

Comme j'aime bien ne pas être d'accord pour moi la bonne solution c'est la conservation automatique d'un historique juste avec des dates [...]

Cette possibilité était dans ma première question, ça me va bien qu'elle soit reconsidérée. Tu offrirais quoi comme réponse à "Sinon ça me semble compliqué à gérer, trop de versions." ?

Je compresserai l'affichage de l'historique en affichant éventuellement que toutes les fins de période contenant plus d'une modifications par quart d'heure, avec possibilité de déplier pour voir le détail. Donc tu bosses deux fois x heures intensément (donc avec des modifications espacés de moins d'1/4 d'heure) sur un formulaire le lundi et le mardi, ça n'affiche que trois lignes dans l'historique, les versions après la dernière modification du lundi et du mardi et la version actuelle; mais on peut regarder à l'intérieur si on veut. À coté de chaque ligne je mettrai la quantité de lignes réelles d'historique que ça représente:

• Lundi 12 juin 8h32 17 modifications [+] * Mardi 13 juin 11h40 11 modifications [+]

Quand je parlai d'implémentation c'était en fait pour dire que ça pouvait servir aussi d'historique global des actions sur la plateforme; je sais qu'on a déjà les logs mais là ce serait plus fin et ça ne concernerait que la configuration. Stocker en dehors du formulaire ça a aussi l'intérêt de ne pas alourdir le fonctionnement normal de l'application seulement la partie création des formulaires. Un formulaire d'1ko avec 1000 lignes d'historique ça va faire déjà 1Mo à pickler/dépickler à chaque utilisation du formulaire.

Pierre Cros a écrit :

Comme j'aime bien ne pas être d'accord

Le problème n'est pas que tu sois pas d'accord mais que tu raisonnes
sans te figurer le besoin d'utilisateurs qui sont très éloignés de tes
propres pratiques, et auquel je suis pour ma part directement confronté.

Je suis utilisateur aussi, il est vrai pas tellement de w.c.s mais je ne pense pas que ça y fasse grand chose; la présence d'une fonction « Undo » automatique m'est toujours d'un grand secours. J'ai remarqué qu'elle l'était pour tous les gens que j'observe autour de moi, et des ergonomes très bien le pensent aussi par exemple http://fr.wikipedia.org/wiki/Jef_Raskin pour qui toutes les boites de dialogue de confirmation c'est le mal pourvu qu'on puisse défaire ce qu'on a fait.

Je fabrique des formulaires, je ne suis pas informaticien, chaque fois
que je déplace un champs, une version est créée dans l'historique, je
m'y perds totalement, je ne sais plus quelle version correspond à quoi.

Si elles s'appellent 1, 2, 3, 4, ... je te comprends mais si elles s'appellent « vendredi 7 mars 22:30 » puis « lundi 10 mars 10:11 » tu vois bien que la version du vendredi c'est celle de la semaine dernière, quand à la navigation dans un historique un peu trop chargé je donne une solution dans un autre message répondant à Fred.

Et non avoir une liste des modifs à côté ne va pas beaucoup m'aider : il
faudrait que je lise ces listes, ce qu'assurément je ne vais pas faire,
préférant cliquer partout.

Les listes de modif. c'est moins pour aider à défaire une connerie, pour ça les dates suffisent, que pour aider à pointer les gens du doigt à la « git blame ». Maintenant c'est un peu chiant à faire partout et la fonctionnalité peut très bien s'en passer.

Je n'ai rien contre le fait de pouvoir nommer certaines versions en plus genre 'v1', 'v2', ça peut d'ailleurs servir pour le versionning souhaité par Thomas si on joignait l'historique aux exports. Mais je ne pense pas que cela puisse servir de base pour cette fonctionnalité, la base ça devrait être la journalisation systématique des nouvelles versions.

Benjamin Dauvergne a écrit :

• Lundi 12 juin 8h32 17 modifications [+]
• Mardi 13 juin 11h40 11 modifications [+]

Pour un exemple réel, j'ai tiré des logs apache les POST sur un formulaire (pris vraiment au hasard, c'est /forms/93 de Vandœuvre), le résultat c'est :

19/May/2014 14:20 (1 modif)
16/Apr/2014 14:42 (2 modifs)
12/Mar/2014 11:41 (1 modif)
12/Dec/2013 10:12 (1 modif)
04/Dec/2013 10:06 (38 modifs)
19/Nov/2013 11:44 (3 modifs)
23/Oct/2013 14:52 (7 modifs)
14/Oct/2013 11:36 (1 modif)
07/Oct/2013 14:21 (1 modif)
18/Sep/2013 15:40 (1 modif)
28/Jun/2013 11:21 (3 modifs)
10/Jun/2013 16:15 (1 modif)

J'essaierai de faire une recherche/analyse plus systématique à un autre moment.

Quand je parlais d'implémentation [...]

Ce qui m'intéresse c'est de d'abord définir la fonctionnalité, et d'éviter de trop mêler les questions d'implémentation ici, en partie aussi pour ne pas risquer un ticket avec trois conversations parallèles. (et la méta-discussion sur ce sujet, laissons-la aller ailleurs)

Le vendredi 13 juin 2014 à 20:59 +0200, redmine@entrouvert.com a écrit :

La demande #4960 a été mise à jour par Benjamin Dauvergne.
Je suis utilisateur aussi

Absolument pas représentatif comme je l'écrivais, négligeable en somme.

il est vrai pas tellement de w.c.s mais je ne pense pas que ça y fasse
grand chose; la présence d'une fonction « Undo » automatique m'est
toujours d'un grand secours. J'ai remarqué qu'elle l'était pour tous
les gens que j'observe autour de moi, et des ergonomes très bien le
pensent aussi par exemple http://fr.wikipedia.org/wiki/Jef_Raskin pour
qui toutes les boites de dialogue de confirmation c'est le mal pourvu
qu'on puisse défaire ce qu'on a fait.

Je vais pas aller sur un débat qui n'a rien à voir avec mon ticket
initial.

Si elles s'appellent 1, 2, 3, 4, ... je te comprends mais si elles
s'appellent « vendredi 7 mars 22:30 » puis « lundi 10 mars 10:11 » tu
vois bien que la version du vendredi c'est celle de la semaine
dernière, quand à la navigation dans un historique un peu trop chargé
je donne une solution dans un autre message répondant à Fred.

Sauf que lundi à 12h10 j'ai modifié ce que j'avais fait à 12H09 (j'ai
déplacé un champ) qui était pourtant correct et à 12h11 j'ai remis le
champs à sa place originale. à 12H30 je sais déjà plus du tout ce que
j'avais fait. Avec une sauvegarde automatique, j'ai facilement 30 ou 40
versions dans la journée, voire plus, ingérable.

S'il te plait, t'as plein des taf sur des domaines que tu connais alors
ne vient pas ralentir les choses sur des domaines que tu ne connais pas.

• on fait revenir un formulaire en arrière et que l'on perde le paramétrage de ses sources de données qui ont évoluées entre temps.
• on fait revenir un workflow en arrière pour avoir le comportement désiré avec une démarche, mais on oublie de vérifier les autres démarches qui l'utilisent également.

Voici ce que je propose :

Historique¶

Il s'agit de logs dédiées aux modifications des objets wcs gérés par le ZIP d'import/export : formulaires, worflows, catégories, paramètres, sources de données et webservices. L'historique serait commun à tous ces objets (ce qui n'empêche pas de filtrer pour n'afficher que les modifications effectués sur le formulaire X).
L'historique serait inclus dans le ZIP d'import/export.

Snapshots¶

Il s'agit de fournir une liste des versions sauvegardées de l'ensemble de la configuration wcs. Les clichés englobent l'ensemble des objets wcs gérés par le ZIP d'import/export : formulaires, worflows, catégories, paramètres, sources de données, webservices et historique.
Les clichés sont gérés de façon séquentielle : si on crée des clichés A puis B puis C, l'affichage sera le même que si l'on avait créé C après être revenu sur A.

A
B
C

A
+ B
+ C

Merci d'ouvrir immédiatement au moins un nouveau ticket pour la partie journal (ou deux et fermer celui là, il y a déjà 21 commentaires :) ). Éventuellement en réouvrant #21524.

Merci d'ouvrir immédiatement au moins un nouveau ticket pour la partie journal (ou deux ...

• Historique (#36506)
• Clichés (#36507)

Voilà dans la branche, qui vient après #45796 et #45924 et #45919,

• 57dd0ab84 general: add snapshot objects (#4960)

Un objet avec comme attributs l'objet lié (object_type & object_id), l'heure, l'usager à l'origine de la modif, le commentaire associé, la sérialisation de l'objet sur le moment et un libellé pour pouvoir nommer le snapshot.

Dans la classe une méthode pour enregistrer les infos, et l'appel à celle-ci dans les .store() des différents objets :

+        if get_publisher().snapshot_class:
+            get_publisher().snapshot_class.snap(instance=self, comment=comment)

Côté différents objets c'est formulaires et worflows comme dans le sujet du ticket mais aussi modèles de fiche et blocs de champs et sources de données et appels webservice.

4e4a6f921 general: update .store() calls with comments (#4960)

Un tour des différents appels à .store() pour y inclure un commentaire automatique, genre :

-        self.objectdef.store()
+        self.objectdef.store(comment=_('Change in order of fields'))

fc742b7e9 backoffice: add history/ paths to list snapshots (#4960)

Un premier bout d'UI, simplement pour un objet lister les différents snapshots existants, avec le js pour grouper pour afficher par défaut un seul snapshot par jour.

1dea14d20 backoffice: add restore/export snapshots (#4960)

Les fonctionnalités pour exporter un snapshot (je l'avais fait parce que trivial, je me suis demandé si c'était bien utile, je l'ai conservé) et pour restaurer un snapshot, à la restauration deux options : soit en tant que nouvel objet (équivalent à exporter/importer), soit en écrasant l'objet (avec toute une série de risques genre si on restaure une version avec moins de champs, le contenu des champs retirés est bien sûr supprimé).

1c50dcb19 backoffice: add History links in sidebars (#4960)

Un peu plus haut j'ajoutais cetta page, voici les liens permettant d'y aller, ça veut aussi dire déplacer les actions en barre latérale pour être cohérent là-dessus, genre les blocs de champs avaient "export" en bouton en haut, alors que les formulaires/workflows l'avaient en barre latérale, comme tout ne peut pas tenir en boutons principaux, j'y laisse une uniquement les actions d'édition non destructive (genre éditer, ou changer le titre, mais pas supprimer (destructif) ni exporter (pas de l'édition).

edea38008 backoffice: add possibility to open snapshots (#4960)

Depuis la liste des snapshots possibilité d'entrer dedans pour en explorer le contenu, c'est là qu'intervient #45924 pour permettre la navigation en lecture seule.

f683f1c6f backoffice: add link to tag/save snapshot (#4960)

Ajout de la possibilité de prendre/nommer un snapshot, pour permettre d'identifier précisément un moment, j'imagine que ça donnera de noms genre "avant intégration webservice". J'imagine aussi qu'il y aura souhait à un moment de retirer ces snapshots nommés, ça sera plus tard. J'imagine aussi la possibilité lors d'un export global depuis les paramètres de dire "et prendre un snapshot de tout en ce moment", avec un libellé comme "export pour la mise en prod".

De manière générale j'aimerais laisser ce ticket à ceci et que les évolutions suivent dans de futurs tickets.

Quelques petites remarques à l'usage :

• Ça marche super bien.
• Le fils d'Ariane pointe dans le vide (history vs snapshots) :
  

    diff --git a/wcs/backoffice/snapshots.py b/wcs/backoffice/snapshots.py
    @@ -36,3 +36,3 @@ class SnapshotsDirectory(Directory):
         def _q_traverse(self, path):
    -        get_response().breadcrumb.append(('snapshots/', _('History')))
    +        get_response().breadcrumb.append(('history/', _('History')))
             return super()._q_traverse(path)
  

• Le bouton "ouvrir la page du workflow" (la flèche oblique) sur les snapshots des fiches et des formulaires pointe dans le vide.
  exemple : https://wcs.dev.publik.love/backoffice/forms/1/history/workflows/1/

• Il ne faudrait plus afficher le warning qui permet d'activer le formulaire quand on "édite" les champs de son snapshot
  (sinon ça plante sur l'assert qui défend la fonction store()).

• On n'a pas accès aux paramètres (via "Modifier") des appels webservices et des sources de données depuis leurs snapshots
  (mais j'imagine que dans un premier temps c'est voulu).

On n'a pas accès aux paramètres (via "Modifier") des appels webservices et des sources de données depuis leurs snapshots
(mais j'imagine que dans un premier temps c'est voulu).

Toutes les informations sont normalement reprises sur la page de visualisation. Tu vois manquer quoi ?

Rebasé (particulièrement nécessaire pour l'affichage des appels webservices, migrés vers un template) et adapté selon tes remarques.

Toutes les informations sont normalement reprises sur la page de visualisation. Tu vois manquer quoi ?

rien, j'ai juste manqué une occasion de me taire.

Concernant la flèche oblique "Ouvrir la page du workflow",
il y a encore un pépin avec les formulaires où il y a un '/' en trop à la fin de l'URL,
et aussi avec les fiches (ci-dessous j'ai corigé en recopiant le code des formulaires).

diff --git a/wcs/admin/forms.py b/wcs/admin/forms.py
index 30817973..03b38503 100644
--- a/wcs/admin/forms.py
+++ b/wcs/admin/forms.py
@@ -462,3 +462,3 @@ class FormDefPage(Directory):
                 '</a>'
-                '<a class="extra-link" title="%(title)s" href="%(workflow_url)s/">↗</a>'
+                '<a class="extra-link" title="%(title)s" href="%(workflow_url)s">↗</a>'
                 '</li>' % {
diff --git a/wcs/backoffice/cards.py b/wcs/backoffice/cards.py
index b33c245d..487bff4a 100644
--- a/wcs/backoffice/cards.py
+++ b/wcs/backoffice/cards.py
@@ -99,3 +99,3 @@ class CardDefPage(FormDefPage):
                 '</a>'
-                '<a class="extra-link" title="%(title)s" href="../../workflows/%(workflow_id)s/">↗</a>'
+                '<a class="extra-link" title="%(title)s" href="%(workflow_url)s">↗</a>'
                 '</li>' % {
@@ -104,3 +104,3 @@ class CardDefPage(FormDefPage):
                           'title': _('Open workflow page'),
-                          'workflow_id': self.formdef.workflow.id,
+                          'workflow_url': self.formdef.workflow.get_admin_url(),
                           'current_value': self.formdef.workflow.name or '-'})

Ensuite, je n'ai plus rien à ajouter et je serais d'avis de valider.
Dis-moi si tu veux que ça passe maintenant, ou si on attend un autre relecteur.

(j'ai poussé une branche avec ces modifs)