Configurer les rôles et leurs capacités

Critère d'acceptation de WP-01 resté sans écran : « un rôle personnalisé créé
par un client modifie effectivement l'accès, sans changement de code ». Le
catalogue de capacités existait, l'autorisation s'y adossait déjà, mais seul le
semis pouvait attribuer quoi que ce soit.

Deux dangers opposés, et il faut se protéger des deux. L'escalade d'abord : on
ne peut accorder qu'une capacité qu'on détient soi-même, sans quoi la première
personne autorisée à éditer un rôle s'accorde l'accès aux rémunérations en
trois clics et le catalogue ne sert plus à rien. Le retrait, lui, reste permis
même sur une capacité qu'on n'a pas — réduire un droit n'a jamais élargi le
sien, et l'interdire empêcherait de corriger un rôle trop large.

Le verrouillage ensuite : au moins un rôle doit conserver la gestion des
droits. La condition se juge sur l'ensemble des rôles après coup, non sur celui
qu'on édite — ce qui compte n'est pas que ce rôle-ci garde la capacité, mais
qu'un rôle la garde. Sans cela une organisation se fermerait dehors, et le seul
recours serait une intervention en base.

Un rôle naît sans aucune capacité : en hériter de celles de son créateur
distribuerait des droits que personne n'a demandés. Le niveau propriétaire se
délègue à part. Un rôle système ne se supprime pas, un rôle attribué non plus —
ses membres se retrouveraient dehors sans que personne l'ait décidé pour eux.

Le test va jusqu'au bout : créer le rôle, l'attribuer, se connecter, constater
qu'un écran s'ouvre et qu'un autre reste fermé. S'arrêter à « la case est
cochée » n'aurait rien dit du critère.

Trois défauts d'isolation des tests corrigés au passage, tous du même genre —
un état qui s'accumule d'une exécution à l'autre :

- la file des congés désignait « la première ligne de ce salarié » pour son
  nettoyage, et tombait sur une ligne laissée par un passage antérieur ;
- l'écran de conservation tronquait à quarante pièces triées par ancienneté,
  faisant disparaître les pièces échues derrière celles dont il n'y a rien à
  dire — corrigé dans le produit, pas seulement dans le test ;
- le test de verrouillage de période consommait un mois par exécution sans
  jamais le rendre.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv

tests/e2e/support/db.ts

@@ -62,3 +62,31 @@ export async function backdateDocument(
     await tx.$executeRaw`UPDATE "Document" SET "uploadedAt" = ${uploadedAt} WHERE id = ${found.id}`;
   });
 }
+
+/**
+ * Attribue un rôle à un membership, par son libellé.
+ *
+ * Aucun écran d'affectation n'existe encore : sans ce levier, l'effet d'un rôle
+ * personnalisé — le critère d'acceptation de WP-01 — resterait invérifiable.
+ */
+export async function assignRole(
+  membershipId: string,
+  roleName: string,
+): Promise<void> {
+  const rows = await db().$queryRaw<Array<{ id: string; accountId: string }>>`
+    SELECT id, "accountId" FROM "Role" WHERE name = ${roleName} LIMIT 1
+  `;
+  const role = rows[0];
+  if (!role) throw new Error(`Rôle introuvable : ${roleName}`);
+
+  const updated = await db().$transaction(async (tx) => {
+    await tx.$executeRaw`SELECT set_config('app.account_id', ${role.accountId}, true)`;
+    return tx.$executeRaw`UPDATE "Membership" SET "roleId" = ${role.id} WHERE id = ${membershipId}`;
+  });
+
+  // Une mise à jour qui ne touche aucune ligne est indiscernable d'un succès :
+  // le test échouerait bien plus loin, sur un refus d'accès inexpliqué.
+  if (updated === 0) {
+    throw new Error(`Aucun membership mis à jour : ${membershipId}`);
+  }
+}