Expose role and verification dates, make notifications non-blocking - #2
Merged
Merged
Conversation
Deux points restants pour que le client puisse afficher correctement le profil. getOnlyUserData omettait role, status et les dates de vérification. Ces champs alimentent le badge de rôle et les badges « Verified » du client, qui remplace son état par la réponse reçue après une inscription ou une mise à jour de profil : les omettre les effaçait. Les dates sont ramenées à null quand elles valent undefined, sinon elles disparaissent de la réponse JSON sur une instance fraîchement créée et la forme du payload change d'un appel à l'autre. Les notifications envoyées après une confirmation d'email, de téléphone ou une réinitialisation de mot de passe faisaient répondre en erreur si le SMTP tombait, alors que le changement était déjà écrit en base. Le client ne rafraîchissait alors pas le profil et son badge restait périmé, et pour la réinitialisation l'utilisateur pouvait croire à un échec puis réessayer avec un code déjà consommé. L'inscription avait déjà été traitée de cette manière, les trois autres suivent. Les emails porteurs d'un code restent bloquants. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VP7toBNjKohZASo9wF67i4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deux correctifs nécessaires pour que
kit_clientpuisse afficher correctement le profil. Ils complètent la PR #1, qui avait déjà repris la majeure partie des endpoints d'authentification.getOnlyUserDataomettait le rôle et les dates de vérificationLe helper ne renvoyait que
uuid, nom, prenoms, email, tel, address. Il alimente pourtant la réponse de l'inscription (createNewUser) et celle de la mise à jour de profil (updateUserService).Le client remplace son état utilisateur par la réponse reçue :
role,status,email_verified_atettel_verified_atétaient donc effacés côté client après une inscription ou une modification de profil — le badge de rôle disparaissait et les badges de vérification devenaient incohérents.Les deux dates sont ramenées à
nulllorsqu'elles valentundefined: sur une instance fraîchement créée parUser.create, elles ne sont pas encore hydratées etJSON.stringifysupprime purement et simplement les clés, si bien que la forme du payload changeait d'un appel à l'autre.Notifications SMTP bloquantes après une opération déjà enregistrée
confirmEmailService,confirmTelServiceetconfirmPasswordCodeServiceenvoient un email après avoir écrit le changement en base. Unawait sendEmail(...)qui lève faisait répondre502alors que l'opération avait bien eu lieu :200), son badge restait périmé alors que le compte était vérifié ;Ces trois envois passent par un helper
sendNotificationEmailqui journalise l'erreur sans la propager. L'inscription était déjà traitée ainsi depuis la PR #1 ; les emails porteurs d'un code (inscription,reset-password,mobile-reset-password) restent bloquants, puisqu'un échec y empêche réellement l'utilisateur de poursuivre.Vérification
npm test: 84 tests, 6 suites, tous verts (80 existants + 4 ajoutés danstests/profile-payload.test.js, couvrant la forme du payload et les deux confirmations sous panne SMTP simulée).Generated by Claude Code