test(technique) : couvrir RG-3.x PHPUnit + capturer le contrat JSON (ERP-139) #100
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: MALIO-DEV/Starseed#100
Reference in New Issue
Block a user
Delete Branch "feature/ERP-139-tests-phpunit-m3"
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?
Ticket Lesstime #139 (M3 — Répertoire prestataires, position 1.9). DoD back avant le front : suite PHPUnit consolidée sur la matrice § 8.1 + captures JSON réelles dans la spec § 4.0.bis.
Contenu
provider:read:accountingajouté surTvaMode/PaymentDelay/PaymentType/Bank— sans ça elles sortaient en IRI nu dans le détail prestataire (réplique du fix ERP-92 du M2, piège #1 § 4.0.bis).ProviderSerializationContractTest(13 tests) : gating RIB/scalaires par omission, réfs compta en objet{id,code,label},isArchived, embed categories/sites liste+détail, sous-collections, enveloppe AP4 ;testDodReferenceJsonShapedumpe le JSON réel (PROVIDER_DOD_DUMP=1).ProviderAuditTest(5 tests) : create/update/archive (technique.Provider), iban/bic dans le diff (technique.ProviderRib, pas dAuditIgnore), trace M2Msites.ProviderListTestétendu :?pagination=false, anti-N+1, filtre?typeCode=PRESTATAIRE.ProviderRbacGatingTestétendu : restauration en conflit de nom → 409 (RG-3.14).ProviderFixtures(§ 8.4) : démo idempotente (complet VIREMENT+banque+RIB, LCR+RIB, CHEQUE multi-cat, minimal, archivé) répartie sur sites 86/17/82 ; skip en envtest.seedCompleteProvider; spec § 4.0.bis : gabarits remplacés par les captures réelles (liste + détail avec/sans accounting.view).Vérifications
make php-cs-fixer-allow-risky→ 0 fichiermake test→ OK, 677 tests, 3328 assertions (garde-fous globaux verts)Notes
make fixtures(autowiring vérifié).Review consolidée — stack back M3 « Prestataires » (ERP-132 → ERP-139)
Review du propre de M3 (cloisonnement site, RBAC
technique.providers.*+bypass_scope, RG-3.04/3.07/3.08). Le cœur Provider (liste/détail/écriture/export/RBAC) est solide et bien testé. Un bloquant trouvé et corrigé dansc9095ff(sur cette branche).⛔ Fuite cross-site des sous-ressources (corrigé)
Les
Get/Patch/Deletedeprovider_ribs|contacts|addresses/{id}passaient par le provider Doctrine par défaut (non cloisonné), et lePOSTrésolvait le parent sans contrôle de scope → un user cloisonné pouvait lire l'IBAN/BIC d'un RIB d'un prestataire d'un autre site, l'éditer/supprimer, ou créer une sous-ressource hors périmètre.SiteScopedQueryExtensionne filtre que lesSiteAwareInterface, ce que ces entités ne sont pas. La spec § 2.13 affirmait à tort que les sous-ressources « héritent du garde-fou parent ».Fix :
ProviderSiteScopeChecker(décision de scope centralisée, source unique) + provider décoréProviderSubResourceItemProvidersur Get/Patch/Delete (→ 404 hors périmètre) + gardeassertInScopeau POST des 3 processors. 7 nouveaux tests (ProviderSubResourceSiteScopeTest). Spec § 2.13 corrigée.🟠 RG-3.04 —
jobTitle(Fonction) (corrigé)Le CHECK +
validateNameignoraientjobTitle, alors que la spec RG-3.04 (ligne 926) liste « Fonction » → un contact avec seulement la Fonction passait le front mais récoltait un 422 (desync). Aligné le code sur la spec. Décision à valider : si tu voulais le garde-fou minimal (jobTitle exclu), c'est l'inverse à appliquer.Points positifs vérifiés
totalItemscorrect), détail 404, écriture 422 horsuser_site.priority:1, scope site, gating SIREN suraccounting.view. RBAC : 3 miroirs alignés,bypass_scopecorrect (Usine cloisonnée).🟡 Non bloquants (laissés tels quels)
paymentType=LCRsans RIB → 422 » trompeuse :paymentType ∈ write:accountingabsent du POST → le cas est structurellement un PATCH, les tests doivent cibler ça.guardLastRibDeletionUnderLcrcompte les RIB en mémoire — robuste, mais à border par un test « 1 seul RIB en base ».Suite back complète verte (685 tests OK) après fix.
Expose les sous-collections du prestataire en #[ApiResource] (POST sur le parent + PATCH/DELETE/GET unitaires), edition complete par onglet (pas de POST-only, RETEX M1/M2) : - ProviderContact : POST /providers/{id}/contacts, PATCH/DELETE /provider_contacts/{id} (security technique.providers.manage). ProviderContactProcessor : normalisation RG-3.11 (nom/prenom Title Case, telephones chiffres, email lowercase) + RG-3.04 (au moins un champ parmi prenom/nom/telephone/email, miroir du CHECK chk_provider_contact_name -> 422). - ProviderAddress : POST /providers/{id}/addresses, PATCH/DELETE /provider_addresses/{id} (security technique.providers.manage). ProviderAddressProcessor : rattachement parent + cloisonnement d'ecriture des sites de l'adresse (RG-3.05 / § 2.13 : site hors user_site -> 422 sur sites). - ProviderRib : POST /providers/{id}/ribs, PATCH/DELETE /provider_ribs/{id} (security technique.providers.accounting.manage). ProviderRibProcessor : RG-3.08 (DELETE du dernier RIB sous LCR -> 409). Tests : ProviderSubResourceApiTest (19 cas) — CRUD chaque sous-ressource, 403 selon permission (Contacts/Adresses=manage, RIB=accounting.manage), 409 dernier RIB LCR, 422 cloisonnement site adresse. Helpers addContact/addRib/paymentType ajoutes a AbstractProviderApiTestCase.Ajoute provider:read:accounting sur les réfs comptables partagées (TvaMode/PaymentDelay/PaymentType/Bank) pour embarquer {id,code,label} au lieu d un IRI nu (réplique fix ERP-92). Helper seedCompleteProvider, anti-N+1 + pagination=false + filtre typeCode, restauration conflit 409, fixtures démo idempotentes. Captures JSON réelles collées dans spec § 4.0.bis.