Inclure la commune de l'usager responsable dans l'export

[yaf]

Dans l'export Excel, nous n'avons pas l'information sur la commune.

Une ligne par rendez-vous;
plusieurs usagers par rendez-vous.

Nous allons donc sélectionner la commune de l'usager responsable.
S'il y a plusieurs usagers responsables ou plusieurs usagers adultes (avec commune), nous prendrons le premier.

Il sera important de trouver un titre qui évoque le trou dans la raquette (commune du responsable ou premier usager ?)

[yaf]

https://forum.rdv-solidarites.fr/t/ajouter-le-detail-des-usagers-dans-les-exports-de-rdvs/124

[yaf]

Comment extraire la commune de l'adresse ?
Est-ce que l'on ajoute l'adresse entière ?

[yaf]

Dans un premier temps, nous pourrions essayer d'extraire le code postal du champ adresse.

[adipasquale]

je serais quand même plus d'avis d'essayer de faire le "vrai" fix et stocker les infos de l'adresse lors des recherches usagers. ça implique de :

• rajouter une colonne address_ban_id sur les users (et les lieux ?)
• ballader ce ban_id depuis la premiere page de la recherche user jusqu'au bon formulaire apres le sign_in
• ecrire une migration qui essaie de remplir la data sur l'existant en utilisant l'API adresse

[yaf]

Je comprends pourquoi tu parles de cette partie, mais ça n'ajoutera pas la ville dans l'export j'ai l'impression 🤔

J'imagine que tu évoques ça, en plus, pour éviter, ou réduire, les adresses usagers vide ?

[adipasquale]

en effet tu as raison.
je voulais dire que ce qui me paraît important c'est de stocker les valeurs "exactes" d'adresses dans la db, pas juste une représentation textuelle. Le ban_id permet d'identifier uniquement et fiablement une adresse.

Une fois qu'on a stocké cet identifiant unique on peut augmenter à souhait la donne, par exemple via une requête à l'API adresse à la volée lors des exports. Peut-être que c'est trop sous optimisé et que ça ne coûte pas cher de rajouter un champ city_insee_code dans les tables contenant des adresses, pour éviter cette requête supplémentaire à la volée.

On peut aussi "hacker" en utilisant une seule colonne ban_id car la première partie des ban_id avant le _ sont des codes commune INSEE

(d'ailleurs en passant encore je pense que c'est mieux d'exporter des codes INSEE plutôt que des codes postaux)

[yaf]

Je ne pense pas que ça corresponde à la demande le code INSEE :D Ces codes sont assez peu compréhensible :)

J'ai aussi en tête que tout baser sur la BAN ça pose un gros problème pour les adresses qui n'existent pas (encore). Et nous savons qu'aujourd'hui, il y a des contournements de l'application pour s'en sortir.

Après, ça reste pertinent de stoker le BAN_ID, mais peut-être en plus d'une adresse qui aurait été saisi manuellement, dans une chaine.
Je ne sais pas comment se comporte le BAN_ID s'il y a une correction d'adresse ?

[github-actions]

Stale issue message