Met en cohérence le calcul par dotation pour /commune et /calculate
- Correction d'un crash.
- Détails :
- Corrige une erreur de type sur requête à
/communesuite à une évolution de/calculate- Incohérence introduite en fin de MR à l'origine de la v2.0.0
- Aligne le type de chaque commune type de
UiDisplayedImpacts.casTypesde/calculatesurApiCommuneResponsede/commune
- Corrige une erreur de type sur requête à
Contexte
Régression détectée en local par une erreur "commune non suscriptable" :
curl -X POST http://127.0.0.1:8000/commune -H 'Content-Type: application/json' -d @init_commune_denestanville.json | jqEt en pré-prod par la réponse :
{
"nomCommune": "string",
"codeInseeCommune": "string",
"codeInseeDepartement": "string",
"nombreHabitants": 0,
"potentielFinancierParHabitant": 0,
"summaryDotations": [
{
"dotation": "string",
"eligible": true,
"montantDotation": 0
}
],
"error": "string"
}La source en est l'utilisation de la même méthode format_commune_impact pour /commune et /calculate mais avec des inputs typé différemment :
En développant /calculate, le traitement des résultats pour les cas types de communes a apporté un changement de syntaxe vers codeInseeCommune = str(commune["codeInseeCommune"]) mais pour /commune, commune étant du type ApiCommuneRequest ou ApiCommuneResponse, il n'est pas "suscriptable".
Inversement codeInseeCommune = str(commune.codeInseeCommune) ne fonctionnait pas pour /calculate car le type de casType était une list sans plus de précision et donc une liste de dictionnaires au final. On obtenait AttributeError: 'dict' object has no attribute 'codeInseeCommune'
Cette MR précise donc le type de UiDisplayedImpacts.casTypes: list[ApiCommuneResponse] sachant qu'il est identique pour la requête /calculate et pour la response. On choisit donc ApiCommuneResponse qui est le plus complet (et où les attributs propres à la response sont optionnels)