[Majeur] Un utilisateur bloqué peut continuer à écrire dans le DM existant #98

New issue

Closed

opened 2026-10-28 10:31:57 +00:00 by asventi · 0 comments

asventi commented

2026-10-28 10:31:57 +00:00

Owner

Gravité : Majeur
Rapports QA d'origine : FRIENDS-05

Le blocage n'est vérifié qu'à la création d'une demande ou d'une conversation, pas à l'envoi de message.

Détails des rapports

[FRIENDS-05] Un utilisateur bloqué peut continuer à écrire dans le DM existant avec celui qui l'a bloqué — Gravité : Majeur

Où : POST /api/channels/{dmId}/messages
Étapes : 1. A et B amis, DM existant. 2. A bloque B (POST /api/me/relationships/{B}/block -> 200). 3. B envoie un message dans le DM.
Attendu : 403 (blocage appliqué aux messages) ; l'UI de A ne doit plus recevoir de messages de B.
Obtenu : 201 "B-after-block" ; il est diffusé à A en temps réel (NewMessage) et stocké. Dans le même état, POST /api/me/conversations et POST /api/me/relationships/{id} renvoient bien 403 (CONVERSATION_BLOCKED / RELATIONSHIP_BLOCKED) : le blocage n'est appliqué qu'à la création, pas à l'usage d'un DM existant. La page UI "Blocked" promet pourtant "Users you block can't send you requests or messages." (FriendsPage.tsx empty state).
Preuve : sortie de scripts/friends/block.py ("B send msg in existing DM: 201") ; en UI (ui6.py) : après blocage de B par A, B envoie "B writes after being blocked" depuis la page du DM, et A le voit dans son DM (screens/friends_18_A_dm_sees_blocked_msg.png, friends_17_B_dm_after_block.png). Le texte de la confirmation de blocage (friends_15_block_confirm.png) ne mentionne d'ailleurs que "friend requests or start conversations".
Cause probable : backend/API/Channels/Messages/Create/CreateMessageCommand.cs ne consulte pas db.Relationships.

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é :** Majeur **Rapports QA d'origine :** FRIENDS-05 Le blocage n'est vérifié qu'à la création d'une demande ou d'une conversation, pas à l'envoi de message. ## Détails des rapports <details><summary>[FRIENDS-05] Un utilisateur bloqué peut continuer à écrire dans le DM existant avec celui qui l'a bloqué — Gravité : Majeur</summary> - Où : `POST /api/channels/{dmId}/messages` - Étapes : 1. A et B amis, DM existant. 2. A bloque B (`POST /api/me/relationships/{B}/block` -> 200). 3. B envoie un message dans le DM. - Attendu : 403 (blocage appliqué aux messages) ; l'UI de A ne doit plus recevoir de messages de B. - Obtenu : 201 "B-after-block" ; il est diffusé à A en temps réel (`NewMessage`) et stocké. Dans le même état, `POST /api/me/conversations` et `POST /api/me/relationships/{id}` renvoient bien 403 (CONVERSATION_BLOCKED / RELATIONSHIP_BLOCKED) : le blocage n'est appliqué qu'à la création, pas à l'usage d'un DM existant. La page UI "Blocked" promet pourtant "Users you block can't send you requests or messages." (`FriendsPage.tsx` empty state). - Preuve : sortie de `scripts/friends/block.py` ("B send msg in existing DM: 201") ; en UI (`ui6.py`) : après blocage de B par A, B envoie "B writes after being blocked" depuis la page du DM, et A le voit dans son DM (`screens/friends_18_A_dm_sees_blocked_msg.png`, `friends_17_B_dm_after_block.png`). Le texte de la confirmation de blocage (`friends_15_block_confirm.png`) ne mentionne d'ailleurs que "friend requests or start conversations". - Cause probable : `backend/API/Channels/Messages/Create/CreateMessageCommand.cs` ne consulte pas `db.Relationships`. </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/friends-blocking

labels

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