Compare commits

..

11 Commits

Author SHA1 Message Date
matthieu 38f9f164f1 [ERP-58] Implémenter l'export XLSX du répertoire clients (#37)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m40s
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m15s
## Contexte
Ticket ERP-58 (M1 Commercial, spec-back § 4.6) — export XLSX du répertoire clients.
Branche stackée sur ERP-57. **Cible la MR sur \`feature/ERP-57-...\`** (squash merge).

## Objectif d'archi : un service d'export RÉUTILISABLE
Le générique vit dans \`Shared\`, le module Client ne déclare que QUOI exporter.

### Shared (le COMMENT — sans métier)
- \`Shared/Domain/Contract/SpreadsheetExporterInterface\` : \`export(string $sheetTitle, array $headers, iterable $rows): string\`. Zéro connaissance métier.
- \`Shared/Infrastructure/Export/PhpSpreadsheetExporter\` : implémentation PhpSpreadsheet (en-tête ligne 1 + lignes, retour binaire via fichier temporaire). Titre d'onglet assaini (≤ 31 car., caractères Excel interdits retirés). Supporte un \`iterable\` paresseux (generator).
- Auto-aliasé (un seul implémenteur) → \`SpreadsheetExporterInterface\` résout vers \`PhpSpreadsheetExporter\`.

> Tout futur module réutilise \`SpreadsheetExporterInterface\` sans toucher au Client.

### Commercial (le QUOI)
- \`ClientExportController\` (controller custom, \`#[Route('/api/clients/export.xlsx', priority: 1)]\` — **priority:1 obligatoire** pour éviter le conflit API Platform \`{id}\`). Security \`commercial.clients.view\`.
- Mêmes filtres que \`GET /api/clients\` (non archivés par défaut, \`?search\`, \`?categoryType\`, \`?includeArchived\`). **Filtrage factorisé dans \`ClientRepository::createListQueryBuilder()\`** (search + categoryType déplacés depuis \`ClientProvider\`) → liste paginée et export partagent strictement la même logique, zéro duplication.
- Colonnes (§ 4.6) : Nom entreprise, Nom contact principal, Prénom, Tél. principal, Tél. secondaire, Email, Catégories (CSV), Sites (CSV = union distincte des sites des adresses), **SIREN (omis si pas \`commercial.clients.accounting.view\`)**, Date de création.
- Réponse : \`Content-Type: …spreadsheetml.sheet\`, \`Content-Disposition: attachment; filename="repertoire-clients-{YYYYMMDD}.xlsx"\`.

## Dépendance
\`composer require phpoffice/phpspreadsheet\` (^5.7). Nettoyage recipes vérifié : seuls \`composer.json\`/\`composer.lock\` modifiés (pas de scaffolding parasite, \`symfony.lock\` désormais versionné).

## Tests (404 OK)
- **Unitaire Shared** : XLSX relisible (en-têtes + 2 lignes), generator, titre assaini.
- **Fonctionnel** : 200 (Content-Type + filename), exclusion archives par défaut, \`?search\`/\`?categoryType\`, SIREN présent (accounting.view) / absent (view seul), 403 sans \`clients.view\`, 401 anonyme.

## Note
Au démarrage, \`symfony/intl\` (requis par ERP-57, contrainte \`Bic\`) manquait du vendor → \`composer install\` joué pour rétablir une base saine.

## ⚠️ Heads-up review (@Tristan) — fichiers « propriété » d'ERP-55 touchés
Cette MR refactore deux fichiers introduits par ERP-55 :
- **`ClientRepository::createListQueryBuilder()`** accueille désormais le filtrage `search` + `categoryType` (signature `(bool $includeArchived, ?string $search, ?string $categoryType)`).
- **`ClientProvider`** délègue ce filtrage au repository → il **perd sa dépendance `EntityManager`** et ses méthodes privées `applySearch` / `applyCategoryType`.

**Pourquoi** : DRY entre la liste paginée (`GET /api/clients`) et l'export — une seule source de vérité pour la sélection des clients. Effet de bord positif : ça résout **plus proprement la fuite d'abstraction** que tu avais pointée en revue ERP-55 (P2) — la sous-requête `categoryType` n'est plus construite via l'`EntityManager` injecté dans le provider, mais à l'intérieur du repository (là où l'accès Doctrine est légitime).

Pas de changement de comportement de l'API liste : régression couverte par `ClientApiTest` (tri, exclusion archives, includeArchived, pagination) — tout vert.

---------

Co-authored-by: Matthieu <contact@malio.fr>
Reviewed-on: #37
Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
2026-06-01 19:28:34 +00:00
Matthieu c21bfea7f6 feat(commercial) : add client sub-resources processors (contacts/addresses/ribs)
Expose les sous-ressources Contacts / Adresses / RIB du repertoire clients
(M1, spec § 4.5) :

- 3 Processors dedies (ClientContactProcessor, ClientAddressProcessor,
  ClientRibProcessor) : normalisation serveur reutilisant ClientFieldNormalizer
  (RG-1.19 capitalize, RG-1.20 telephones chiffres, RG-1.21 emails/billingEmail
  lowercase) + regles metier.
- Operations API Platform :
  - POST /api/clients/{id}/contacts|addresses, PATCH/DELETE /api/client_contacts|addresses/{id}
    (security commercial.clients.manage)
  - POST /api/clients/{id}/ribs, PATCH/DELETE /api/client_ribs/{id}
    (security commercial.clients.accounting.manage)
  - GET item par sous-ressource (lecture unitaire) ; pas de GET collection
    autonome (lecture via le parent, non concernee par la pagination ERP-72).
- Regles de gestion :
  - RG-1.13 : DELETE du dernier RIB d'un client en reglement LCR -> 409.
  - RG-1.14 : DELETE du dernier contact d'un client -> 409 (completude front au M1).
  - RG-1.05 : prenom OU nom du contact obligatoire -> 422.
- Validations deja portees par l'entite et desormais exercees : Assert\Count(min:1)
  sur ClientAddress.sites (RG-1.10), Assert\Regex code postal (RG-1.09),
  Assert\Iban / Assert\Bic sur ClientRib.
- SiteReferenceDenormalizer : resout les IRIs /api/sites vers SiteInterface
  (meme pattern que CategoryReferenceDenormalizer, sans import cross-module).
- Ajout de symfony/intl, requis par Assert\Bic.

Tests : ClientSubResourceApiTest (13 cas) couvrant CRUD, normalisation,
RG-1.13/1.14, gating 403 sur client_ribs sans accounting.manage. Suite back
complete au vert (383 tests).
2026-06-01 16:18:23 +02:00
Matthieu f29587f113 feat(commercial) : expose accounting referentials read-only API
Expose TvaMode, PaymentDelay, PaymentType et Bank en lecture seule
(GetCollection + Get), security commercial.clients.view au niveau
operations + ressource. Aucune ecriture declaree -> POST/PATCH/DELETE
renvoient 405.

Tri par defaut position ASC puis label ASC (spec M1 § 4.7). Pagination
serveur conservee (ERP-72) avec paginationClientEnabled pour activer
l'echappatoire ?pagination=false (alimenter un select sans pagination).

Endpoints : GET /api/tva_modes, /api/payment_delays, /api/payment_types,
/api/banks. Tests fonctionnels : 200 + seed, tri position/label,
405 ecritures, 403 sans permission, 401 anonyme, pagination toggle.
2026-06-01 16:18:23 +02:00
Matthieu aa1a42e659 fix(commercial) : flatten clients route 2026-06-01 16:16:00 +02:00
Matthieu a84bde5bcc feat(commercial) : declare commercial.clients permissions + sync RBAC mirrors
Ajoute CommercialModule::permissions() (5 codes commercial.clients.* :
view, manage, accounting.view, accounting.manage, archive) — alignes sur
les is_granted deja references par ERP-55 (Client ApiResource, ClientProcessor,
ClientReadGroupContextBuilder).

Synchronise les 3 sources RBAC (regle ABSOLUE n8) : item sidebar
"Repertoire clients" (commercial.clients.view), persona user-full dans
personas.ts et SeedE2ECommand.php, cle i18n sidebar.commercial.clients.

Les roles metier Bureau/Compta/Commerciale/Usine sont seedes par ERP-74 :
les 5 permissions sont mappees ici sur le seul persona technique user-full
en attendant, sans creer de nouveau persona (regle n7).
2026-06-01 14:50:45 +02:00
Matthieu 0f8fc48df0 fix(commercial) : robust gating + strict category denormalizer + provider via EM (review ERP-55) 2026-06-01 14:50:45 +02:00
Matthieu d3d00425f7 feat(commercial) : add Client API Platform provider + processor + business rules
Branche l'API REST du repertoire clients (M1) sur l'entite Client preparee en
ERP-54. Operations GetCollection / Get / Post / Patch (pas de Delete au M1 :
l'archivage passe par PATCH isArchived).

ClientProvider :
- liste paginee (Paginator ORM, aligne sur la convention ERP-72) + echappatoire
  ?pagination=false
- exclut archives + soft-deletes par defaut (RG-1.24), ?includeArchived=true
  reintegre les archives (RG-1.25)
- tri companyName ASC (RG-1.26), filtres ?search (fuzzy companyName/lastName/
  email) et ?categoryType=<code>
- detail : 404 sur soft-delete, embarque contacts/adresses/ribs

ClientProcessor :
- normalisation serveur via ClientFieldNormalizer (RG-1.18 a 1.21)
- 409 sur doublon de nom de societe (RG-1.16) ; 409 dedie sur conflit de
  restauration (RG-1.23)
- gating par onglet : champ comptable -> accounting.manage, isArchived ->
  archive, mode strict 403 sur tout le payload (RG-1.28) ; archivage exclusif
  (RG-1.22) + pose/retrait archivedAt
- regles metier RG-1.01 (prenom/nom), RG-1.03 (distributor/broker exclusifs +
  controle du type de categorie), RG-1.12 (Virement -> banque), RG-1.13 (LCR ->
  >= 1 RIB), RG-1.04 (completude Information pour le role Commerciale)

Lecture comptable conditionnelle : ClientReadGroupContextBuilder ajoute le
groupe client:read:accounting selon commercial.clients.accounting.view.

Resolution des references categorie : CategoryReferenceDenormalizer resout les
IRI vers Category quand la propriete est type-hintee par le contrat
CategoryInterface (denormalisation impossible sur une interface sinon).

Contrats Shared :
- CategoryInterface::getCategoryTypeCode() (implemente par Category) pour la
  verification de type sans import inter-modules
- BusinessRoleAwareInterface (implemente par User) + BusinessRoles::COMMERCIALE
  pour detecter le role metier ; le code de role sera seede par ERP-74 et
  reutilise par ERP-59/60. RG-1.04 reste dormante tant qu'aucun user ne porte
  ce role.

Coordination stack :
- chaines de permission commercial.clients.* referencees ici, declarees en
  ERP-59 (tests RBAC complets en ERP-60)
- config globale de pagination (itemsPerPage client, max 50) portee par ERP-72
- referentiels comptables (PaymentType/Bank/...) exposes en ERP-56

Tests : 31 tests Commercial (integration admin sur les regles metier + unitaires
sur le gating, RG-1.04/1.12/1.13 et le context builder). Suite complete verte
(339 tests).
2026-06-01 14:50:45 +02:00
Matthieu a9998d4bcd feat(commercial) : add M1 client entities + accounting referentials + repositories
Entites metier (Client, ClientContact, ClientAddress, ClientRib) avec
#[Auditable] + Timestampable/Blamable, et 4 referentiels comptables statiques
(TvaMode, PaymentDelay, PaymentType, Bank). 8 repositories interfaces + impl
Doctrine. Aucun ApiResource (Provider/Processor = ERP-55).

- Client : 2 FK auto-referentes distributor/broker (mutuellement exclusives,
  CHECK en base), M2M categories, FK referentiels comptables, groupes de
  serialisation par onglet. Pas de #[ORM\UniqueConstraint] : unicite du nom de
  societe portee par l'index partiel Postgres (decision Q4).
- ClientRib : tous les champs audites, aucun #[AuditIgnore] sur iban/bic
  (decision 29/05, audit admin-only).
- M2M Category via le contrat Shared CategoryInterface + resolve_target_entities
  (regle n°1, pas d'import inter-modules) ; sites via SiteInterface.
- CommercialReferentialFixtures : re-seed idempotent des 4 referentiels (sinon
  vides apres db-reset car desormais tables mappees, purgees par les fixtures).
- Referentiels whitelistes dans EntitiesAreTimestampableBlamableTest::EXCLUDED.
- doctrine.yaml : mapping ORM du module Commercial + resolve CategoryInterface.
- ColumnCommentsCatalog : ajout des colonnes M1 (chemin schema:update/test) ;
  migration retrofit Version20260528120000 filtree sur les tables existantes
  pour ne pas casser sur les tables des modules crees plus tard.
- makefile test-db-setup : recreation de l'index partiel uq_client_company_name_active.

Refs ERP-54.
2026-06-01 14:50:45 +02:00
Matthieu 034301ceaf fix(commercial) : down() orphan-only + index FK referentiels (review ERP-53)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m29s
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m15s
2026-06-01 14:50:45 +02:00
Matthieu 8d0a9a67ef feat(commercial) : migrate M1 client tables + accounting referentials + extend category_type seed 2026-06-01 14:50:45 +02:00
Matthieu bc4b1d0492 docs(commercial) : migration racine + seed fixture CategoryType (blocages ERP-53 vérifiés) 2026-06-01 14:50:45 +02:00
10 changed files with 1 additions and 751 deletions
+1 -1
View File
@@ -1,2 +1,2 @@
parameters:
app.version: '0.1.60'
app.version: '0.1.58'
@@ -1,79 +0,0 @@
# Cahier de test back — M1 Répertoire clients (ticket ERP-60 / #478)
Mapping **toutes les RG (§ 7) → test(s) PHPUnit**, à jour après ERP-60.
Légende source : `ERP-55` `ERP-56` `ERP-57` `ERP-58` = tests écrits par les wagons
précédents ; **`ERP-60`** = tests ajoutés par ce ticket (stratégie « combler les
trous, zéro duplication »).
## Stratégie
ERP-60 n'écrit QUE les tests des RG non déjà couvertes par la stack, et mappe ici
l'intégralité des RG (existantes + nouvelles + déléguées). Les tests dépendants
des **rôles métier** (matrice RBAC bureau/compta/commerciale/usine + RG-1.04
fonctionnel) sont **délégués à ERP-74 (#493)** : ces rôles n'existent qu'après le
merge de la stack.
## Mapping RG → test
| RG | Intitulé | Test(s) | Source |
|----|----------|---------|--------|
| RG-1.01 | Prénom OU nom obligatoire → 422 | `ClientApiTest::testPostWithoutFirstOrLastNameReturns422` ; `ClientProcessorTest` (unit) | ERP-55 |
| RG-1.02 | phoneSecondary persisté ; max 2 téléphones | `ClientFormulaireMainTest::testPostPersistsSecondaryPhoneNormalized` ; `::testThirdPhoneFieldIsIgnored` | **ERP-60** |
| RG-1.03 | distributor/broker exclusifs + type catégorie | `ClientApiTest::testPostWithDistributorAndBrokerReturns422` ; `::testPostDistributorReferencingNonDistributorReturns422` ; `::testPostValidDistributorReturns201` ; `ClientProcessorTest` (unit) | ERP-55 |
| RG-1.04 | Onglet Information obligatoire pour rôle Commerciale | `ClientProcessorTest::testCommercialeIncompleteInformationIsUnprocessable` ; `::testNonCommercialeSkipsInformationCompleteness` (unit, dormant). **Test fonctionnel + durcissement → ERP-74** | ERP-55 / **ERP-74** |
| RG-1.05 | Contact : prénom OU nom → 422 (CHECK) | `ClientSubResourceApiTest::testPostContactWithoutNameReturns422` | ERP-57 |
| RG-1.06/07/08 | Adresse prospect exclusive de livraison/facturation (CHECK) | `ClientAddressTest::testProspectAddressCannotBeDelivery` ; `::testProspectAddressCannotBeBilling` | **ERP-60** |
| RG-1.09 | Code postal `^[0-9]{4,5}$` → 422 | `ClientSubResourceApiTest::testPostAddressWithInvalidPostalCodeReturns422` | ERP-57 |
| RG-1.10 | ≥ 1 site sur adresse → 422 | `ClientSubResourceApiTest::testPostAddressWithoutSiteReturns422` | ERP-57 |
| RG-1.11 | billingEmail obligatoire ssi isBilling (CHECK) | `ClientAddressTest::testBillingAddressRequiresBillingEmail` ; `::testNonBillingAddressRejectsBillingEmail` | **ERP-60** |
| RG-1.12 | Virement → banque obligatoire → 422 | `ClientProcessorTest::testVirementWithoutBankIsUnprocessable` ; `::testVirementWithBankPasses` (unit) | ERP-55 |
| RG-1.13 | LCR → ≥ 1 RIB ; DELETE dernier RIB en LCR → 409 | `ClientProcessorTest::testLcrWithoutRibIsUnprocessable` / `::testLcrWithRibPasses` (unit) ; `ClientSubResourceApiTest::testDeleteLastRibUnderLcrReturns409` / `::testDeleteRibNonLcrReturns204` | ERP-55 / ERP-57 |
| RG-1.14 | ≥ 1 bloc Contact pour finaliser l'onglet | **Front-driven (pas de state machine back).** Back voisin : `ClientSubResourceApiTest::testDeleteLastContactReturns409` | ERP-57 |
| RG-1.15 | ~~Unicité SIREN~~ supprimée (Q4) — SIREN partageable | `ClientUniquenessTest::testDuplicateSirenIsAllowed` ; `ClientMigrationTest::testNoSirenOrEmailUniqueIndex` | **ERP-60** |
| RG-1.16 | companyName unique (case-insensitive) parmi actifs → 409 | `ClientApiTest::testPostDuplicateCompanyNameReturns409` ; `ClientMigrationTest::testCompanyNameActivePartialIndexExistsExactlyOnce` | ERP-55 / **ERP-60** |
| RG-1.17 | ~~Unicité email~~ supprimée (Q4) — email partageable | `ClientUniquenessTest::testDuplicateEmailIsAllowed` ; `ClientMigrationTest::testNoSirenOrEmailUniqueIndex` | **ERP-60** |
| RG-1.18 | companyName upper-cased serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testCompanyNameIsUppercased` (unit) | ERP-55 |
| RG-1.19 | firstName/lastName capitalize serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testPersonNameIsTitleCased` (unit) ; `ClientSubResourceApiTest::testPostContactNormalizesFields` | ERP-55 / ERP-57 |
| RG-1.20 | Téléphones chiffres-seuls serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testPhoneKeepsOnlyDigits` (unit) ; `ClientFormulaireMainTest::testPostPersistsSecondaryPhoneNormalized` (secondary) | ERP-55 / **ERP-60** |
| RG-1.21 | email lowercase serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testEmailIsLowercased` (unit) ; `ClientSubResourceApiTest::testPostContactNormalizesFields` / `::testPostAddressNormalizesBillingEmail` | ERP-55 / ERP-57 |
| RG-1.22 | Archive : permission `archive` + archivedAt + aucun autre champ | `ClientApiTest::testPatchArchiveSetsArchivedAtThenRestore` ; `::testPatchArchiveWithOtherFieldReturns422` ; `ClientProcessorTest` (unit, gating archive) | ERP-55 |
| RG-1.23 | Restauration : archivedAt=null ; **409 si conflit d'unicité** | `ClientApiTest::testPatchArchiveSetsArchivedAtThenRestore` (cas nominal) ; **`ClientArchiveTest::testRestoreConflictReturns409`** (409 restauration, gap P1) | ERP-55 / **ERP-60** |
| RG-1.24 | Liste exclut les archivés par défaut | `ClientApiTest::testListSortedByCompanyNameAscAndExcludesArchived` | ERP-55 |
| RG-1.25 | `?includeArchived=true` inclut les archivés | `ClientApiTest::testListIncludeArchivedReturnsArchived` | ERP-55 |
| RG-1.26 | Tri par défaut companyName ASC | `ClientApiTest::testListSortedByCompanyNameAscAndExcludesArchived` | ERP-55 |
| RG-1.27 | Timestampable/Blamable : created* figés, updated* mis à jour | `ClientAuditTest::testCreatedFrozenAndUpdatedByReflectsModifier` | **ERP-60** |
| RG-1.28 | PATCH multi-groupes sans permission → 403 strict (tout le payload) | `ClientProcessorTest::testStrictMixWithAccountingFieldIsForbidden` / `::testAccountingFieldWithoutPermissionIsForbidden` (unit) ; **`ClientPatchStrictTest::testMixedGroupsPatchWithoutAccountingPermissionIsForbidden`** (fonctionnel) | ERP-55 / **ERP-60** |
| RG-1.29 | Catégorie d'adresse limitée aux types SECTEUR/AUTRE | **Filtrage LECTURE = front-driven** (SearchFilter `GET /api/categories?categoryType.code[]=…`). **Validation ÉCRITURE (POST/PATPH catégorie DISTRIBUTEUR/COURTIER → 422) NON IMPLÉMENTÉE côté back au M1** (absente du `ClientAddressProcessor` et de la liste § 8.1). → voir « Gaps & suivi » | — (gap) |
## Couvertures transverses
| Sujet | Test(s) | Source |
|-------|---------|--------|
| Audit iban/bic présents dans le diff (pas d'`#[AuditIgnore]`) | `ClientAuditTest::testRibCreateAuditIncludesIbanAndBic` | **ERP-60** |
| Sécurité générique : 401 anonyme + 403 sans `commercial.clients.view` | `ClientSecurityTest` (collection + détail) ; `ClientExportControllerTest::testForbiddenWithoutClientsViewPermission` / `::testUnauthorizedWhenAnonymous` | **ERP-60** / ERP-58 |
| Migration : index partiel unique présent (1 seul), pas de siren/email unique | `ClientMigrationTest` | **ERP-60** |
| Référentiels comptables read-only (405 écriture, 401/403) | `ReferentialApiTest` | ERP-56 |
| Export XLSX (colonnes accounting selon permission, 401/403) | `ClientExportControllerTest` | ERP-58 |
## Délégué à ERP-74 (#493) — NE PAS faire dans ERP-60
- **Matrice RBAC différenciée** par rôle métier (Bureau / Compta / Commerciale /
Usine) : 200/403 par verbe et par onglet selon le rôle.
- **RG-1.04 fonctionnel** : PATCH onglet Information par une Commerciale avec
champs incomplets → 422 ; même PATCH par Admin → 200 (+ durcissement code/spec).
- Raison : ces rôles métier ne sont seedés qu'après le merge de la stack M1.
## Gaps & suivi
- **RG-1.29 (validation écriture)** : refuser une catégorie de type
`DISTRIBUTEUR`/`COURTIER` sur une `ClientAddress` (→ 422, violation
`categories`) n'est pas implémenté au M1. La spec § 8.1 ne le liste pas comme
cas de test back ; le filtrage de lecture est front-driven. **Suggestion** :
ouvrir un follow-up (durcissement `ClientAddressProcessor`) ou l'intégrer à
ERP-74. Aucune invention de feature dans ERP-60 (ticket test-only).
- **Violations CHECK → statut HTTP** : les CHECK d'adresse (RG-1.06/07/08/11)
sont aujourd'hui rejetées par la base (statut ≥ 400) mais sans mapping fin
vers 422 (pas d'`exception_to_status` ni de listener DBAL→HTTP). Les tests
ERP-60 assertent donc le **rejet** (≥ 400). Un mapping explicite vers 422
serait une amélioration UX d'API (follow-up possible).
@@ -1,149 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
use App\Module\Sites\Domain\Entity\Site;
/**
* Tests fonctionnels de l'onglet Adresse — combler les trous (ERP-60).
*
* RG-1.09 (code postal) et RG-1.10 (>= 1 site) sont DEJA couverts par
* ClientSubResourceApiTest (ERP-57) et ne sont pas reduplique ici. Ce fichier
* cible les contraintes CHECK BDD non encore testees :
* - RG-1.06 / RG-1.07 / RG-1.08 : `chk_client_address_prospect_exclusive`
* (is_prospect exclusif de is_delivery / is_billing) ;
* - RG-1.11 : `chk_client_address_billing_email` (billing_email obligatoire
* ssi is_billing).
*
* Note : ces regles sont portees par des CHECK Postgres (pas d'Assert ni de
* regle Processor au M1). On verifie donc que la combinaison invalide est
* REJETEE par le serveur (statut >= 400), sans coupler le test au code exact :
* une violation CHECK non mappee remonte aujourd'hui en erreur serveur ; un
* mapping fin vers 422 serait une amelioration ulterieure (hors perimetre
* ERP-60, test-only).
*
* RG-1.29 (filtrage du type de categorie SECTEUR/AUTRE sur une adresse) n'est
* PAS testee : la validation d'ecriture correspondante n'est pas implementee
* cote back au M1 (et ne figure pas dans la liste § 8.1). Documentee comme gap
* dans le cahier de test #478.
*
* @internal
*/
final class ClientAddressTest extends AbstractCommercialApiTestCase
{
private const string LD = 'application/ld+json';
/**
* RG-1.06 / RG-1.07 : une adresse de prospection ne peut pas etre une
* adresse de livraison (CHECK chk_client_address_prospect_exclusive).
*/
public function testProspectAddressCannotBeDelivery(): void
{
$this->skipIfSitesModuleDisabled();
$client = $this->createAdminClient();
$seed = $this->seedClient('Prospect Delivery');
$response = $client->request('POST', '/api/clients/'.$seed->getId().'/addresses', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'isProspect' => true,
'isDelivery' => true,
'postalCode' => '86100',
'city' => 'Châtellerault',
'street' => '1 rue du Test',
'sites' => [$this->firstSiteIri()],
],
]);
self::assertGreaterThanOrEqual(400, $response->getStatusCode());
}
/**
* RG-1.06 / RG-1.08 : une adresse de prospection ne peut pas etre une
* adresse de facturation (meme CHECK). On fournit billingEmail pour que la
* seule violation possible soit l'exclusivite prospect/billing.
*/
public function testProspectAddressCannotBeBilling(): void
{
$this->skipIfSitesModuleDisabled();
$client = $this->createAdminClient();
$seed = $this->seedClient('Prospect Billing');
$response = $client->request('POST', '/api/clients/'.$seed->getId().'/addresses', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'isProspect' => true,
'isBilling' => true,
'billingEmail' => 'facturation@test.fr',
'postalCode' => '86100',
'city' => 'Châtellerault',
'street' => '1 rue du Test',
'sites' => [$this->firstSiteIri()],
],
]);
self::assertGreaterThanOrEqual(400, $response->getStatusCode());
}
/**
* RG-1.11 : une adresse de facturation exige un billingEmail
* (CHECK chk_client_address_billing_email).
*/
public function testBillingAddressRequiresBillingEmail(): void
{
$this->skipIfSitesModuleDisabled();
$client = $this->createAdminClient();
$seed = $this->seedClient('Billing No Email');
$response = $client->request('POST', '/api/clients/'.$seed->getId().'/addresses', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'isBilling' => true,
'postalCode' => '86100',
'city' => 'Châtellerault',
'street' => '1 rue du Test',
'sites' => [$this->firstSiteIri()],
],
]);
self::assertGreaterThanOrEqual(400, $response->getStatusCode());
}
/**
* RG-1.11 (sens inverse) : une adresse NON facturable ne peut pas porter un
* billingEmail (meme CHECK).
*/
public function testNonBillingAddressRejectsBillingEmail(): void
{
$this->skipIfSitesModuleDisabled();
$client = $this->createAdminClient();
$seed = $this->seedClient('Non Billing With Email');
$response = $client->request('POST', '/api/clients/'.$seed->getId().'/addresses', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'isBilling' => false,
'billingEmail' => 'parasite@test.fr',
'postalCode' => '86100',
'city' => 'Châtellerault',
'street' => '1 rue du Test',
'sites' => [$this->firstSiteIri()],
],
]);
self::assertGreaterThanOrEqual(400, $response->getStatusCode());
}
/**
* Retourne l'IRI du premier site seede (fixtures Sites).
*/
private function firstSiteIri(): string
{
$site = $this->getEm()->getRepository(Site::class)->findOneBy([]);
self::assertNotNull($site, 'Aucun site seede : impossible de tester les adresses.');
return '/api/sites/'.$site->getId();
}
}
@@ -1,47 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
/**
* Tests d'archivage / restauration — combler les trous (ERP-60).
*
* Le cas nominal RG-1.22 (archive pose archivedAt) + RG-1.23 (restauration
* repasse archivedAt a null) ainsi que le 422 « archive + autre champ » sont
* DEJA couverts par ClientApiTest (ERP-55). Ce fichier cible le trou identifie
* en revue (P1 review ERP-55) : le 409 de RESTAURATION en conflit d'unicite.
*
* @internal
*/
final class ClientArchiveTest extends AbstractCommercialApiTestCase
{
private const string MERGE = 'application/merge-patch+json';
/**
* RG-1.23 : restaurer un client archive dont le nom a ete repris par un
* client actif entre-temps doit echouer en 409 (l'index partiel
* uq_client_company_name_active n'admet qu'un seul actif portant ce nom).
*
* Scenario :
* 1. un client « ACME CONFLICT » est archive (donc hors index partiel) ;
* 2. un autre client actif « ACME CONFLICT » est cree (autorise tant que le
* premier reste archive) ;
* 3. la restauration du premier le rendrait actif -> collision d'unicite
* -> ClientProcessor traduit la UniqueConstraintViolationException en 409.
*/
public function testRestoreConflictReturns409(): void
{
$client = $this->createAdminClient();
$archived = $this->seedClient('Acme Conflict', true);
$this->seedClient('Acme Conflict', false);
$client->request('PATCH', '/api/clients/'.$archived->getId(), [
'headers' => ['Content-Type' => self::MERGE],
'json' => ['isArchived' => false],
]);
self::assertResponseStatusCodeSame(409);
}
}
@@ -1,142 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
use App\Module\Commercial\Domain\Entity\Client as ClientEntity;
use DateTimeImmutable;
use Doctrine\DBAL\Connection;
/**
* Tests Audit + Timestampable/Blamable du repertoire clients (ERP-60).
*
* Couvre :
* - RG-1.27 : createdAt / createdBy figes au POST, updatedBy reflete bien
* l'auteur de la modification (POST admin puis PATCH par un autre user) ;
* - Audit (§ 6.1) : le RIB est `#[Auditable]` SANS `#[AuditIgnore]` sur iban /
* bic — ces champs sensibles DOIVENT donc apparaitre dans le diff audite
* (decision Matthieu, revue MR 29/05/2026).
*
* @internal
*/
final class ClientAuditTest extends AbstractCommercialApiTestCase
{
private const string LD = 'application/ld+json';
private const string MERGE = 'application/merge-patch+json';
private const string RIB_TYPE = 'commercial.ClientRib';
private const string VALID_IBAN = 'FR1420041010050500013M02606';
private const string VALID_BIC = 'BNPAFRPPXXX';
private ?Connection $auditConnection = null;
protected function setUp(): void
{
parent::setUp();
self::bootKernel();
/** @var Connection $conn */
$conn = self::getContainer()->get('doctrine.dbal.audit_connection');
$this->auditConnection = $conn;
}
protected function tearDown(): void
{
if (null !== $this->auditConnection) {
$this->auditConnection->close();
}
parent::tearDown();
}
/**
* RG-1.27 : createdAt / createdBy sont poses au POST puis figes ; updatedBy
* suit l'auteur de la derniere modification. On cree en admin puis on
* modifie avec un user `commercial.clients.manage` distinct : createdBy reste
* l'admin, updatedBy devient le manager, createdAt ne bouge pas.
*/
public function testCreatedFrozenAndUpdatedByReflectsModifier(): void
{
// 1. User modificateur (non-admin) cree AVANT le reboot de kernel induit
// par les clients authentifies suivants ; il est persiste en base.
$manageCreds = $this->createUserWithPermission('commercial.clients.manage');
// 2. Creation en admin (createdBy = admin).
$admin = $this->createAdminClient();
$cat = $this->createCategory('SECTEUR');
$created = $admin->request('POST', '/api/clients', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'companyName' => 'Blamable Co',
'firstName' => 'A',
'phonePrimary' => '0102030405',
'email' => 'blamable@test.fr',
'categories' => ['/api/categories/'.$cat->getId()],
],
])->toArray();
self::assertResponseStatusCodeSame(201);
$id = (int) $created['id'];
$createdAtTs = new DateTimeImmutable((string) $created['createdAt'])->getTimestamp();
// 3. Modification par le manager (updatedBy = manager).
$manage = $this->authenticatedClient($manageCreds['username'], $manageCreds['password']);
$manage->request('PATCH', '/api/clients/'.$id, [
'headers' => ['Content-Type' => self::MERGE],
'json' => ['companyName' => 'Blamable Renamed'],
]);
self::assertResponseStatusCodeSame(200);
// 4. Verification cote base (etat re-charge depuis la BDD).
$em = $this->getEm();
$em->clear();
$reloaded = $em->getRepository(ClientEntity::class)->find($id);
self::assertNotNull($reloaded);
self::assertSame('admin', $reloaded->getCreatedBy()?->getUserIdentifier(), 'createdBy doit rester l\'admin createur.');
self::assertSame(
$manageCreds['username'],
$reloaded->getUpdatedBy()?->getUserIdentifier(),
'updatedBy doit refleter le dernier modificateur.',
);
self::assertSame($createdAtTs, $reloaded->getCreatedAt()?->getTimestamp(), 'createdAt doit etre fige au POST.');
self::assertNotNull($reloaded->getUpdatedAt());
self::assertGreaterThanOrEqual($createdAtTs, $reloaded->getUpdatedAt()->getTimestamp());
}
/**
* Audit § 6.1 : la creation d'un RIB produit une ligne audit_log
* `commercial.ClientRib` / `create` dont le snapshot contient iban et bic
* (champs volontairement NON ignores).
*/
public function testRibCreateAuditIncludesIbanAndBic(): void
{
$admin = $this->createAdminClient();
$seed = $this->seedClient('Rib Audit Host');
$rib = $admin->request('POST', '/api/clients/'.$seed->getId().'/ribs', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'label' => 'Compte audite',
'bic' => self::VALID_BIC,
'iban' => self::VALID_IBAN,
],
])->toArray();
self::assertResponseStatusCodeSame(201);
$rows = $this->auditConnection->fetchAllAssociative(
'SELECT changes FROM audit_log '
.'WHERE entity_type = :type AND entity_id = :id AND action = :action '
.'ORDER BY performed_at DESC',
['type' => self::RIB_TYPE, 'id' => (string) $rib['id'], 'action' => 'create'],
);
self::assertGreaterThanOrEqual(1, count($rows), 'Un audit_log "create" doit etre genere pour le RIB.');
/** @var array<string, mixed> $changes */
$changes = json_decode((string) $rows[0]['changes'], true, flags: JSON_THROW_ON_ERROR);
self::assertArrayHasKey('iban', $changes, 'iban doit figurer dans le diff audite (pas d\'AuditIgnore).');
self::assertArrayHasKey('bic', $changes, 'bic doit figurer dans le diff audite (pas d\'AuditIgnore).');
self::assertSame(self::VALID_IBAN, $changes['iban']);
self::assertSame(self::VALID_BIC, $changes['bic']);
}
}
@@ -1,84 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
use App\Module\Commercial\Domain\Entity\Client as ClientEntity;
/**
* Tests fonctionnels du formulaire principal — combler les trous (ERP-60).
*
* RG-1.01 (prenom OU nom obligatoire) et RG-1.03 (distributor/broker exclusifs
* + type de categorie) sont DEJA couverts par ClientApiTest (ERP-55) : on ne les
* reduplique pas ici. Ce fichier ne couvre que RG-1.02 (telephone secondaire),
* non encore testee.
*
* @internal
*/
final class ClientFormulaireMainTest extends AbstractCommercialApiTestCase
{
private const string LD = 'application/ld+json';
/**
* RG-1.02 : le telephone secondaire est optionnel mais persiste (2 colonnes
* distinctes). Verifie aussi la normalisation chiffres-seuls (RG-1.20) sur
* la colonne secondaire.
*/
public function testPostPersistsSecondaryPhoneNormalized(): void
{
$client = $this->createAdminClient();
$cat = $this->createCategory('SECTEUR');
$data = $client->request('POST', '/api/clients', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'companyName' => 'Two Phones SARL',
'firstName' => 'A',
'phonePrimary' => '06.12.34.56.78',
'phoneSecondary' => '05 49 00 11 22',
'email' => 'twophones@test.fr',
'categories' => ['/api/categories/'.$cat->getId()],
],
])->toArray();
self::assertResponseStatusCodeSame(201);
self::assertSame('0612345678', $data['phonePrimary']);
self::assertSame('0549001122', $data['phoneSecondary']);
}
/**
* RG-1.02 : maximum 2 telephones — le modele n'expose que phonePrimary et
* phoneSecondary. Un eventuel 3e champ envoye par un appel API direct est
* ignore (aucune 3e colonne), il ne peut donc pas creer un troisieme numero.
*/
public function testThirdPhoneFieldIsIgnored(): void
{
$client = $this->createAdminClient();
$cat = $this->createCategory('SECTEUR');
$data = $client->request('POST', '/api/clients', [
'headers' => ['Content-Type' => self::LD],
'json' => [
'companyName' => 'Third Phone SARL',
'firstName' => 'A',
'phonePrimary' => '0612345678',
'phoneSecondary' => '0549001122',
'phoneTertiary' => '0700000000',
'email' => 'thirdphone@test.fr',
'categories' => ['/api/categories/'.$cat->getId()],
],
])->toArray();
self::assertResponseStatusCodeSame(201);
// Le champ inconnu est ignore par le denormaliseur : il n'apparait pas
// dans la representation et n'a pas ete persiste.
self::assertArrayNotHasKey('phoneTertiary', $data);
// Confirmation cote base : seules les 2 colonnes telephone existent.
$persisted = $this->getEm()->getRepository(ClientEntity::class)->find($data['id']);
self::assertNotNull($persisted);
self::assertSame('0612345678', $persisted->getPhonePrimary());
self::assertSame('0549001122', $persisted->getPhoneSecondary());
}
}
@@ -1,67 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
/**
* Tests de structure / migration M1 (ERP-60).
*
* Verifie la decision Q4 (29/05/2026) au niveau du schema Postgres :
* - l'unique index partiel fonctionnel uq_client_company_name_active existe
* (un seul, sur LOWER(company_name), partiel sur les actifs non archives /
* non supprimes) — seule unicite metier conservee (RG-1.16) ;
* - les anciens index uq_client_siren_active (RG-1.15) et uq_client_email_active
* (RG-1.17) ont ete supprimes / ne sont jamais crees.
*
* @internal
*/
final class ClientMigrationTest extends AbstractCommercialApiTestCase
{
public function testCompanyNameActivePartialIndexExistsExactlyOnce(): void
{
$rows = $this->clientIndexes();
$companyNameIndexes = array_filter(
$rows,
static fn (array $r): bool => 'uq_client_company_name_active' === $r['indexname'],
);
self::assertCount(
1,
$companyNameIndexes,
'Il doit exister exactement UN index uq_client_company_name_active.',
);
// Confirme la nature fonctionnelle (LOWER) + partielle (WHERE) de l'index.
// Postgres serialise l'expression sous la forme `lower((company_name)::text)`,
// d'ou des verifications de sous-chaines distinctes.
$def = strtolower((string) array_values($companyNameIndexes)[0]['indexdef']);
self::assertStringContainsString('unique', $def);
self::assertStringContainsString('lower', $def);
self::assertStringContainsString('company_name', $def);
self::assertStringContainsString('where', $def, 'L\'index doit etre partiel (clause WHERE sur les actifs).');
}
public function testNoSirenOrEmailUniqueIndex(): void
{
$names = array_map(static fn (array $r): string => $r['indexname'], $this->clientIndexes());
// RG-1.15 / RG-1.17 supprimees (Q4) : aucun index unique siren / email.
self::assertNotContains('uq_client_siren_active', $names);
self::assertNotContains('uq_client_email_active', $names);
}
/**
* @return list<array{indexname: string, indexdef: string}>
*/
private function clientIndexes(): array
{
self::bootKernel();
/** @var list<array{indexname: string, indexdef: string}> $rows */
return $this->getEm()->getConnection()->fetchAllAssociative(
"SELECT indexname, indexdef FROM pg_indexes WHERE schemaname = 'public' AND tablename = 'client'",
);
}
}
@@ -1,52 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
use App\Module\Commercial\Domain\Entity\Client as ClientEntity;
/**
* Test fonctionnel du mode strict PATCH multi-groupes (RG-1.28) — ERP-60.
*
* Le cas est deja couvert en unitaire (ClientProcessorTest) ; on en ajoute la
* preuve fonctionnelle HTTP, SANS dependre d'un role metier : un utilisateur
* portant `commercial.clients.manage` mais PAS `commercial.clients.accounting.manage`
* qui envoie un PATCH melant un champ principal (companyName) et un champ
* comptable (siren) recoit un 403 sur l'ENSEMBLE du payload — aucun champ n'est
* applique (pas de filtrage silencieux).
*
* ⚠ La matrice differenciee par role metier (Bureau / Compta / Commerciale) est
* DELEGUEE a ERP-74 (#493). Ici on n'utilise qu'un user mono-permission.
*
* @internal
*/
final class ClientPatchStrictTest extends AbstractCommercialApiTestCase
{
private const string MERGE = 'application/merge-patch+json';
public function testMixedGroupsPatchWithoutAccountingPermissionIsForbidden(): void
{
$seed = $this->seedClient('Strict Mix');
$credentials = $this->createUserWithPermission('commercial.clients.manage');
$client = $this->authenticatedClient($credentials['username'], $credentials['password']);
$client->request('PATCH', '/api/clients/'.$seed->getId(), [
'headers' => ['Content-Type' => self::MERGE],
'json' => [
'companyName' => 'Renamed Strict',
'siren' => '123456789',
],
]);
// RG-1.28 : 403 strict (le champ comptable siren exige accounting.manage).
self::assertResponseStatusCodeSame(403);
// Aucun champ applique : le companyName d'origine est intact.
$em = $this->getEm();
$em->clear();
$reloaded = $em->getRepository(ClientEntity::class)->find($seed->getId());
self::assertNotNull($reloaded);
self::assertSame('STRICT MIX', $reloaded->getCompanyName());
}
}
@@ -1,57 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
/**
* Tests de securite GENERIQUE de /api/clients (ERP-60).
*
* Couvre les garde-fous non dependants des roles metier :
* - 401 si requete anonyme (firewall JWT) ;
* - 403 si l'utilisateur authentifie ne porte pas `commercial.clients.view`.
*
* ⚠ La matrice RBAC differenciee par role metier (bureau / compta / commerciale
* / usine) et le test fonctionnel RG-1.04 sont DELEGUES a ERP-74 (#493) : ils
* exigent les roles seedes apres le merge de la stack. NE PAS les ajouter ici.
*
* @internal
*/
final class ClientSecurityTest extends AbstractCommercialApiTestCase
{
private const string LD = 'application/ld+json';
public function testAnonymousGetCollectionReturns401(): void
{
$client = self::createClient();
$client->request('GET', '/api/clients', ['headers' => ['Accept' => self::LD]]);
self::assertResponseStatusCodeSame(401);
}
public function testAnonymousGetItemReturns401(): void
{
$seed = $this->seedClient('Anon Item');
$client = self::createClient();
$client->request('GET', '/api/clients/'.$seed->getId(), ['headers' => ['Accept' => self::LD]]);
self::assertResponseStatusCodeSame(401);
}
public function testForbiddenWithoutClientsViewPermission(): void
{
// User authentifie portant une permission SANS rapport avec les clients.
$seed = $this->seedClient('Forbidden Target');
$credentials = $this->createUserWithPermission('core.users.view');
$client = $this->authenticatedClient($credentials['username'], $credentials['password']);
// Collection.
$client->request('GET', '/api/clients', ['headers' => ['Accept' => self::LD]]);
self::assertResponseStatusCodeSame(403);
// Detail.
$client->request('GET', '/api/clients/'.$seed->getId(), ['headers' => ['Accept' => self::LD]]);
self::assertResponseStatusCodeSame(403);
}
}
@@ -1,73 +0,0 @@
<?php
declare(strict_types=1);
namespace App\Tests\Module\Commercial\Api;
use App\Module\Commercial\Domain\Entity\Client as ClientEntity;
/**
* Tests d'unicite — combler les trous (ERP-60).
*
* RG-1.16 (doublon de companyName parmi les actifs -> 409) est DEJA couvert par
* ClientApiTest::testPostDuplicateCompanyNameReturns409 (ERP-55). Ce fichier
* verifie l'envers de la decision Q4 (29/05/2026) : le SIREN (RG-1.15 supprimee)
* et l'email (RG-1.17 supprimee) NE SONT PLUS contraints uniques.
*
* @internal
*/
final class ClientUniquenessTest extends AbstractCommercialApiTestCase
{
private const string LD = 'application/ld+json';
/**
* RG-1.16 / RG-1.17 (Q4) : deux clients actifs peuvent partager le meme
* email principal — aucune contrainte d'unicite (un email peut servir
* plusieurs clients).
*/
public function testDuplicateEmailIsAllowed(): void
{
$client = $this->createAdminClient();
$cat = $this->createCategory('SECTEUR');
$iri = '/api/categories/'.$cat->getId();
$payload = static fn (string $name): array => [
'companyName' => $name,
'firstName' => 'A',
'phonePrimary' => '0102030405',
'email' => 'partage@test.fr',
'categories' => [$iri],
];
$client->request('POST', '/api/clients', ['headers' => ['Content-Type' => self::LD], 'json' => $payload('Email Share One')]);
self::assertResponseStatusCodeSame(201);
// Meme email, nom different -> doit passer (pas d'index unique email).
$client->request('POST', '/api/clients', ['headers' => ['Content-Type' => self::LD], 'json' => $payload('Email Share Two')]);
self::assertResponseStatusCodeSame(201);
}
/**
* RG-1.15 (Q4) : deux clients peuvent partager le meme SIREN (etablissements
* multiples). Le SIREN n'est pas ecrivable au POST (groupe accounting), on
* seede donc directement via l'ORM et on prouve que le flush ne leve aucune
* violation d'unicite.
*/
public function testDuplicateSirenIsAllowed(): void
{
// Boot kernel pour disposer de l'EM (pas d'appel HTTP necessaire ici).
self::bootKernel();
$em = $this->getEm();
$one = $this->seedClient('Siren Share One');
$two = $this->seedClient('Siren Share Two');
$one->setSiren('123456789');
$two->setSiren('123456789');
$em->flush();
// Aucune exception : preuve qu'il n'existe pas d'index unique sur siren.
self::assertSame('123456789', $em->getRepository(ClientEntity::class)->find($one->getId())->getSiren());
self::assertSame('123456789', $em->getRepository(ClientEntity::class)->find($two->getId())->getSiren());
}
}