[Mineur] Admin : modifications de permissions perdues en cochant deux cases rapidement #157

New issue

Closed

opened 2026-10-28 10:32:29 +00:00 by asventi · 0 comments

asventi commented

2026-10-28 10:32:29 +00:00

Owner

Gravité : Mineur
Rapports QA d'origine : ADMIN-15

Détails des rapports

[ADMIN-15] Cases de permissions : modifications perdues quand on coche/décoche deux cases rapidement (calcul sur un snapshot périmé) — Gravité : Mineur

Où : /admin/roles, ligne d'un rôle
Étapes : 1. Rôle qa avec les 7 permissions 2. Cliquer très vite sur "Manage events" puis "Manage users" pour les décocher (sans attendre le toast)
Attendu : permissions finales = 124 (bits 0 et 1 retirés).
Obtenu : permission API finale = 125 : la 1re modification est écrasée par la 2e ; après refresh la case "Manage events" est de nouveau cochée alors que l'utilisateur l'avait décochée.
Preuve : sortie de scripts/admin/t8_roles_ui.py : after quick uncheck 0 and 1 -> API perm 125 expected 124. En clics séquentiels (attente 1,2 s entre chaque), les 7 permissions se cochent correctement (1,3,7,15,31,63,127) et persistent après refresh.
Cause probable : frontend/src/admin/components/AdminRoleBox.tsx:54-57 envoie RolePerm: role.permission (valeur du loader au moment du rendu) et frontend/src/admin/api/roles.ts:handleCheckbox calcule le masque absolu côté client ; l'API (PatchRolePermEndpoint) prend la valeur absolue au lieu d'un toggle atomique (même problème entre deux admins simultanés).

Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes.

**Gravité :** Mineur **Rapports QA d'origine :** ADMIN-15 ## Détails des rapports <details><summary>[ADMIN-15] Cases de permissions : modifications perdues quand on coche/décoche deux cases rapidement (calcul sur un snapshot périmé) — Gravité : Mineur</summary> - Où : /admin/roles, ligne d'un rôle - Étapes : 1. Rôle qa avec les 7 permissions 2. Cliquer très vite sur "Manage events" puis "Manage users" pour les décocher (sans attendre le toast) - Attendu : permissions finales = 124 (bits 0 et 1 retirés). - Obtenu : permission API finale = 125 : la 1re modification est écrasée par la 2e ; après refresh la case "Manage events" est de nouveau cochée alors que l'utilisateur l'avait décochée. - Preuve : sortie de `scripts/admin/t8_roles_ui.py` : `after quick uncheck 0 and 1 -> API perm 125 expected 124`. En clics séquentiels (attente 1,2 s entre chaque), les 7 permissions se cochent correctement (1,3,7,15,31,63,127) et persistent après refresh. - Cause probable : `frontend/src/admin/components/AdminRoleBox.tsx:54-57` envoie `RolePerm: role.permission` (valeur du loader au moment du rendu) et `frontend/src/admin/api/roles.ts:handleCheckbox` calcule le masque absolu côté client ; l'API (`PatchRolePermEndpoint`) prend la valeur absolue au lieu d'un toggle atomique (même problème entre deux admins simultanés). </details> --- _Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes._

asventi added the

bug

groupe/admin-ui

labels

2026-10-28 10:44:21 +00:00