Produits Entr'ouvert » Passerelle

+        return zeep.Client(urlparse.urljoin(self.base_url, wsdl_name), wsse=wsse)

Plutôt utiliser self.soap_client

Relectures bienvenue sur la branche: https://git.entrouvert.org/passerelle.git/?h=wip%2F47058-maelis-initial-connector.

Ma première relecture :

Sur les calculs de « school_year = timezone.now().year » on peut déjà imaginer que l'année change plutôt au 31 juillet. C'est à dire : si on est après le 31 juillet, c'est « timezone.now().year », sinon c'est « timezone.now().year - 1 ».

Fonctionnement je pense qu'il manque un endpoint children_info qui renvoie la liste des enfants.

Question : sur "link", je vois dans les tests que leur truc renvoie une 500 si le mot de passe reçu est mauvais... sûr ça ne va rien déclencher chez nous, pas de trace à cause de notre requests ? En fait, c'est sûr que ça fait une 500 ? Ça me parait étrange, je ne pensais pas que SOAP faisait ça.

Thomas Noël a écrit :

Question : sur "link", je vois dans les tests que leur truc renvoie une 500 si le mot de passe reçu est mauvais... sûr ça ne va rien déclencher chez nous, pas de trace à cause de notre requests ? En fait, c'est sûr que ça fait une 500 ? Ça me parait étrange, je ne pensais pas que SOAP faisait ça.

C'est moche mais oui c'est le fonctionnement obligatoire de SOAP 1.1 quand il retourne une soap:Fault¹.

¹ https://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529 https://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Ref477795995

• pour la 500 effectivement ça pourrait être mieux de passer par httmock (je vais finir par en faire un poster).

• +# Copyright (C) 2019 Entr'ouvert
  

• « E16 : Le code postal est obligatoire » j'ai l'impression qu'ils font l'effort de coder toutes leurs erreurs ça pourrait être bien de l'extraire quand on peut et de leur demander la liste des codes, voir ce qu'on peut en faire.

• +            link, created = Link.objects.get_or_create(
  +                resource=self, name_id=NameID)
  +            link.family_id = r.number

  utiliser atomic() (les appels machin_or_create() + save() ne fonctionnent pas comme on s'y attend sans atomic) ou update_or_create()

Branche à jour avec calcul de l'année scolaire, ajout du endpoint "children-info" et usage de update_or_create.

Je ne vois pas trop ce qu'on peut faire des codes d'erreur, mais je demande la liste.

From: Laurent Barbareau <laurent.barbareau@sigec.fr>

Bonjour,
On n'a qu'une liste globale des messages d'erreur donc c'est un peu compliqué pour fournir une liste pertinente par rapport aux méthodes utilisées.
Je pense qu'il va falloir faire sans, désolé.

Si tu hérites aussi de HTTPResource (en plus de BaseResource) je pense que tu gagnes automagiquement la gestion du login/pass au niveau du transport (ainsi que certif, etc). C'est à tester en tout cas.

Le login/mdp servent à l'authentification WSSE: https://docs.python-zeep.org/en/master/wsse.html et non HTTP-Basic.

Serghei Mihai a écrit :

Le login/mdp servent à l'authentification WSSE: https://docs.python-zeep.org/en/master/wsse.html et non HTTP-Basic.

SOAP, chaque jour une découverte :)

• Dans children et child_info peux remplacer les « family_data.get('childInfoList', []) » par « family_data['childInfoList'] ».
• Pendant qu'on y pense, un truc gratuit et utile en support : ajoute des « created = models.DateTimeField(auto_now_add=True) » et « updated_at = models.DateTimeField(auto_now=True) » sur Link.

Done (branche à jour).

Serghei Mihai a écrit :

Done (branche à jour).

Pour « verbose_name = u'Maelis' » : plutôt 'Maélis' parce que bon.

Lors de get_link, le message APIError('Family not found', err_code='not-found') quand le lien n'existe pas, pourra preter à confusion lors du support : plutôt dire explicitement que l'utilisateur Publik n'est relié à aucune famille.

Dans get_invoices : Y'a un "assert name_id / if name_id" qui n'ont pas de sens (le name_id est obligatoire, sinon ça crashera sur le numDossier=family_id juste en dessous)

J'ai toujours un peu de mal avec les "django.utils.six" depuis qu'on est passé à Python3 ça ne me semble plus valable... je me trompe ?

Dans les moments où :

+        if not school_year:
+            # fallback to current year if not provided
+            school_year = get_default_school_year()

Dans "link", si r.number n'existe pas, il faudrait plutôt faire une APIError "family not found"

Sur child_info ou activity_list, nommer le paramètre childID au lieu de personID, ça sera plus clair. Il semble que Maélis fait la différence entre

update_coordinates demande un personID qui est celui d'un des deux responsables. Il faut donc ajouter un endpoint responsible_info (ou autre mot anglais qui va bien) qui renvoie une source de données id/text des rl1 et rl2 s'il est là.

activity_list je n'ai pas l'impression que ça renvoie une liste au sens Publik (id/text). Il faudrait sans doute que si.

