[Majeur] PUT /events/{id} ignore expireAt et remet la date à 0001-01-01 si elle est absente #106

New issue

Closed

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

asventi commented

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

Owner

Gravité : Majeur
Rapports QA d'origine : EVENTS-11, EVENTS-12

Le composer d'édition envoie expireAt mais il n'est pas sauvegardé ; date n'est pas validée.

Détails des rapports

[EVENTS-11] `PUT /events/{id}` ignore `expireAt` (le composer d'édition le propose pourtant) — Gravité : Majeur

Où : PUT /api/events/{id} ; UI : modale d'édition (tuile "Expiration").
Étapes : 1. event avec expireAt = J+5. 2. PUT avec expireAt = J+10 (204). 3. GET.
Attendu : expireAt = J+10.
Obtenu : expireAt inchangé (J+5), aucune erreur. L'utilisateur croit avoir repoussé l'expiration ; l'event sera quand même supprimé par CleanUp à l'ancienne échéance.
Cause probable : backend/API/Events/Update/UpdateEventEndpoint.cs:8-26 (pas de champ ExpireAt dans UpdateEventRequest) et UpdateEventCommand.cs:40-47. Le front l'envoie : frontend/src/events/api/events.api.ts:76-79.
Statut : confirmé (API).

[EVENTS-12] `PUT /events/{id}` sans `date` remet la date à 0001-01-01 ; `date` toujours non validée — Gravité : Mineur

Étapes : PUT valide sans la clé date -> 204, GET -> date: "0001-01-01T00:00:00". (Même cause que EVENTS-04 : [Required] sur un DateTime non nullable.)
Cause probable : UpdateEventEndpoint.cs:13-14.

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 :** EVENTS-11, EVENTS-12 Le composer d'édition envoie `expireAt` mais il n'est pas sauvegardé ; `date` n'est pas validée. ## Détails des rapports <details><summary>[EVENTS-11] `PUT /events/{id}` ignore `expireAt` (le composer d'édition le propose pourtant) — Gravité : Majeur</summary> - Où : `PUT /api/events/{id}` ; UI : modale d'édition (tuile "Expiration"). - Étapes : 1. event avec `expireAt` = J+5. 2. PUT avec `expireAt` = J+10 (204). 3. GET. - Attendu : `expireAt` = J+10. - Obtenu : `expireAt` inchangé (J+5), aucune erreur. L'utilisateur croit avoir repoussé l'expiration ; l'event sera quand même supprimé par CleanUp à l'ancienne échéance. - Cause probable : `backend/API/Events/Update/UpdateEventEndpoint.cs:8-26` (pas de champ `ExpireAt` dans `UpdateEventRequest`) et `UpdateEventCommand.cs:40-47`. Le front l'envoie : `frontend/src/events/api/events.api.ts:76-79`. - Statut : confirmé (API). </details> <details><summary>[EVENTS-12] `PUT /events/{id}` sans `date` remet la date à 0001-01-01 ; `date` toujours non validée — Gravité : Mineur</summary> - Étapes : PUT valide sans la clé `date` -> 204, GET -> `date: "0001-01-01T00:00:00"`. (Même cause que EVENTS-04 : `[Required]` sur un `DateTime` non nullable.) - Cause probable : `UpdateEventEndpoint.cs:13-14`. </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

label

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

asventi self-assigned this

2026-10-28 13:49:13 +00:00

asventi closed this issue

2026-10-28 14:18:17 +00:00