[Mineur] Changement de rôle non répercuté en direct (UI de l'utilisateur, sidebar Members) #158

Closed
opened 2026-10-28 10:32:30 +00:00 by asventi · 0 comments
Owner

Gravité : Mineur
Rapports QA d'origine : ADMIN-16, ADMIN-19

Cache me d'1 h et aucun push.

Détails des rapports

[ADMIN-16] Changement de rôle non répercuté en direct dans l'UI de l'utilisateur concerné (cache `me` 1 h, aucun push) — Gravité : Mineur
  • Où : toute l'UI (sidebar Invite/Users/Roles, boutons event/channel/messages) ; API
  • Étapes : 1. User qa X (rôle HandleEvent) connecté 2. dede change son rôle (HandleUsers+InviteUser+HandleChannels+HandleRoles) via PATCH /users/{X}/role/{R} 3. Observer l'UI de X sans recharger (4 s, puis navigation SPA Calendar/Home) 4. GET /api/me de X
  • Attendu : l'UI de X affiche immédiatement les liens "Users"/"Roles" ; (et inversement disparaissent à la rétrogradation).
  • Obtenu : GET /api/me renvoie le nouveau rôle immédiatement (et l'API applique les nouvelles permissions tout de suite), mais l'UI reste inchangée (0 lien admin) après 4 s et après navigation SPA ; les liens n'apparaissent qu'après un rechargement complet (goto/reload). Inversement, X rétrogradé reste sur /admin/users avec tous les liens, ses actions échouent en 401 (POST /api/roles -> 401 depuis l'UI périmée).
  • Preuve : scripts/admin/t6_live.py (admin_links=0 avant/après, admin_links=2 après reload) ; screenshots screens/admin_live_02_R2_noreload.png, admin_live_04_demoted_on_users_page.png.
  • Cause probable : frontend/src/root.tsx:68-72 queryClient.query({queryKey:["me"], staleTime: 60*60_000}) ; aucune invalidation SignalR sur changement de rôle/permission (realtime.ts, hub sans événement de rôle) ; le changement de permissions d'un rôle (cases) n'invalide pas non plus me des utilisateurs concernés.
[ADMIN-19] Sidebar "Members" : le rôle affiché n'est pas mis à jour en temps réel après un changement de rôle — Gravité : Mineur
  • Où : panneau Members d'un channel
  • Étapes : 1. User observateur ouvre /channels/<id> (panneau Members ouvert, la cible affichée "Member") 2. dede change le rôle de la cible (PATCH /users/{id}/role/{roleId}) 3. Attendre 4 s sans recharger
  • Attendu : libellé de rôle mis à jour (ou au pire après navigation).
  • Obtenu : libellé inchangé ("Member") ; après rechargement complet : nouveau rôle affiché. (La suppression d'un rôle réaffectant les users à Member a le même défaut.)
  • Preuve : scripts/admin/t15_roles_ui2.py (sidebar after role change (no reload, 4s): ... Member, after reload: ... qa_admin_rn_..._b), screenshot screens/admin_members_sidebar.png.
  • Cause probable : aucun événement SignalR émis par PatchRoleQuery.cs / PatchRolePermQuery.cs / DeleteRoleQuery.cs ; cache react-query (10 min, queryClient.ts) côté front.

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-16, ADMIN-19 Cache `me` d'1 h et aucun push. ## Détails des rapports <details><summary>[ADMIN-16] Changement de rôle non répercuté en direct dans l'UI de l'utilisateur concerné (cache `me` 1 h, aucun push) — Gravité : Mineur</summary> - Où : toute l'UI (sidebar Invite/Users/Roles, boutons event/channel/messages) ; API - Étapes : 1. User qa X (rôle HandleEvent) connecté 2. dede change son rôle (HandleUsers+InviteUser+HandleChannels+HandleRoles) via `PATCH /users/{X}/role/{R}` 3. Observer l'UI de X sans recharger (4 s, puis navigation SPA Calendar/Home) 4. `GET /api/me` de X - Attendu : l'UI de X affiche immédiatement les liens "Users"/"Roles" ; (et inversement disparaissent à la rétrogradation). - Obtenu : `GET /api/me` renvoie le nouveau rôle immédiatement (et l'API applique les nouvelles permissions tout de suite), mais l'UI reste inchangée (0 lien admin) après 4 s et après navigation SPA ; les liens n'apparaissent qu'après un rechargement complet (goto/reload). Inversement, X rétrogradé reste sur /admin/users avec tous les liens, ses actions échouent en 401 (`POST /api/roles` -> 401 depuis l'UI périmée). - Preuve : `scripts/admin/t6_live.py` (`admin_links=0` avant/après, `admin_links=2` après reload) ; screenshots `screens/admin_live_02_R2_noreload.png`, `admin_live_04_demoted_on_users_page.png`. - Cause probable : `frontend/src/root.tsx:68-72` `queryClient.query({queryKey:["me"], staleTime: 60*60_000})` ; aucune invalidation SignalR sur changement de rôle/permission (`realtime.ts`, hub sans événement de rôle) ; le changement de permissions d'un rôle (cases) n'invalide pas non plus `me` des utilisateurs concernés. </details> <details><summary>[ADMIN-19] Sidebar "Members" : le rôle affiché n'est pas mis à jour en temps réel après un changement de rôle — Gravité : Mineur</summary> - Où : panneau Members d'un channel - Étapes : 1. User observateur ouvre `/channels/<id>` (panneau Members ouvert, la cible affichée "Member") 2. dede change le rôle de la cible (`PATCH /users/{id}/role/{roleId}`) 3. Attendre 4 s sans recharger - Attendu : libellé de rôle mis à jour (ou au pire après navigation). - Obtenu : libellé inchangé ("Member") ; après rechargement complet : nouveau rôle affiché. (La suppression d'un rôle réaffectant les users à Member a le même défaut.) - Preuve : `scripts/admin/t15_roles_ui2.py` (`sidebar after role change (no reload, 4s): ... Member`, `after reload: ... qa_admin_rn_..._b`), screenshot `screens/admin_members_sidebar.png`. - Cause probable : aucun événement SignalR émis par `PatchRoleQuery.cs` / `PatchRolePermQuery.cs` / `DeleteRoleQuery.cs` ; cache react-query (10 min, `queryClient.ts`) côté front. </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._
dernst self-assigned this 2026-10-30 12:26:36 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transcendence/frontend#158
No description provided.