Dernier truc : sur les tests, peux-tu xmllinter les XML afin qu'on puisse les "lire" ? Parce que mine de rien, ça fait aussi une bonne doc, ça aide à comprendre le code d'avoir ces exemples. Au passage, on est sûr qu'ils contiennent des données bidon ? Je vois des numéros de téléphones qui ont presque l'air vrais...

Quelques autres remarques concernant les impacts "fonctionnels"..

Dans les résultats des infos famille, on voit déjà qu'il y a des réferentiels genre <category>MONO</category> ou <situation>SEPA</situation>. Il faudra en avoir la liste pour avoir des affichages corrects dans les cellules combo et autres. C'est notre connecteur qui dira les choses en bon français, typiqement "category": "MONO" sera complété avec un "category_label": "famille monoparentale". Déjà vu sur Axel à Toulouse, c'est nécessaire... Allez, un futur ticket : "maélis: expliciter les codes reçus" -- où il faudra commencer par demander tous les listings à SIGEC.

• Fonctionnellement : on imagine éventuellement un formulaire+worfklow qui permettrait à une personne anonyme de se créer un compte Publik ET un appairage dans le même moment (en passant sous silence la notion d'appairage, comme un "vrai" portail famille). Pour ça, il faudrait un endpoint « check_family_password » qu'on appellerait avant de chercher à créer le compte Publik.
• Il faudrait aussi un endpoint qui puisse savoir si une famille est déjà appairée, et refuser éventuellement un double appairage (en fait ça pourrait être une option lors de l'appel à "link", genre "unique=1")

Il y aura une impossibilité fonctionnelle si on ne peut pas extraire une facture en dehors du NameID : impossible de faire payer une personne autre que l'usager Publik. A faire remonter au fonctionnel... (dans Maélis la notion de payeur semble mélangée à la notion de famille, bon, c'est vrai que c'est plus simple...).

Enfin, fonctionnellement, je me demande à quoi sert l'année en cours lors de la remontée de la famille. J'espère qu'au 1er aôut, lors du changement d'année scolaire, tout ne va pas disparaître... on verra. Question à poser à SIGEC en tout cas. D'une façon général ce truc de l'envoi d'une année va poser de gros soucis de calculs, pas faciles voire impossibles à faire dans combo et wcs. Il faudra plutôt avoir une option du genre "année=en-cours|prochaine", et savoir comment SIGEC gère la date de bascule et la date à partir de laquelle l'année prochaine est active. C'est un gros sujet sur la gestion de l'enfance & petite enfance.

Thomas Noël a écrit :

Pour « verbose_name = u'Maelis' » : plutôt 'Maélis' parce que bon.

Ok.

Lors de get_link, le message APIError('Family not found', err_code='not-found') quand le lien n'existe pas, pourra preter à confusion lors du support : plutôt dire explicitement que l'utilisateur Publik n'est relié à aucune famille.

Done.

Dans get_invoices : Y'a un "assert name_id / if name_id" qui n'ont pas de sens (le name_id est obligatoire, sinon ça crashera sur le numDossier=family_id juste en dessous)

Virés.

J'ai toujours un peu de mal avec les "django.utils.six" depuis qu'on est passé à Python3 ça ne me semble plus valable... je me trompe ?

J'ai repris bêtement ce qu'est fait dans les autres connecteurs, mais ça suffit en effet.

Dans les moments où :
[...]
on va envoyer une string si school_year est reçu (wcs n'envoie que des string), sinon un entier. Il faudrait vérifier ce que SOAP attend vraiment et envoyer le bon type.

zeep est magique. Il caste tout seul. J'ai mis à jour le test pour voir que ça passe.

Dans "link", si r.number n'existe pas, il faudrait plutôt faire une APIError "family not found"

Ok.

Sur child_info ou activity_list, nommer le paramètre childID au lieu de personID, ça sera plus clair. Il semble que Maélis fait la différence entre

Oui.

update_coordinates demande un personID qui est celui d'un des deux responsables. Il faut donc ajouter un endpoint responsible_info (ou autre mot anglais qui va bien) qui renvoie une source de données id/text des rl1 et rl2 s'il est là.

Je rajoute ça.

activity_list je n'ai pas l'impression que ça renvoie une liste au sens Publik (id/text). Il faudrait sans doute que si.

Done.

Dernier truc : sur les tests, peux-tu xmllinter les XML afin qu'on puisse les "lire" ? Parce que mine de rien, ça fait aussi une bonne doc, ça aide à comprendre le code d'avoir ces exemples. Au passage, on est sûr qu'ils contiennent des données bidon ? Je vois des numéros de téléphones qui ont presque l'air vrais...

Fichiers xmlintés. De quelques tests j'ai l'impression que les RL sont les employés de SIGEC, probablement avec leur vraies coordonnées. Je vais les "faker".

Branche à jour.

Branche à jour avec les mobiles dans les réponses bidouillés et endpoint pour les infos sur les résponsables légaux (j'ai appelé "guardians").