Matthieu
83508d0c5a
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.
75 lines
5.0 KiB
Markdown
75 lines
5.0 KiB
Markdown
# 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.
|