Produits Entr'ouvert » w.c.s.

pour discussion

(correspond à la branche wip/62800-formdata-snapshot-bis - version sans table dédiée)

0001: juste un split de tests
0002: les ContentSnapshotPart à la création et à la modification d'un form/carddata
0003: fichiers inutilisés & historisation (pas très sûre de moi là)

Rien de particulier pour l'anonymisation pour le moment

nouvelle version de 0002, pour stocker aussi formdef_type et formdef_id dans ContentSnapshotPart, parce que ça peut servir.

Toutes les parts sont supprimées (2 fois même, on sait jamais), dans l'hypothèse où on ne fait pas de table dédiée, je laisse comme ça, ou je garde les SnapshotContentPart en anonymisant ce qui doit l'être ?

Je dirai qu'arriver à l'anonymisation l'historique des données du formulaire n'ont plus beaucoup d'intérêt, donc non on vire tout.

• 0002:

  class ContentSnapshotPart(EvolutionPart):
      def __init__(self, formdata, old_data):
          self.formdef_type = formdata.formdef.xml_root_node
          self.formdef_id = formdata.formdef.id
          self.old_data = old_data
          self.new_data = copy.deepcopy(formdata.data)
  

Est-ce qu'on ne réduirait pas un poil ? Genre ne garder que ce qui a changé :

- self.old_data = old_data
- self.new_data = copy.deepcopy(formdata.data)
+ self.new_data = copy.deepcopy({key: value for key, value in formdata.data.items() if value != old_data.get(key)})

• 0003: il me semble qu'il y manque le cas des champs fichiers dans les blocs qui est géré un peu plus haut pour formdata.data en commençant avec cette ligne :
  

              elif isinstance(field_data, dict) and isinstance(field_data.get('data'), list):
  

0003: il me semble qu'il y manque le cas des champs fichiers dans les blocs qui est géré un peu plus haut pour formdata.data en commençant avec cette ligne :

exact, merci

Est-ce qu'on ne réduirait pas un poil ?

C'est quand même super pratique d'avoir un avant/après complet sur une part:
- pour afficher les changements dans l'historique d'une demande, il n'y a qu'à définir une méthode view sur ContentSnapshotPart, on a tout ce qu'il faut pour faire un diff. Sinon, pour chaque part, il faudrait loader les part précédentes, construire un data complet en compilant tout ça, puis vérifier les changements.
- pour récupérer les données à un instant t, il suffit de récupérer la part juste avant t, on a les données complètes dessus. Sinon, pareil, faut récupérer toutes les parts précédentes, etc.

Dans la modification à l'action edit_carddata pourquoi est-il nécessaire de créer une nouvelle evolution ce qui n'est pas le cas pour backoffice_field, l'édition en front ou la mise à jour par l'API ?

Dans la modification à l'action edit_carddata pourquoi est-il nécessaire de créer une nouvelle evolution ce qui n'est pas le cas pour backoffice_field, l'édition en front ou la mise à jour par l'API ?

Parce que edit_carddata est lancé par une action sur un autre workflow que celui de la fiche modifiée. Cette action ajoute bien une evolution et une part sur la demande initiale, mais rien sur la fiche modifiée. Pour avoir le bon horodatage il faut ajouter une evolution, et pour comprendre d'où viennent les modifs il y a #70000.

backoffice_field: on est dans un perform_workflow, qui gère déjà les evolutions et les ActionsTracingEvolutionPart et l'horodatage des actions.
édition en front: idem, on passe par un perform_workflow
api: juste avant l'ajout de la part, on a un perform_workflow.
Il me semble qu'on est bon.

En tout cas les tests ajoutés sur evolution et parts dans test_content_snapshots.py m'ont l'air plutôt cohérents, mais je veux bien une autre relecture pour confirmer.

Ok.

Après discussion avec Fred: ajout d'une datetime sur ContentSnapshotPart, pour avoir la bonne date (avec tz) même si la part est posée sur la mauvaise evolution

Toujours ok.

commit b6b7203358a355a950bde26deb96dd9166379b68
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Fri Oct 7 09:40:16 2022 +0200

    formdata: look at files in history when deleting unused files (#62800)

commit 5fc369a082124f334f5fcb609fe35417c2b31b08
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Sat Sep 24 18:43:55 2022 +0200

    formdata: store data history (#62800)

commit f293184fff301048fe9d21c5d552f5f1960ae080
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date:   Sat Sep 24 18:35:59 2022 +0200

    misc: split workflow tests