matthieu
8fae987e15
Auto Tag Develop / tag (push) Successful in 6s
Acte la décision refonte-contact dans les specs : le contact principal inline (firstName/lastName/phonePrimary/phoneSecondary/email) est retiré des entités tiers (Client, Supplier). Les contacts vivent uniquement dans ClientContact / SupplierContact (onglet Contacts). Garantie « >=1 contact nommé » préservée par RG-1.05/1.14 (M1) et RG-2.04/2.13 (M2). - M1 (spec-back/spec-front/cahier) : modèle Client sans contact inline ; RG-1.01/1.02 supprimées ; D1 (recherche) / D2 (export) décrites ; version V1. - M2 (spec-back/spec-front) : FICHIERS NOUVEAUX (non versionnés sur develop), introduits déjà corrigés (Supplier sans contact inline, RG-2.01/2.02 supprimées) ; version V0.2. - docs/specs/M1-clients/refonte-contact/ : décision (README) + tickets (M1 back/front/specs, M2 specs) + prompts + amendement des tickets M2. Lesstime : tâches #103 (M1 back), #104 (M1 front), #105 (M1 specs), #106 (M2 specs) ; tickets M2 #85-#97 amendés. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #54 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
4.9 KiB
4.9 KiB
Refonte « contact » — suppression du contact inline des tiers (Client M1 + Supplier M2)
Dossier de tickets transverse. Source de vérité de la décision et de son découpage. Rédigé le 2026-06-03. Owner : Matthieu.
1. Décision
Le contact « principal » inline (les 5 colonnes plates first_name, last_name,
phone_primary, phone_secondary, email) est supprimé de l'entité tier (Client,
puis Supplier). La gestion des contacts passe exclusivement par la sous-entité
dédiée (ClientContact / SupplierContact), c.-à-d. l'onglet « Contacts ».
Pourquoi
- Modèle unique, zéro duplication. Aujourd'hui le contact est saisi deux fois : une
fois dans le bloc principal (inline sur le tier) et une fois dans l'onglet Contacts
(sous-entité). À la création, le front recopie même l'un dans l'autre
(
prefillFirstContact). Deux sources pour la même information = risque de divergence. - Cohérence métier. Un tier peut avoir plusieurs contacts ; il n'y a pas de raison qu'un seul soit « privilégié » au niveau de la table tier. La notion de contact appartient à la collection de contacts.
- Garantie préservée. L'invariant « il y a toujours au moins un contact » est déjà assuré par la sous-entité : RG-1.05/RG-1.14 (M1) et RG-2.04/RG-2.13 (M2) imposent ≥ 1 bloc Contact valide (Nom OU Prénom). Supprimer le contact inline ne crée donc aucun trou : le contact reste obligatoire, mais au bon endroit.
Règles de gestion impactées
| RG | Avant | Après |
|---|---|---|
| RG-1.01 / RG-2.01 (firstName OU lastName obligatoire sur le tier) | sur Client / Supplier |
supprimée du tier — équivalent assuré par RG-1.05 / RG-2.04 sur la sous-entité |
| RG-1.02 / RG-2.02 (max 2 téléphones sur le tier) | sur le tier | supprimée du tier — reste sur la sous-entité |
| RG-1.19/1.20/1.21 — RG-2.12 (normalisation Capitalize / chiffres / lowercase) | appliquée aux champs du tier ET de la sous-entité | ne s'applique plus aux champs du tier (qui n'existent plus) — inchangée sur la sous-entité |
2. Périmètre & découpage
M1 — Clients (code DÉJÀ livré → suppression + migration de données)
| # | Ticket | Tag | Effort |
|---|---|---|---|
| 1 | M1-ticket-01-back — supprimer le contact inline du Client (migration + backfill + entité + processor + provider + export + fixtures + tests) |
Backend | M |
| 2 | M1-ticket-02-front — retirer le bloc contact principal des écrans création / consultation / modification |
Frontend | M |
| 3 | M1-ticket-03-specs — acter la décision dans les specs M1 (back + front + cahier de test) |
Maintenance | S |
M2 — Fournisseurs (NON codé → on retire le contact inline dès la conception)
| # | Action | Tag | Effort |
|---|---|---|---|
| 4 | M2-ticket-specs — mettre à jour les specs M2 déjà écrites (back + front) pour retirer le contact inline du Supplier |
Maintenance | S |
| — | M2-amendement-tickets — amender les tickets M2 existants (n° 84–97) impactés (migration, entités, processor, export, front, tests, i18n) |
— | — |
M2 ne nécessite pas de migration de suppression ni de backfill : il suffit de ne jamais créer les 5 colonnes inline sur
supplier. Le travail M2 est donc un ajustement de specs + un amendement des tickets « prêts à dev ».
3. Décisions transverses à trancher (mêmes pour M1 et M2)
Deux comportements s'appuyaient sur les colonnes inline du tier. À la suppression, il faut choisir leur nouvelle source. Recommandation par défaut entre parenthèses.
- D1 — Recherche serveur (
?search=). Aujourd'hui : fuzzy surcompanyName+lastName+emaildu tier. Après suppression, deux options :- (a) restreindre la recherche à
companyNameseul (simple, mais perte de la recherche par contact) ; - (b) [recommandé] étendre la recherche en
LEFT JOINsur la sous-entité contact (first_name/last_name/emaildu contact), pour préserver l'UX « recherche par nom / contact / email » annoncée dans la barre de recherche.
- (a) restreindre la recherche à
- D2 — Colonnes de l'export XLSX (Nom contact / Prénom / Téléphone / Téléphone 2 /
Email). Après suppression :
- (a) supprimer ces colonnes ;
- (b) [recommandé] les alimenter depuis le contact principal (le contact de plus
petit
position), pour garder un export utile.
Ces deux décisions sont à valider par le métier (Matthieu) avant implémentation et sont rappelées dans chaque ticket concerné.
4. Fichiers de ce dossier
README.md(ce fichier) — décision + découpage.M1-ticket-01-back.md/.prompt.md— description + prompt d'implémentation.M1-ticket-02-front.md/.prompt.md.M1-ticket-03-specs.md/.prompt.md.M2-ticket-specs.md/.prompt.md.M2-amendement-tickets.md— bandeau d'amendement + liste des tickets M2 à mettre à jour.