MALIO-DEV/Starseed
3
0
Fork 0
Code Issues Pull Requests 4 Actions Packages Projects Releases Wiki Activity

ERP-119 : revue validation front clients + évolutions écran client (types d'adresse, 2e email, saisies manuelles, redirection) #80

Merged
tristan merged 7 commits from feature/ERP-119-revoir-la-validation-front into develop 2026-06-09 19:47:41 +00:00
Conversation 0 Commits 7 Files Changed 25
+1011 -245
tristan commented 2026-06-09 12:09:53 +00:00
Owner
Copy Link
Copy Source

Contexte

Branche ERP-119 — revue de la validation des formulaires clients (déclencheur : écran « Ajouter un client »), accompagnée de plusieurs évolutions de l'écran client (M1).

Contenu

Validation front (clients)

  • Boutons « Valider » toujours actifs (retrait du gating de validité) : c'est le back qui renvoie les 422, mappées en rouge par champ.
  • Champs requis adossés à une colonne non-nullable : la clé est omise du payload si vide (companyName, RIB, adresse) → 422 NotBlank au lieu d'un 400 de type.
  • Onglet Contact : au moins un contact requis (l'amorce vide est soumise → 422 RG-1.05).
  • Onglet Adresse : affichage inline des erreurs type / sites / catégories + RG back « au moins un type d'adresse obligatoire ».

Nouveaux types d'adresse

  • Courtier / Distributeur, types autonomes exclusifs : colonnes is_broker / is_distributor (migration + CHECK miroir d'exclusivité), entité + Callback, et front (select, drapeaux, payloads).

Saisies manuelles

  • Adresse : allow-create sur le champ Adresse → saisie libre si la BAN ne propose rien.
  • Date de création : MalioDate :editable → saisie clavier JJ/MM/AAAA en plus du calendrier.

2e email de facturation

  • Colonne billing_email_secondary (optionnel, max 2), miroir du téléphone secondaire. Bump @malio/layer-ui 1.7.8 (prop addable).

Fin d'ajout d'un client

  • Redirection vers la liste à la validation du dernier onglet remplissable par le rôle (Adresse pour Bureau/Commerciale, Comptabilité pour Admin) + toast « Client ajouté ». Dérivé de tabKeys, sans règle RBAC custom.

Vérifications

  • Back : suites Module/Commercial + Architecture vertes (Client : 124/124). Migrations appliquées (dev + test).
  • Front : Vitest vert (272), ESLint OK.

Note : le hook pré-commit flake aléatoirement (JWT 401 / timeout DB) sur des tests sans rapport (Supplier) ; les commits ont été faits après vérification des suites concernées en isolation.

## Contexte Branche ERP-119 — revue de la validation des formulaires clients (déclencheur : écran « Ajouter un client »), accompagnée de plusieurs évolutions de l'écran client (M1). ## Contenu ### Validation front (clients) - Boutons « Valider » toujours actifs (retrait du gating de validité) : c'est le back qui renvoie les 422, mappées en rouge par champ. - Champs requis adossés à une colonne non-nullable : la clé est omise du payload si vide (companyName, RIB, adresse) → 422 NotBlank au lieu d'un 400 de type. - Onglet Contact : au moins un contact requis (l'amorce vide est soumise → 422 RG-1.05). - Onglet Adresse : affichage inline des erreurs type / sites / catégories + RG back « au moins un type d'adresse obligatoire ». ### Nouveaux types d'adresse - Courtier / Distributeur, types autonomes exclusifs : colonnes `is_broker` / `is_distributor` (migration + CHECK miroir d'exclusivité), entité + Callback, et front (select, drapeaux, payloads). ### Saisies manuelles - Adresse : `allow-create` sur le champ Adresse → saisie libre si la BAN ne propose rien. - Date de création : `MalioDate :editable` → saisie clavier JJ/MM/AAAA en plus du calendrier. ### 2e email de facturation - Colonne `billing_email_secondary` (optionnel, max 2), miroir du téléphone secondaire. Bump `@malio/layer-ui` 1.7.8 (prop `addable`). ### Fin d'ajout d'un client - Redirection vers la liste à la validation du dernier onglet remplissable par le rôle (Adresse pour Bureau/Commerciale, Comptabilité pour Admin) + toast « Client ajouté ». Dérivé de `tabKeys`, sans règle RBAC custom. ## Vérifications - Back : suites Module/Commercial + Architecture vertes (Client : 124/124). Migrations appliquées (dev + test). - Front : Vitest vert (272), ESLint OK. > Note : le hook pré-commit flake aléatoirement (JWT 401 / timeout DB) sur des tests sans rapport (Supplier) ; les commits ont été faits après vérification des suites concernées en isolation.
tristan added the type/featbackfrontdbwipM1-Client labels 2026-06-09 12:09:53 +00:00
tristan added 3 commits 2026-06-09 12:09:53 +00:00
feat(commercial) : revue de la validation front clients + RG type d'adresse (ERP-119) 982f501b94 
- Boutons « Valider » toujours actifs (retrait du gating de validite) : le back renvoie les 422 mappees en rouge par champ.
- Champs requis a colonne non-nullable : la cle est omise du payload si vide (companyName, RIB, adresse) -> 422 NotBlank au lieu d'un 400 de type a la deserialisation.
- Onglet Contact : au moins un contact requis -> l'amorce vide est soumise pour declencher la 422 RG-1.05 quand aucun contact n'est nomme.
- Adresse : affichage inline des erreurs type / sites / categories, et nouvelle RG back « au moins un type d'adresse obligatoire » (Callback sur isProspect).
feat(commercial) : types d'adresse Courtier et Distributeur (ERP-119) f6be671230 
Ajoute deux types d'adresse autonomes (exclusifs, comme la Prospection) :
- back : colonnes is_broker / is_distributor sur client_address (migration
  modulaire, append + 2 CHECK miroir d'exclusivite + COMMENT ON COLUMN),
  proprietes ClientAddress (getters Groups + SerializedName), Callback
  validateExclusiveAddressTypes, validateAddressTypeRequired etendue,
  catalogue des commentaires SQL mis a jour.
- front : type AddressType (+broker/distributor), drapeaux, mappers, option
  du select Type d'adresse, labels i18n, payloads create/edit et lecture.
- tests back (acceptation + exclusivite + contrat de serialisation) et front.
feat(commercial) : saisie manuelle de l'adresse si la BAN ne trouve rien (ERP-119)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 2m5s
Details
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m9s
Details
4d403ec7ed 
Le champ Adresse (MalioInputAutocomplete) passe en allow-create : le texte saisi
est conserve au blur/Entree meme sans suggestion BAN (sinon il etait efface).
Message « Adresse introuvable ? Saisissez-la directement. » dans la liste vide.
La ville reste pilotee par le code postal.
tristan added 1 commit 2026-06-09 12:32:33 +00:00
feat(commercial) : redirection vers la liste a la fin de l'ajout d'un client (ERP-119)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 2m6s
Details
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m10s
Details
ada4b156fa 
Quand le dernier onglet remplissable par le role est valide (Adresse pour
Bureau/Commerciale, Comptabilite pour Admin), l'ajout est termine : toast
« Client ajoute » + redirection vers /clients. Le dernier onglet remplissable
est derive de tabKeys via lastFillableTabKey (dernier onglet non-placeholder),
deja role-aware, sans regle RBAC custom. completeTab retourne un booleen pour
eviter le double toast.
tristan added 1 commit 2026-06-09 18:39:13 +00:00
feat(commercial) : 2e email de facturation optionnel sur l'adresse client (ERP-119)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 2m9s
Details
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m10s
Details
dacf67535d 
Pendant du telephone secondaire (max 2). Bump @malio/layer-ui 1.7.8 (prop
addable du MalioInputEmail).

- back : colonne billing_email_secondary (migration + COMMENT + catalogue),
  propriete ClientAddress (Email + Length), Callback etendu (2e email interdit
  hors facturation, optionnel sinon), normalisation lowercase au Processor.
- front : draft + flag UI hasSecondaryBillingEmail, mappers, payloads, champ
  MalioInputEmail :addable -> revele un 2e champ ; layout : 2e email qui coule
  dans la grille et Adresse complementaire sur une colonne.
- tests back (2 emails / 2e email hors facturation) et front (payload).
tristan added 1 commit 2026-06-09 18:43:48 +00:00
feat(commercial) : saisie manuelle de la date de creation du client (ERP-119)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 2m6s
Details
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m9s
Details
5b3ce0eb13 
Champ « Date de creation » (foundedAt) en :editable sur les formulaires de
creation et d'edition : saisie clavier JJ/MM/AAAA en plus du calendrier
(prop MalioDate, @malio/layer-ui 1.7.8). Consultation inchangee (lecture seule).
tristan removed the wip label 2026-06-09 18:45:13 +00:00
tristan changed title from ERP-119 : revue validation front clients + types d'adresse (Courtier/Distributeur) + saisie manuelle to ERP-119 : revue validation front clients + évolutions écran client (types d'adresse, 2e email, saisies manuelles, redirection) 2026-06-09 18:45:14 +00:00
tristan added 1 commit 2026-06-09 19:43:23 +00:00
feat(commercial) : validation back de la relation + suivi de revue MR (ERP-119)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 2m52s
Details
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m9s
Details
8bfaa3f640 
- validation serveur « relation choisie => FK obligatoire » : champ transitoire
  relationType (non persiste) + Assert\Callback portant la 422 sur distributor /
  broker, que le back ne pouvait pas deriver des seules FK nullable
- mutualisation des payloads d'ecriture clients : new.vue consomme buildMainPayload
  / buildAddressPayload / buildRibPayload (fin de la duplication create/edit)
- COMMENT ON TABLE client_address : ajout des types Courtier / Distributeur
  (catalogue + migration Version20260609120000)
- tests : violationsByPath remonte dans AbstractCommercialApiTestCase (fin des
  copies inline) + couverture de la nouvelle RG relation
tristan merged commit 8490de99da into develop 2026-06-09 19:47:41 +00:00
tristan deleted branch feature/ERP-119-revoir-la-validation-front 2026-06-09 19:47:41 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
back
Backend PHP / Symfony / API Platform
 blocked
Bloqué par une dépendance externe
 breaking
Breaking change — impact API / contrat
 db
Migrations Doctrine / schéma BDD
 front
Frontend Nuxt / Vue / @malio/layer-ui
 infra
Docker / nginx / config infra
 M0-Categorie
M0 — Catégories
 M1-Client
M1 — Clients
 M2-Fournisseur
M2 — Fournisseurs
 M3-Prestataire
M3 — Prestataires
 M4-Transporteur
M4 — Transporteurs
 M5-Ticket-pesee
M5 — Tickets de pesée
 type/chore
Tâche de maintenance (bump, conf, etc.)
 type/ci
CI / pipeline / workflows
 type/docs
Documentation
 type/feat
Nouvelle fonctionnalité
 type/fix
Correction de bug
 type/perf
Amélioration de performance
 type/refactor
Refacto sans changement fonctionnel
 type/test
Ajout ou modification de tests
 wip
Work in progress — ne pas merger
No Label back db front M1-Client type/feat
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
malio (admin malio) matthieu (THOLOT DECHENE Matthieu) tristan (Autin )
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MALIO-DEV/Starseed#80
Delete Branch "feature/ERP-119-revoir-la-validation-front"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?