[ERP-59] Déclarer les permissions Commercial.clients + synchroniser RBAC (3 sources) #32
Reference in New Issue
Block a user
Delete Branch "feature/ERP-59-declarer-permissions-commercial-clients-rbac"
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?
Revue de code ERP-59 (déclaration des permissions Commercial.clients + synchronisation des 3 miroirs RBAC), stackée sur ERP-55.
PR propre et conforme. Points vérifiés OK :
config/sidebar.php(item + permissioncommercial.clients.view),personas.tsETSeedE2ECommand.phpmettent à jour le même personae2e.user-fullavec les 5 mêmes codes. Alignés au caractère près.view/manage(security des opérations),accounting.view(ClientReadGroupContextBuilder),accounting.manage+archive(ClientProcessor). Aucun code orphelin, aucune permission référencée manquante.CommercialModule::permissions()utilise la même forme['code','label']que Core/Catalog ;sync-permissionsvalide les clés + le préfixecommercial.et accepte sans souci les codes 4-segments (commercial.clients.accounting.view) — pas de regex stricte sur le nombre de segments.commercialactif dansconfig/modules.php→ les permissions seront bien synchronisées et le seed e2e (qui exige leur existence en base) ne lèvera pas.sidebar-visibility.spec.tsn'itère que surexpectedAdminLinks(section Administration) → l'ajout du lien dans la section Commercial ne casse aucune assertion ;expectedAdminLinksinchangé est correct.sidebar.commercial.clientsajouté.2 remarques mineures ci-dessous. Rien de bloquant.
@@ -105,1 +105,4 @@'items' => [['label' => 'sidebar.commercial.clients','to' => '/commercial/clients',Incohérence de convention de route dans la section Commercial.
Contexte : le nouvel item pointe vers
/commercial/clients(imbriqué), alors que l'item voisinsupplierspointe vers/suppliers(plat), et les items Administration vers/admin/*.Cause : côté front, le module
commercialn'expose aujourd'hui quepages/commercial.vue(→/commercial). Tant qu'ERP-73 n'a pas créé la page, le lien/commercial/clientsmènera à un 404 si on clique dessus (sans impact e2e : le test n'asserte que la présence des liens Administration, pas la navigation).Recommandation : confirmer qu'ERP-73 implémentera bien la page à l'emplacement exact
/commercial/clients(ex.pages/commercial/clients.vue), et trancher la convention du module Commercial (imbriqué/commercial/*vs plat/suppliers) pour rester cohérent. Mineur, à coordonner avec ERP-73.@@ -68,0 +70,4 @@// commerciale/usine) seedes par ERP-74. Pas de nouveau persona// (regle ABSOLUE n°7). commercial.clients.view n'ajoute pas de lien// dans la section Administration, donc expectedAdminLinks reste inchange.'commercial.clients.view',Mapping RBAC e2e volontairement grossier — gradations non couvertes jusqu'à ERP-74.
Contexte : les 5 permissions sont toutes accordées au seul persona
e2e.user-full.Cause : du coup aucun persona ne représente un utilisateur ayant
commercial.clients.view/manageSANSaccounting.manageniarchive. Or c'est précisément la différenciation que le ClientProcessor d'ERP-55 met en œuvre (gating 403 sur l'onglet Comptabilité, sur l'archivage, RG-1.28 strict). Ce comportement différentiel reste donc vérifié uniquement par les tests unitaires du Processor, pas de bout en bout.Recommandation : acceptable et déjà documenté (les vrais rôles métier bureau/compta/commerciale/usine arrivent en ERP-74). Penser à ajouter à ce moment-là un persona « view sans accounting/archive » pour exercer le gating en e2e. Aucune action requise sur cette MR.
Suite review (merci) — pas de changement back, 2 points relevant de décisions tracées :
/commercial/clients(imbriquée) vs/suppliers(plate) : 🔵 décision front, à arbitrer ensemble côté ERP-73. Tant que le modulecommercialn'expose quepages/commercial.vue, je ne change pas la route côté back sans calage front commun.view/managesansaccounting.manageniarchive) seront couvertes via ERP-74 / ERP-60. LeClientProcessordistingue déjà ces permissions ; seul le persona e2e est agrégé pour l'instant.(Branche rebasée sur la stack corrigée → nouveau SHA.)
## ERP-56 — Référentiels comptables en lecture seule Expose les 4 référentiels comptables (M1 Commercial) en **lecture seule** via API Platform. Aucune nouvelle entité ni migration : seule la couche API (`#[ApiResource]`) est ajoutée sur des entités existantes (ERP-53/54). > **Stacked PR** — base = `feature/ERP-59-declarer-permissions-commercial-clients-rbac` (la security `commercial.clients.view` est déclarée par ERP-59). ### Endpoints exposés | Méthode | URL | |---|---| | `GET` | `/api/tva_modes` · `/api/tva_modes/{id}` | | `GET` | `/api/payment_delays` · `/api/payment_delays/{id}` | | `GET` | `/api/payment_types` · `/api/payment_types/{id}` | | `GET` | `/api/banks` · `/api/banks/{id}` | OpenAPI exposée automatiquement. ### Détails techniques - **Opérations** : `GetCollection` + `Get` uniquement. Aucune écriture déclarée → `POST` / `PATCH` / `DELETE` renvoient **405**. - **Security** : `is_granted('commercial.clients.view')` au niveau opérations **et** ressource. - **Tri par défaut** : `position ASC` puis `label ASC` (spec § 4.7) via `order:` sur `GetCollection` (provider Doctrine par défaut, aligné sur le pattern `CategoryType` ERP-46 — pas de provider custom car référentiels sans filtre). - **Pagination (ERP-72)** : pagination serveur conservée sur ces collections autonomes. `paginationClientEnabled: true` par opération pour activer l'échappatoire `?pagination=false` (alimenter un `<MalioSelect>` complet). Note : `client_enabled` est `false` globalement, d'où l'activation explicite par opération. ### Tests (`tests/Module/Commercial/Api/ReferentialApiTest.php`) `make test` → **364 tests OK** (dont 21 nouveaux, 70 assertions) : - 4 endpoints → **200** avec le seed (`CommercialReferentialFixtures`) ; - tri **position ASC** vérifié + départage **label ASC** (lignes de test purgées en `tearDown`) ; - `GET` item → 200 ; - `POST` (×4) / `PATCH` / `DELETE` → **405** ; - user authentifié sans `commercial.clients.view` → **403** ; - anonyme → **401** ; - pagination serveur active (page 2 vide) + `?pagination=false` cohérent. `make php-cs-fixer-allow-risky` : clean. ### Review Reviewer souhaité : @tristan À **squash merge** (sélectionner manuellement dans l'UI Gitea). --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #34 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>Pull request closed