1888b70623
Auto Tag Develop / tag (push) Successful in 11s
## Contexte
ERP-102 — Découvert pendant ERP-64. Connecté avec un rôle **métier** (bureau / compta / commerciale), `GET /api/categories` et `GET /api/sites` renvoient **403**, alors que `/tva_modes`, `/payment_delays`, `/payment_types`, `/banks` renvoient 200.
Conséquences : page **Création client** inutilisable (le `Promise.all` rejetait → **tous** les selects vides) et **filtres Catégories/Sites vides** au répertoire.
## Cause
La `security` des `GetCollection`/`Get` de `Category` et `Site` exigeait `catalog.categories.view` / `sites.view` — permissions d'**administration** du Catalogue / des Sites. Or ces référentiels sont **transverses** : tout rôle qui gère un tiers doit pouvoir les lire.
## Correctif back — Option C (permission de lecture-référentiel dédiée)
Choix d'archi retenu parmi les 3 du ticket :
- **Pourquoi pas A** (`... or is_granted('commercial.clients.view')`) : coupler `Category`/`Site` à une permission **Commercial** viole l'esprit de la règle ABSOLUE n°1 et ne scale pas (M2 Fournisseurs devrait rajouter un OR).
- **Pourquoi pas B** (donner `.view` aux rôles métier) : `.view` = accès admin → items sidebar admin Catégories/Sites exposés à une commerciale.
- **C** : nouvelle permission `catalog.categories.read_ref` / `sites.read_ref`, distincte de `.view` (pas d'item sidebar) et de `.manage`. Chaque permission appartient à **son** module → isolement inter-module préservé, **réutilisable tel quel par M2 Fournisseurs**. C'est la « permission référentiel lisible » que le ticket pointe lui-même.
Détail :
- `CatalogModule` / `SitesModule` : déclaration des deux permissions `read_ref`.
- `Category` / `Site` : security lecture (liste + item) = `view OR read_ref`.
- `RbacSeeder` (matrice § 2.7) : `read_ref` attaché à bureau / compta / commerciale ; usine reste sans accès.
## Durcissement front (résilience — requis dans tous les cas)
`useClientReferentials.loadCommon` : `Promise.all` → **`Promise.allSettled`** avec affectation isolée par référentiel. L'échec d'un endpoint ne vide plus que **son** select, plus la totalité du formulaire.
## Tests (TDD)
- `ClientRBACMatrixTest::testBusinessRolesCanReadCategoriesAndSitesReferentials` — bureau/compta/commerciale listent `/categories` et `/sites` (200), usine reste 403.
- `SitesModuleTest` — set de permissions porté à 4 codes.
- `useClientReferentials.spec` (Vitest) — un référentiel en échec ne vide que son select.
## Vérifications
- `make test` (back) : **467/467** ✓
- `make nuxt-test` (front) : **131/131** ✓
- `make php-cs-fixer` : conforme ✓
## Note miroirs RBAC
`config/sidebar.php` / `personas.ts` / `SeedE2ECommand.php` **non touchés** : `read_ref` n'ajoute aucun item sidebar, le persona E2E `user-full` lit déjà via `.view`, et aucun persona ne modélise un rôle métier seul. Pas de nouveau test E2E (règle n°7 : bug attrapé avant prod). La source de vérité de la matrice (`RbacSeeder`) est mise à jour et couverte par `ClientRBACMatrixTest`.
Closes ERP-102.
---------
Co-authored-by: Matthieu <contact@malio.fr>
Reviewed-on: #53
Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
55 lines
2.1 KiB
PHP
55 lines
2.1 KiB
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Tests\Module\Sites;
|
|
|
|
use App\Module\Sites\Infrastructure\ApiPlatform\State\Processor\SiteAwareInjectionProcessor;
|
|
use App\Module\Sites\SitesModule;
|
|
use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;
|
|
|
|
/**
|
|
* Tests structurels du module Sites : contrat `permissions()` et
|
|
* invariants d'enregistrement des services.
|
|
*
|
|
* @internal
|
|
*/
|
|
final class SitesModuleTest extends KernelTestCase
|
|
{
|
|
public function testPermissionsSetContainsExactlyFourCodes(): void
|
|
{
|
|
// Garde-fou : si quelqu'un ajoute une permission sans ajuster les
|
|
// tests ou la doc, ce test casse explicitement. Si au contraire une
|
|
// permission disparait (ex: bypass_scope retire par erreur), meme
|
|
// effet. Le set de permissions est fige par ce test.
|
|
// `sites.read_ref` ajoutee en ERP-102 (lecture-referentiel transverse).
|
|
$codes = array_column(SitesModule::permissions(), 'code');
|
|
sort($codes);
|
|
|
|
self::assertSame(
|
|
['sites.bypass_scope', 'sites.manage', 'sites.read_ref', 'sites.view'],
|
|
$codes,
|
|
);
|
|
}
|
|
|
|
public function testSiteAwareInjectionProcessorIsRegisteredAsDecoratorOfPersistProcessor(): void
|
|
{
|
|
// Garde d'integration : le ticket 4 compte sur le fait que tous
|
|
// les processors existants qui deleguent au persist processor
|
|
// (UserRbacProcessor, RoleProcessor, etc.) passent par notre
|
|
// decorator SiteAwareInjectionProcessor. Si un refactor Symfony
|
|
// change la resolution du service decore, ce test cassera en
|
|
// amont des regressions invisibles dans les tests metier.
|
|
self::bootKernel();
|
|
$container = self::getContainer();
|
|
|
|
$persistProcessor = $container->get('api_platform.doctrine.orm.state.persist_processor');
|
|
|
|
self::assertInstanceOf(
|
|
SiteAwareInjectionProcessor::class,
|
|
$persistProcessor,
|
|
'Le service api_platform.doctrine.orm.state.persist_processor doit etre decore par SiteAwareInjectionProcessor (#[AsDecorator]).',
|
|
);
|
|
}
|
|
}
|