Produits Entr'ouvert » Zoo

Et donc, on a nouvel écran accessible via un nouveau bouton sur la vue des entités, cet écran affiche les derniers imports en cours, l'import se fait en deux temps et démarre par un clic sur le bouton "Nouvel import", ensuite on doit choisir l'application concernée et fournir un CSV.

Cela génère une nouvelle ligne dans le listing permettant de voir un pré-rapport d'import, la vue HTML du pré-rapport ne donne des indications que sur:

• les fédération à supprimer (action "DELETE")
• les fédération nouvelles (i.e. des fédération inconnus mais qui semble plus récente que le fichier d'import, donc on n'y touche pas) (action "NEW")
• les fédérations inconnue (les identifiants métiers qu'on ne retrouve pas dans le RSU) (action "UNKNOWN")

Ce pré-rapport est aussi disponible en fichier CSV, mais il est plus complet (on a en plus toutes les fédérations conservées, marquées de l'action "KEEP").

Après validation du rapport on peut passer à l'application de l'import via le bouton "Appliquer", cela donnera lieu à la création d'un deuxième rapport (en effet entre le premier chargement et l'application il peut y avoir des différences, différences qui seront visible en comparant les deux CSV par exemple).

Les fichiers CSV sont triés par les identifiants RSU, sauf pour les fédérations inconnues qui sont listées en fin de fichier.

0001: zoo_data: ajoute la construction d'un classpath pour une classe et pas seulement une instance (#21198)

• def get_classpath(cls, instance): comme l'instance peut aussi être une classe, on pourrait changer le nom ; ou plutôt simplement mettre un mini commentaire (# instance can be a class ; au niveau du if isinstance)... ou rien parce que "git blame" expliquera. Au choix.

0002: zoo_data: ajoute une méthode pour récupérer tous les jobs d'une classe d'action (#21198)

• ack

0003: zoo_data: toujours lier une action à son job (#21198)

• faut pas utiliser assert en dehors des tests
• mais ack quand même, je sais ton amour pour les asserts

0004: zoo_data: permettre à une application d'étendre les URLs d'admin des entités (#21198)

• ack

0005: zoo_data: ajoute des permissions génériques en vue d'extensions (#21198)

• petite erreur de copié collé, après action1 tu n'ajoutes que des "Can do action2 on entities"

0006: nanterre: BO pour la synchronisation des fédérations métiers (fixes #21198)

(enfin un vrai patch ☺)

• zoo/zoo_nanterre/synchronize_federations.py: dans SynchronizeFederationsImport::__init__ il y a :
  

  +        self.federations = []
  +        self.errors = []
  +        self.actions = []
  

  
  mais je pense qu'il faut ajouter ça aussi au début de SynchronizeFederationsImport::analyse() ; parce que celle-ci me semble pouvoir avoir lieu plusieurs fois (pourrait, un jour). Et, sans véritable importance cette fois, juste par réciprocité, ajouter dans le init :
  

  +        self.keep_count = 0
  +        self.new_count = 0
  +        self.delete_count = 0
  +        self.unknown_count = 0
  

• dans le apply, quand tu extraies la liste des effacements :
  

  +        for row in self.actions:
  +            entity_id, _, _, _, app_id, federation, action = row
  +            if action != 'DELETE':
  +                continue
  +            deletes[entity_id] = federation
  

  
  est-ce qu'il ne faudrait pas aussi filtrer uniquement si app_id == self.action.app_id ?

• si j'ai tout suivi, l'action NEW elle est jamais gérée ?

• dans SynchronizeFederationsAction::do , à mon avis pépin dans le bout ci-dessous, parce que le synchronize_federations_import.errors n'est pas géré par SynchronizeFederationsImport::analyze_and_report (selon ma lecture SynchronizeFederationsImport ne fait juste que self.errors=[] et jamais rien d'autre) :
  

  +    synchronize_federations_import = SynchronizeFederationsImport(self)
           ....
  +            synchronize_federations_import.analyze_and_report()
  +            if synchronize_federations_import.errors:  <-- ça sera toujours [] je crois bien
  +                return Job.STATE_UNRECOVERABLE_ERROR
  

• Job.create(self, do_later=not settings.DEBUG) va être génant parce qu'en preprod on a DEBUG = True. Plutôt un getattr(settings, 'NANTERRE_SYNCHRONIZE_NO_DELAY', False) ou quelque autre nom plus joli que tu trouverais.

• zoo_nanterre/templates/admin/index.html: sans doute que tu t'embêtes pour rien à faire des {% trans ... %} vu que y'a du français ailleurs
• c'est bien y'a pas d'assert, tu progresses
• zoo_nanterre/synchronize_federations.py: Copyright (C) 2016 alors qu'on est en 2018

Thomas Noël a écrit :

0001: zoo_data: ajoute la construction d'un classpath pour une classe et pas seulement une instance (#21198)

• def get_classpath(cls, instance): comme l'instance peut aussi être une classe, on pourrait changer le nom ; ou plutôt simplement mettre un mini commentaire (# instance can be a class ; au niveau du if isinstance)... ou rien parce que "git blame" expliquera. Au choix.

0002: zoo_data: ajoute une méthode pour récupérer tous les jobs d'une classe d'action (#21198)

• ack

0003: zoo_data: toujours lier une action à son job (#21198)

• faut pas utiliser assert en dehors des tests

Il faut distinguer l'utilisation d'assert pour de la gestion d'erreur, ça c'est mal et l'utilisation de assert pour du contrôle de pré-/post-condition/invariant i.e. des choses qui ne peuvent jamais arriver sauf erreur de codage. J'utilise assert comme on l'utilise en C (qui a le même comportement, en -O1 les assert sont virés).

• zoo/zoo_nanterre/synchronize_federations.py: dans SynchronizeFederationsImport::__init__ il y a :
  [...]
  mais je pense qu'il faut ajouter ça aussi au début de SynchronizeFederationsImport::analyse() ; parce que celle-ci me semble pouvoir avoir lieu plusieurs fois (pourrait, un jour). Et, sans véritable importance cette fois, juste par réciprocité, ajouter dans le init :

Oui tu as raison je vais même tout simplement déplacer cela dans analyze().

[...]

• dans le apply, quand tu extraies la liste des effacements :
  [...]
  est-ce qu'il ne faudrait pas aussi filtrer uniquement si app_id == self.action.app_id ?

En fait j'utilise la liste actions pour deux choses, générer mes rapports CSV et effectuer réellement la suppression des fédérations, dans ce dernier cas il n'y a que trois colonnes qui servent, rsu_id, federation et action.

• si j'ai tout suivi, l'action NEW elle est jamais gérée ?

Non c'est une valeur qui ne sert qu'au rapport, ça indique une fédération qui est plus récente que l'import (elle est plus grande que la plus grande valeur entière d'une fédération de l'import). L'idée c'est qu'ils ne se prennent pas trop le choux à bloquer toute l'application au moment d'un import parce qu'entre le temps T de l'export et le temps T+1 de son import de nouvelles fédérations auront pu être créé entre zoo et les applications métiers, qui étant absente de l'export seraient considérées comme devant être supprimées; bien sûr cela ne marche que dans la mesure ou les fédérations sont des entiers distribués de manière strictement incrémentale; ce qui semble être le cas (sauf pour saga, mais de notre coté on génère un code saga_tiers incrémental, on partira de ça plutôt).

• dans SynchronizeFederationsAction::do , à mon avis pépin dans le bout ci-dessous, parce que le synchronize_federations_import.errors n'est pas géré par SynchronizeFederationsImport::analyze_and_report (selon ma lecture SynchronizeFederationsImport ne fait juste que self.errors=[] et jamais rien d'autre) :
  [...]

Ouais je vais relire ça, en fait y a pas vraiment de cas d'erreur, au début je faisais des pseudos contrôles sur le fichier d'import, mais maintenant je lis juste ligne par ligne et si un truc ne martche pas ça fait juste une fédération inconnue.

• Job.create(self, do_later=not settings.DEBUG) va être génant parce qu'en preprod on a DEBUG = True. Plutôt un getattr(settings, 'NANTERRE_SYNCHRONIZE_NO_DELAY', False) ou quelque autre nom plus joli que tu trouverais.

Ok.

• zoo_nanterre/templates/admin/index.html: sans doute que tu t'embêtes pour rien à faire des {% trans ... %} vu que y'a du français ailleurs

C'est un template copié depuis django/contrib/admin/templates/admin/ donc c'est pas moi, je ne peux rien n'y faire l'admin django ne prévoit pas de moyen propre de surcharger sa page d'accueil, enfin on peut déclarer sa propre classe AdminSite et surcharger le chemin mais j'ai eu la flemme.

• c'est bien y'a pas d'assert, tu progresses
• zoo_nanterre/synchronize_federations.py: Copyright (C) 2016 alors qu'on est en 2018

Yep je corrige.

Ack

Je peux m'occuper de pousser et envoyer en préprod si tu veux.