MALIO-DEV/Starseed

Fork 0

Files

T

Matthieu 83508d0c5a

Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m39s

Details

Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m5s

Details

docs(commercial) : refonte contact — suppression du contact inline (specs M1 + M2)

Le contact principal inline (firstName/lastName/phonePrimary/phoneSecondary/email)
est retiré des entités tiers : il vit désormais uniquement dans ClientContact /
SupplierContact (onglet Contacts).

- M1 (spec-back / spec-front / cahier-test) : contact inline retiré du modèle Client ;
  RG-1.01 et RG-1.02 marquées supprimées (équivalent RG-1.05 / RG-1.14) ; décisions
  D1 (recherche) et D2 (export) décrites ; version V1.
- M2 (spec-back / spec-front) : contact inline retiré du modèle Supplier dès la
  conception ; RG-2.01 et RG-2.02 supprimées (équivalent RG-2.04 / RG-2.13) ; version
  V0.2. Fichiers M2 introduits ici car non encore versionnés sur develop.
- docs/specs/M1-clients/refonte-contact/ : décision (README) + tickets (M1 back/front/
  specs, M2 specs) + prompts d'implémentation + amendement des tickets M2 existants.

2026-06-03 15:11:45 +02:00

5.0 KiB

Raw Blame History

M1 · Ticket 2/3 (Frontend) — Retirer le bloc contact principal des écrans Client

1. Objectif

Retirer le bloc « contact principal » (Nom, Prénom, Téléphone, Téléphone 2, Email) des trois écrans Client — création, consultation, modification — ainsi que des types, mappeurs, validations et clés i18n associés. La saisie des contacts se fait désormais uniquement dans l'onglet « Contacts » (composant ClientContactBlock, déjà en place et inchangé).

Dépend du ticket 1/3 (back) : l'API ne renvoie/n'accepte plus ces 5 champs sur client. Contexte : voir README.md du dossier refonte-contact.

2. Périmètre

IN — fichiers `frontend/modules/commercial/`

Fichier	Action
`pages/clients/new.vue`	Supprimer le bloc principal Nom/Prénom/Téléphones/Email (~l.27-63), l'état `main.firstName/lastName/email`, `mainPhones` (~l.445-459), la fonction `prefillFirstContact()` (~l.658-665) et son appel, le mapping payload POST `phonePrimary/phoneSecondary` (~l.513-524). Adapter `isMainValid` (~l.479-493) : la validation principale ne porte plus que sur `companyName` (+ relation/catégories selon RG existantes). L'onglet Contacts devient le point de saisie des coordonnées ; garantir au moins un `ClientContactBlock` vide au départ.
`pages/clients/[id]/edit.vue`	Supprimer les 5 champs du bloc principal (~l.32-73). `mapMainDraft()` et `buildMainPayload()` ne portent plus ces champs. L'onglet Contacts reste éditable.
`pages/clients/[id]/index.vue`	Supprimer l'affichage lecture seule des 5 champs du bloc principal (~l.49-104, partie contact). Conserver l'onglet Contacts (lecture seule).
`types/clientForm.ts`	`MainFormDraft` : retirer `firstName`, `lastName`, `email`, `phonePrimary`, `phoneSecondary`, `hasSecondaryPhone`. Garder `ContactFormDraft` (inchangé).
`types/clientConsultation.ts`	`ClientDetail` : retirer `firstName/lastName/phonePrimary/phoneSecondary/email` (les commentaires « Contact principal »). Garder `ContactRead`.
`utils/clientEdit.ts`	`mapMainDraft()` et `buildMainPayload()` : retirer les 5 champs. Garder `buildContactPayload()`.
`utils/clientConsultation.ts`	Retirer toute lecture des 5 champs inline du client (garder `mapContactToDraft`, `contactOptionsOf`).
`i18n/locales/fr.json`	Retirer `commercial.clients.form.main.firstName/lastName/email/phonePrimary/phoneSecondary/addPhone`. Conserver tout le bloc `commercial.clients.form.contact.*`. Vérifier qu'aucune autre vue ne référence les clés retirées.
`*/__tests__/.spec.ts`	Mettre à jour `clientFormRules.spec.ts`, `clientEdit.spec.ts`, `clientConsultation.spec.ts` (cf. § 4).

OUT

ClientContactBlock.vue, l'onglet Contacts, useClient, la liste/répertoire (pages/clients/index.vue — ses colonnes n'affichent déjà pas le contact inline) : inchangés.
Le back → ticket 1/3. Les specs → ticket 3/3.

3. Comportement attendu après modification

Création : le formulaire principal demande l'entreprise (et relation/catégories selon l'existant), plus de Nom/Prénom/Téléphone/Email inline. L'utilisateur renseigne les coordonnées dans l'onglet Contacts. La création reste valide tant qu'il y a companyName et ≥ 1 bloc Contact valide (Nom OU Prénom) — RG-1.05/RG-1.14 inchangées.
Consultation : plus de bloc contact principal ; l'onglet Contacts affiche les contacts.
Modification : idem ; le PATCH du groupe client:write:main n'envoie plus les 5 champs.

4. Tests Vitest à mettre à jour

clientFormRules.spec.ts : la validité du « principal » ne dépend plus de firstName/email/phone ; conserver isContactNamed() (RG-1.05) sur les blocs Contacts.
clientEdit.spec.ts : buildMainPayload() ne contient plus les 5 champs ; mapMainDraft() non plus.
clientConsultation.spec.ts : retirer les assertions sur les 5 champs inline.

5. Tips & rappels projet

useApi() obligatoire (jamais $fetch/ofetch). Composants Malio* obligatoires.
État de tableau jamais dans l'URL (règle inchangée).
Les valeurs sont normalisées côté serveur (Capitalize / chiffres / lowercase) : le front envoie la saisie et réaffiche la valeur renvoyée — ne pas réintroduire de normalisation front.
Ne pas créer de clé i18n orpheline ni laisser de clé form.main.* morte.

6. Critères d'acceptation (DoD)

Les 3 écrans n'affichent plus Nom/Prénom/Téléphone/Téléphone 2/Email en bloc principal.
Le parcours de création fonctionne avec companyName + onglet Contacts (≥ 1 contact).
MainFormDraft / ClientDetail ne déclarent plus les 5 champs ; mapMainDraft / buildMainPayload non plus.
Aucune clé i18n form.main.firstName/lastName/email/phone* restante ni référencée.
make nuxt-test vert.
Vérification visuelle du golden path (make dev-nuxt, port 3004) : création → consultation → modification d'un client sans bloc contact inline.

5.0 KiB Raw Blame History