Produits Entr'ouvert » w.c.s.

• Il faudrait par exemple trouver le moyen d'indiquer les clichés qui "pointent" sur chaque ligne de logs.
  (de façon analogue aux tags qui sont incrustés dans le 'git log')
• De l'autre côté (dans l'IHM des clichés), il faudrait par exemple trouver le moyen d'afficher (ou de basculer vers) les logs du cliché.

Nicolas Roche a écrit :

En terme d'interface, clichés (versions) et historiques doivent être tout à fait liés :

• Il faudrait par exemple trouver le moyen d'indiquer les clichés qui "pointent" sur chaque ligne de logs.
  (de façon analogue aux tags qui sont incrustés dans le 'git log')
• De l'autre côté (dans l'IHM des clichés), il faudrait par exemple trouver le moyen d'afficher (ou de basculer vers) les logs du cliché.

Me semble que le plus simple c'est de stocker les logs avec le cliché, ça rejoint le besoin d'exporter les logs dans les exports, il suffira de mettre une ligne dans le log chaque fois qu'un cliché est pris pour avoir des marqueurs pour faire correspondre logs et clichés. Quand on importe un cliché on écrase les logs et le pickle du formdef/worflow avec ce qu'il y a dans l'export.

creuser l'idée d'avoir des objets "FormDefSnapshot" qui sont en fait des FormDef

À creuser... en l'état, 0001, "il y aura un objet par ancienne version, il sera créé automatiquement lorsqu'un formdef sera enregistré", peut tout à fait être un morceau d'un plan technique, mais oui, il faudrait creuser, avoir davantage pour voir vraiment la direction.

On est donc là sur un enregistrement automatique, mais dans une vue de l'historique, ce choix va créer une longue liste de versions connues uniquement par une date/heure. Est-il pertinent de pointer qu'il faudrait l'accompagner de quelques mots ? C'est-à-dire qu'une part du plan devrait être de passer sur les endroits où .store() est appelé pour y ajouter quelques mots de description, ex: "changement du workflow associé", ou "modification du champ Untel".

Et ce point qui semble un détail d'UI amène derrière quand même la question du stockage, parce qu'on va vouloir afficher la liste des versions, et peut-être qu'on peut se dire qu'ouvrir 50 pickles, c'est pas top, peut-être qu'on serait mieux à dire que les versions c'est postgresql uniquement, et travailler sur une table snaphots (object_type, object_id, timestamp, message, xml_export).

_~~

0002, "mettre l'historique des formulaires au premier niveau de navigation", est une autre part du plan technique, que je ne pense pas appropriée; pour moi l'historique d'un formulaire doit être au niveau sous le formulaire, comme dans la descrpition du ticket.

_~~

(mais c'est bien de déjà "finir" les formdef, dans un premier temps, à mon avis).

Ça me va très bien de commencer par les formdefs.

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

On est donc là sur un enregistrement automatique, mais dans une vue de l'historique, ce choix va créer une longue liste de versions connues uniquement par une date/heure. Est-il pertinent de pointer qu'il faudrait l'accompagner de quelques mots ? C'est-à-dire qu'une part du plan devrait être de passer sur les endroits où .store() est appelé pour y ajouter quelques mots de description, ex: "changement du workflow associé", ou "modification du champ Untel".

Il est prévu un algo de comparaison entre deux formdefs (reprendre/étendre celui qui gère l'écrasement par import). On peut imaginer que cet algo saura faire le calcul lors de l'enregistrement d'un snapshot (entre lui et son précédent) et que cette information sera enregistrée, et donc affichée dans le listing, oui. On aurait donc pour un formulaire donné une liste de ses clichés

• 10/10/2019 10h34 « ajout d'un champ bidule » par Tarte Enpion
• 10/10/2019 10h30 « ajout d'un champ chose » par Tarte Enpion
• 09/10/2019 16h01 « changement du workflow » par Tarte Enpion

Evidemment si on supprime un snapshot (par exemple le second) on perd l'info sur l'ajout du champ "chose". Il pourrait être recalculé... Ou alors on interdit de supprimer un snapshot, on retire juste, éventuellement, le XML stocké qui bouffe de la place (cf infra).

Et ce point qui semble un détail d'UI amène derrière quand même la question du stockage, parce qu'on va vouloir afficher la liste des versions, et peut-être qu'on peut se dire qu'ouvrir 50 pickles, c'est pas top, peut-être qu'on serait mieux à dire que les versions c'est postgresql uniquement, et travailler sur une table snaphots (object_type, object_id, timestamp, message, xml_export).

Yep. Et ajouter un chaînage "previous" qui pointe vers le snapshot précédent.

0002, "mettre l'historique des formulaires au premier niveau de navigation", est une autre part du plan technique, que je ne pense pas appropriée; pour moi l'historique d'un formulaire doit être au niveau sous le formulaire, comme dans la descrpition du ticket.

L'idée de 0002 c'était pour moi de "convaincre" Nicolas qu'en ayant un objet FormDefSnapshot on gagnait déjà beaucoup d'UI. Pas grand chose de plus. Effectivement ça serait plus des pages /forms/58/snapshots/ (liste des clichés) et /forms/58/snapshots/32/ (affichage d'un cliché donné), etc.

Bref, il s'agissait ici d'aider Nicolas à chiffrer, et pour cela de creuser un peu une piste. Je pense que ce qu'il a fait, et ce début de discussion, suffit à montrer que c'est la voie à suivre.

• écrire un système de comparaison de deux formdef, compare(formdef1, formdef2) (3 jours)
  • qui renvoie une liste des modifs (modifs des options, champs ajoutés, champs supprimés, champs modifiés, ...) et un résumé en une ligne
• utilisation de ce système dans le processus d'overwrite (écraser avec un import) (2 jours)
• création d'un objet FormDefSnapshot dont le stockage se fait dans une table SQL (4 jours)
• interface de présentation des clichés liés à un formdef (1 jour)
• interface de présentation d'un cliché donné (2 jours)
• outil de restauration d'un cliché, reprenant ce qui a été dessiné dans "écraser avec un import" (exactement le même principe) (2 jours)

J'ai mis mon chiffrage "doigt mouillé" entre parenthèses, qui tape sur 14 jours... Tout est encore discutable.

Je ne voulais pas allonger ce ticket (à 14 commentaires j'ai déjà envie de le rejeter), inciter à faire un pad pour poser le fonctionnel et plan technique envisagé; Nicolas a commencé dans https://pad.libre-entreprise.org/p/eo-snapshots