(PC-30539)[BO] feat: make manual address edition compatible with new "Offer Address" model #12932
Conversation
prouzet
force-pushed
the
prouzet/pc-30539-oa-manual-address-in-bo
branch
2 times, most recently
from
d15f5c1
to
e5a56e7
Compare
| op.create_index( | ||
| "ix_complete_unique_address", | ||
| "address", | ||
| ["banId", "inseeCode", "street", "postalCode", "city", "latitude", "longitude"], |
There was a problem hiding this comment.
C'est une contrainte très forte encore plus sur des contraintes décimale. Je ne connais pas la fréquence de mise à jour de l'api adresse mais pour une petite différence ou approximation on se retrouvera avec des adresses différentes.
There was a problem hiding this comment.
Lorsque l'adresse provient de l'API Adresse, on a désormais isManualEdition à false, et c'est l'index ix_partial_unique_address_per_street_and_insee_code qui évite tout doublon sur les seuls champs street et postalCode. Ça ne change pas.
Ce nouvel index permet d'éviter les doublons complets de tous les champs, lors de l'utilisation de l'édition manuelle d'adresse dans le backoffice, qui ne valide pas forcément les résultats de l'API Adresse, ou les ajuste volontairement (ça peut être seulement un "bis" ajouté, l'ajustement de la latitude et longitude, un nom de ville qui précise un hameau, etc.).
Si un utilisateur du backoffice a saisi manuellement une petite différence, alors on doit la conserver dans une nouvelle entrée, car c'est le principe de l'édition manuelle : enregistrer ce qui a été saisi 🙂 .
There was a problem hiding this comment.
Autre solution : je peux ne pas ajouter cet index, et simplement dans le cas d'une édition manuelle, rechercher par un select s'il existe une entrée identique, et la retourner. C'était surtout pour garder le fonctionnement que vous aviez implémenté côté activation avec IntegrityError pour détecter les doublons, mais peut-être est-ce trop lourd avec cet index complet ?
There was a problem hiding this comment.
je crains surtout que coté api adresse certaines coordonnées changes de peu ( pour représenter une correction lors de la prise de mesure ou autre chose) et on se retrouve a ne pas pouvoir inserer cette adresse. Il y a déjà une exception qui gère ça. personnelement ca ne me choque pas tant que ça parce que ça restera très exceptionnel. pareil pour la correction manuelle on aura des "quasi doublon" mais pas sur toute la base
There was a problem hiding this comment.
Je ne comprends pas dans quel cas tu penses qu'on ne pourra pas insérer l'adresse.
Si les coordonnées changent de peu sur l'API Adresse, rien ne change dans le comportement que la squad activation a implémenté, car on aura l'IntegrityError sur votre index. Et ça ne mettra pas à jour, mais je n'ai pas changé le comportement.
api/src/pcapi/static/backoffice/js/addons/pc-postal-address-autocomplete.js
Outdated
Show resolved
Hide resolved
…"Offer Address" model
prouzet
force-pushed
the
prouzet/pc-30539-oa-manual-address-in-bo
branch
from
e5a56e7
to
48727a8
Compare
...api/alembic/versions/20240624T162701_e92c101b449f_add_is_manual_edition_column_to_address.py
Show resolved
Hide resolved
...0624T162702_036a69733891_update_index_ix_partial_unique_address_per_street_and_insee_code.py
Show resolved
Hide resolved
But de la pull request
Ticket Jira : https://passculture.atlassian.net/browse/PC-30539
Vérifications