toulouse-maelis: accéder aux données nécessaires pour l'inscription extra-scolaire et loisir (#73648) #59
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/73648-parsifal-get-person-unit-info"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Nouveau endpoint pour accéder au WS getPersonUnitInfo.
tolulouse-maelis: accéder aux données nécessaires pour l'inscription extra-scolaire et loisir (#73648)to toulouse-maelis: accéder aux données nécessaires pour l'inscription extra-scolaire et loisir (#73648)2a43dc5db2
to6a5b1443d6
6a5b1443d6
to740ca7bfa0
740ca7bfa0
tofe647837dc
(rebase)
fe647837dc
to182740c37e
(rebase)
182740c37e
to0c0802568d
(rebase)
Pour info il y a déjà une notification quand la branche est poussée; ça ne me semble pas utile de les doubler.
0c0802568d
toe98331cb9a
e98331cb9a
toeb877622c0
@ -2419,0 +2438,4 @@
perm='can_access',
parameters={
'person_id': {'description': "Numéro du responsale légal ou de l'enfant"},
'activity_id': {'description': "Numéro de l'activités"},
activité, singulier.
@ -2419,0 +2470,4 @@
activity_id,
unit_id,
place_id,
ref_date=ref_date and ref_date.strftime(utils.json_date_format),
Il me semblerait plus opportun que l'adaptation au format soit effectuée dans la méthode appelée, plutôt qu'avoir à être répétée dans tous les appelants.
Il ne me semble pas que ça ait été compris; ci-dessus je notais que la gestion u format du paramètre ref_date aurait à gagner à être géré dans la méthode appelée (get_person_unit_info_raw). Dans la branche actualisée ça n'est toujours pas le cas, l'appelant (get_person_subscribing_info) contient toujours un code d'interprétation de ref_date (curieusement encore plus long qu'avant).
Oui, j'ai anticipé la factorisation de l'appel au WS maélis, ce qui n'était pas une bonne idée. Il n'y a plus d'appelé.
(Concernant la taille du code d'interprétation de ref_date, voir la réponse au commentaire ci-dessous.)
@ -5285,0 +5379,4 @@
resp = app.get(url, params=params, status=400)
assert resp.json['err'] == 1
assert resp.json['err_desc'] == 'invalid value for parameter "ref_date (YYYY-MM-DD expected)"'
Il est bien plus facile depuis w.c.s. de passer un paramètre vide que de ne pas passer de paramètre, pourquoi ce comportement contraire ?
C'était pour utiliser le type date sur ce paramètre pour ne pas à avoir à gérer les cas d'erreur, mais c'était une mauvaise idée, parce ce type ne fonctionne pas avec un paramètre optionnel.
C'est #72641
Ce n'est pas le format attendu pour les messages de commit; ça devrait être "... add new ...".
eb877622c0
to23040d4d37
23040d4d37
to907141d026
Remarques prises en compte.
907141d026
to7501fdd28d
7501fdd28d
to4aa1291e1f
Mes 50 cents: s/subscribing/subscription/
4aa1291e1f
tobc32bb2f54
Le mot français "inscription" (un sujet) donne en anglais "subscription" (noun).
@ -499,0 +508,4 @@
'dateRef': ref_date,
}
response = self.call('Activity', 'getPersonUnitInfo', getPersonUnitInfoRequestBean=params)
data = serialize_object(response)
J'aurais fait directement:
return serialize_object(response)
oui, c'est #74084.
(tu as vraiment écris ce commentaire il y a une semaine ?)
edit: d'après le mail reçu, non : Date: Thu, 02 Feb 2023 10:52:58 +0100)
bc32bb2f54
to76d8e2e7be