Changer l'e-mail d'un utilisateur

RGJ · Septembre 18, 2020, 10:17

Je suis un peu confus par le processus lorsqu’un administrateur modifie l’adresse e-mail d’un utilisateur.

Certaines choses m’échappent simplement, et il y a un bug (c’est pourquoi je poste ceci dans bug et non dans Support).

Selon cette demande de tirage, cela devrait fonctionner comme suit.

Lorsqu’un administrateur modifie l’e-mail d’un utilisateur depuis la page de préférences de cet utilisateur :

L’utilisateur ne recevra pas d’e-mail pour confirmer le changement de son adresse. Il recevra un e-mail de réinitialisation de mot de passe afin qu’il puisse définir le mot de passe de son compte sur la nouvelle adresse.

L’utilisateur recevra toujours un e-mail à son ancienne adresse pour l’informer du changement.

#1 Je ne comprends pas pourquoi un e-mail de réinitialisation de mot de passe est envoyé (« afin qu’il puisse définir le mot de passe de son compte »). Ils n’ont pas besoin de changer leur mot de passe ? Et l’expérience utilisateur est confuse : l’utilisateur ne s’attend pas à recevoir un e-mail de réinitialisation de mot de passe, et il n’y a aucun texte d’accompagnement ; il est simplement indiqué « Quelqu’un a demandé de réinitialiser votre mot de passe sur [nom du forum] ».

#2 Cet e-mail de réinitialisation de mot de passe est envoyé à l’adresse ancienne au lieu de la nouvelle adresse e-mail.

Même si l’e-mail de l’utilisateur est mis à jour dans update_user_email à la ligne 46, l’objet @user n’est pas rechargé et contient toujours l’ancienne adresse e-mail.

github.com/discourse/discourse

lib/email_updater.rb

main


      
          if @guardian.is_staff? && @guardian.user != @user
            StaffActionLogger.new(@guardian.user).log_add_email(@user)
          else
            UserHistory.create!(action: UserHistory.actions[:add_email], acting_user_id: @user.id)
          end

#3 Si l’administrateur est l’utilisateur qui agit, et que l’utilisateur sur lequel on agit n’est pas du personnel, aucun e-mail de confirmation n’est envoyé conformément à la spécification ci-dessus. Néanmoins, après avoir modifié l’adresse e-mail, l’administrateur reçoit le message de succès suivant : « Nous avons envoyé un e-mail à cette adresse. Veuillez suivre les instructions de confirmation ».

#4 Pourquoi l’utilisateur n’a-t-il pas besoin de confirmer sa nouvelle adresse e-mail ? La demande de tirage fait référence à ce sujet, mais il semble qu’il manque de nombreux messages. Cependant, le sujet mentionne toujours « Pour un utilisateur normal, la seule adresse e-mail qui doit être vérifiée est la NOUVELLE adresse e-mail ». EDIT : oh attendez, voir #6 / #7.

#5 Ce processus, où un administrateur modifie l’e-mail d’un utilisateur, est généralement utilisé lorsque l’ancienne adresse e-mail n’est plus accessible (je suppose ?). Pourquoi y a-t-il toujours une notification envoyée à l’ancienne adresse ?

#6 Lorsque cet utilisateur tente de se connecter, une fenêtre contextuelle apparaît :

Vous ne pouvez pas encore vous connecter. Nous vous avons précédemment envoyé un e-mail d’activation à l’ancienne adresse e-mail. Veuillez suivre les instructions contenues dans cet e-mail pour activer votre compte.

aucun tel e-mail n’a été envoyé
l’ancienne adresse e-mail est mentionnée

Appuyer sur le bouton « Renvoyer » indique :

Nous vous avons envoyé un autre e-mail d’activation à la nouvelle adresse e-mail. Cela peut prendre quelques minutes pour qu’il arrive ; assurez-vous de vérifier votre dossier spam.

#7 Cet e-mail d’activation arrive effectivement à la nouvelle adresse e-mail et porte le titre « confirmez votre nouveau compte » (et non « confirmez votre nouvelle adresse e-mail »).

Cela ne devrait-il pas simplement être :

Un e-mail est envoyé à la nouvelle adresse e-mail, indiquant « votre adresse e-mail a été modifiée par [nom de l’administrateur]. Veuillez cliquer sur le lien suivant pour confirmer [lien].

Édition : #8 l’adresse e-mail peut être modifiée par un administrateur depuis le profil public de l’utilisateur (/u/username), mais pas depuis la page d’administration de cet utilisateur (/admin/users/id/username). C’est contre-intuitif.

codinghorror · Septembre 21, 2020, 12:17

Peut-on reproduire ce problème @tshenry ? Y a-t-il eu une régression ici ?

tshenry · Septembre 25, 2020, 12:40

Je vais d’abord décrire le flux actuel tel que je le vois se dérouler (la plupart, sinon la totalité, de ces éléments correspondent à ce que @RGJ a décrit) :

Un administrateur accède aux préférences d’un utilisateur non membre du personnel et modifie son adresse e-mail :

Screen Shot 2020-09-24 at 4.16.04 PM1758×590 35.2 KB

Une fois soumis, l’administrateur voit le message suivant :

Nous avons envoyé un e-mail à cette adresse. Veuillez suivre les instructions de confirmation.
Le message ci-dessus ne semble pas exact, car DEUX e-mails sont envoyés à l’adresse e-mail ancienne :

[Démo] Votre adresse e-mail a été modifiée

Il s’agit d’un message automatique pour vous informer que votre adresse e-mail pour
Démo a été modifiée. Si cela a été fait par erreur, veuillez contacter
un administrateur du site.

Votre adresse e-mail a été modifiée en :

new@email.com

[Démo] Réinitialisation du mot de passe

Quelqu’un a demandé de réinitialiser votre mot de passe sur Démo.

Si ce n’était pas vous, vous pouvez ignorer cet e-mail en toute sécurité.

Cliquez sur le lien suivant pour choisir un nouveau mot de passe :
https://example.discourse.site/u/password-reset/74d53d7d2cf20dsbc360614844c653s2
J’ai testé trois scénarios distincts à partir de ce point. Chaque puce représente un scénario :
- L’utilisateur a accès à l’ancienne adresse e-mail et suit le lien de réinitialisation du mot de passe. Après avoir mis à jour son mot de passe, il est connecté. À partir de là, il peut se connecter avec son nom d’utilisateur ou l’adresse e-mail ancienne. La nouvelle adresse e-mail ne semble pas être en vigueur à ce stade.
- L’utilisateur tente de se connecter avec son nom d’utilisateur ou l’adresse e-mail nouvelle et reçoit ceci :
  
  Screen Shot 2020-09-24 at 4.38.01 PM1418×394 35.5 KB
  
  Option 1 : Cliquer sur « Renvoyer » affiche le message suivant (notez qu’il mentionne cette fois l’adresse e-mail nouvelle) :
  
  Screen Shot 2020-09-24 at 4.59.42 PM1418×390 27.8 KB
  
  Un e-mail est effectivement envoyé à l’adresse e-mail nouvelle :
  
  [Démo] Confirmez votre nouveau compte
  
  Bienvenue sur Démo !
  
  Cliquez sur le lien suivant pour confirmer et activer votre nouveau compte :
  https://example.discourse.site/u/activate-account/74d53d7d2cf20dsbc360614844c653s2
  
  Si le lien ci-dessus n’est pas cliquable, essayez de le copier et de le coller dans la barre d’adresse de votre navigateur web.
  
  En suivant le lien, on passe par certaines pages pour l’activation d’un nouveau compte. À la fin, l’utilisateur se connecte avec succès. À partir de ce moment, l’utilisateur peut se connecter avec son nom d’utilisateur ou l’adresse e-mail ancienne. La nouvelle adresse e-mail ne semble pas être en vigueur à ce stade.
  
  Option 2 : Cliquer sur le bouton « Modifier l’adresse e-mail » affiche ce qui suit. Le bouton « Mettre à jour l’adresse e-mail » est désactivé lorsque l’adresse e-mail nouvelle est dans le champ de texte, ce qui suggère que la nouvelle adresse e-mail est déjà active (mais cela ne semble pas être le cas).
  
  Screen Shot 2020-09-24 at 5.17.31 PM938×492 27.2 KB
- L’utilisateur initie une réinitialisation du mot de passe. L’e-mail est envoyé à l’adresse e-mail nouvelle et l’utilisateur peut se connecter via le lien. Comme dans les autres scénarios, l’utilisateur peut se connecter avec son nom d’utilisateur ou l’adresse e-mail ancienne. La nouvelle adresse e-mail ne semble pas être en vigueur à ce stade.

Donc, nous reproduisons clairement ces problèmes ici. C’est difficile à expliquer clairement, mais j’espère qu’entre le message initial et cette description, cela deviendra plus clair. Il y a certainement des éléments qui doivent être corrigés.

@martin Je sais que tu as déjà travaillé sur cette partie du cœur du système. Pourrais-tu donner ton avis ici quand tu auras un moment ?

codinghorror · Septembre 25, 2020, 12:54

Pourquoi cela aurait-il régressé ?

edit : Je peux également confirmer que cela a régressé. Lors de la modification de l’e-mail d’un utilisateur standard, la confirmation et autres sont envoyées à l’ANCIEN e-mail. Ce n’est pas ainsi que cela fonctionnait auparavant..

martin · Septembre 27, 2020, 11:11

Ce sentiment de familiarité inconfortable quand on lit la description du pull request cité et qu’on réalise que c’est soi le coupable…

Merci pour les instructions détaillées @tshenry et @RGJ, je vais mettre cela en haut de ma liste à corriger cette semaine.

martin · Septembre 28, 2020, 2:48

Bon, j’ai maintenant compris le problème. J’ai consulté l’ancien sujet sur les commentaires supprimés pour retrouver l’historique. J’ai retrouvé cela de la part de @sam, dont je me souviens maintenant :

La réinitialisation de l’adresse e-mail par l’administrateur est très différente ; il s’agit en réalité d’une réinitialisation de l’adresse e-mail et du mot de passe par l’administrateur. En effet, si l’utilisateur avait accès au compte, il pourrait tout faire lui-même via le service autonome.

Donc, nous disons que, puisque c’est l’administrateur qui modifie l’adresse e-mail, un e-mail de réinitialisation du mot de passe doit être envoyé. En effet, si l’utilisateur avait accès à l’ancienne adresse e-mail, il pourrait simplement… se connecter et le faire lui-même ? Mais l’e-mail de réinitialisation du mot de passe sert également de confirmation. Sans terminer le processus de réinitialisation du mot de passe (ce qui est actuellement impossible car l’e-mail est envoyé à l’ancienne adresse), la nouvelle adresse e-mail n’est pas « confirmée », ce qui déclenche l’apparition de cette fenêtre modale :

Le problème où l’e-mail de réinitialisation du mot de passe est envoyé à l’ancienne adresse est facilement résolu, et nous parviendrons au moins à un état où le processus de réinitialisation peut être suivi :

RGJ:

Même si l’adresse e-mail de l’utilisateur est mise à jour dans update_user_email à la ligne 46, l’objet @user n’est pas rechargé et contient toujours l’ancienne adresse e-mail.

github.com

discourse/discourse/blob/master/lib/email_updater.rb#L44-L49
if @guardian.is_staff? && !@user.staff?
  send_email_notification(@user.email, email)
  update_user_email(old_email, email)
  send_email(:forgot_password, @user.email_tokens.create!(email: @user.email))
  return
end

De plus, comme l’e-mail de réinitialisation du mot de passe est actuellement envoyé à l’ancienne adresse, lorsqu’il est confirmé, cela confirme la mauvaise adresse et remet l’adresse e-mail de l’utilisateur à l’ancienne.

Je vais modifier le message destiné à l’administrateur qui modifie l’adresse e-mail afin de lui faire clairement comprendre que l’utilisateur doit cliquer sur le lien dans la nouvelle adresse e-mail et modifier son mot de passe pour que la modification prenne pleinement effet (et corriger également le problème de la mauvaise adresse e-mail).

RGJ · Septembre 28, 2020, 11:28

Attends. Je ne comprends pas cela.

Il y a une différence entre le fait qu’un utilisateur puisse accéder à l’ancienne adresse e-mail et le fait qu’un utilisateur doive réinitialiser son mot de passe pour son compte Discourse. Le premier n’implique absolument pas le second ; ce sont des situations totalement différentes.

Un grand nombre de modifications d’adresse e-mail par un administrateur sont également dues au fait que l’utilisateur ne sait pas comment le faire, ou parce que l’administrateur doit temporairement lever la restriction email_editable = false.

Je trouve très confus qu’une réinitialisation de mot de passe serve également de confirmation d’adresse e-mail. Personnellement, je ne répondrais même pas à cet e-mail de réinitialisation du mot de passe puisque je ne l’ai pas demandé, et je ne réaliserais pas qu’il s’agit d’une étape de confirmation nécessaire (et je pense que ce n’est pas le cas ; un simple e-mail de confirmation ordinaire suffirait ?)

Steve_Pavlina · Septembre 28, 2020, 4:47

Cela pourrait être lié :

Lorsqu’un de mes utilisateurs du forum tente de réinitialiser son mot de passe aujourd’hui (avec la dernière version de Discourse disponible ce matin), il reçoit l’e-mail, mais obtient ensuite une erreur en suivant le lien contenu dans l’e-mail :

Il rencontre cette erreur sur plusieurs navigateurs et n’utilise pas de bloqueur de publicités.

Lorsque je me rends sur la page des préférences de son compte et que je clique sur « Envoyer un e-mail de réinitialisation du mot de passe », j’obtiens également un message d’erreur :

Avant d’afficher « (erreur) » à côté du bouton, il indique brièvement « (envoi de l’e-mail)) ». Il semble cependant qu’aucun e-mail n’ait été envoyé. Je peux confirmer que les autres e-mails du forum sont envoyés normalement aujourd’hui.

Cette fonctionnalité fonctionnait parfaitement auparavant… elle semble avoir cessé de fonctionner à un moment donné au cours de la semaine dernière.

codinghorror · Septembre 28, 2020, 4:54

Vérifiez les journaux d’erreurs de Discourse dans le navigateur web lorsque vous êtes connecté en tant qu’administrateur ; un rapport d’erreur plus détaillé devrait s’y trouver.

Steve_Pavlina · Septembre 28, 2020, 5:05

Voici l’entrée d’erreur :

398 Exception de tâche : La source de copie spécifiée est plus grande que la taille maximale autorisée pour une source de copie : 5368709120

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/request.rb:70:in `send_request'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:61:in `block in vacate_legacy_prefix'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `each'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `vacate_legacy_prefix'

/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'

/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'

/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'

rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection'

/var/www/discourse/app/jobs/base.rb:221:in `block in perform'

/var/www/discourse/app/jobs/base.rb:217:in `each'

/var/www/discourse/app/jobs/base.rb:217:in `perform'

sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job'

sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'

/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'

sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local'

sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'

sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats'

sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call'

sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global'

sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch'

sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare'

sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one'

sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run'

sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog'

sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread'

RGJ · Septembre 28, 2020, 5:28

Non, cela n’a absolument aucun rapport. Essayez d’effacer les journaux et de forcer la survenue de cette erreur, puis vérifiez à nouveau les journaux.

Steve_Pavlina · Septembre 28, 2020, 6:22

Ensuite, les journaux restent vides après la survenue de l’erreur.

martin · Septembre 28, 2020, 11:44

RGJ:

Attendez. Je ne comprends pas cela.

Il y a une différence entre le fait qu’un utilisateur puisse accéder à l’ancienne adresse e-mail et le fait qu’un utilisateur doive réinitialiser son mot de passe pour son compte Discourse. Le premier n’implique absolument pas le second ; ce sont des situations totalement différentes.

Un grand nombre de modifications d’adresse e-mail par un administrateur sont également dues au fait que l’utilisateur ne sait pas comment faire, ou parce que l’administrateur doit temporairement lever la restriction email_editable = false.

…

Je trouve très confus qu’une réinitialisation de mot de passe serve également de confirmation d’adresse e-mail. Personnellement, je ne répondrais même pas à la réinitialisation de mot de passe si je ne l’ai pas demandée, et je ne réaliserais pas qu’il s’agit d’une étape de confirmation nécessaire (et je pense que ce n’est pas le cas ; un simple e-mail de confirmation suffirait ?)

Je comprends votre point de vue ; pour moi, l’idée d’utiliser la réinitialisation de mot de passe comme confirmation m’a trompé hier. Je pense que cela pourrait être une option secondaire pour l’administrateur lors de la modification de l’adresse e-mail d’un utilisateur, avec une case à cocher indiquant « Réinitialiser également le mot de passe de l’utilisateur ». Je vais fusionner la PR que j’ai préparée pour une correction telle quelle, car le processus est actuellement totalement cassé.

J’aimerais que @sam donne son avis sur un nouveau processus/flux, car Sam avait initialement expliqué la logique derrière le flux de réinitialisation de mot de passe :

L’administrateur modifie l’adresse e-mail de l’utilisateur. Il a la possibilité de réinitialiser son mot de passe en même temps.
L’utilisateur reçoit un e-mail à sa nouvelle adresse demandant confirmation du changement d’adresse e-mail.
- S’il répond Oui, l’adresse e-mail est modifiée. Nous envoyons un e-mail à l’ancienne adresse indiquant que l’adresse e-mail a été changée.
- S’il répond Non, rien n’est fait.
Si l’administrateur avait spécifié qu’il souhaitait une réinitialisation à l’étape 1, alors dès que l’utilisateur confirme le changement d’adresse e-mail, il reçoit un e-mail de réinitialisation de mot de passe à la nouvelle adresse.

Je pense que cela serait beaucoup plus clair, et la réinitialisation du mot de passe n’aurait rien à voir avec la confirmation du changement d’adresse e-mail.

codinghorror · Septembre 28, 2020, 11:48

Oui, je ne vois pas pourquoi ces deux éléments seraient liés du tout ?

IAmGav · Septembre 29, 2020, 12:56

Je vois une belle nouvelle commit fusionnée dont les gens seront heureux

github.com/discourse/discourse

FIX: Admin change email for user process improvements and fixes (#10755)

master ← issue/fix-admin-changing-user-email-process

merged 11:45PM - 28 Sep 20 UTC

martin-brennan

+33 -10

See https://meta.discourse.org/t/changing-a-users-email/164512 for context. W…hen admin changes an email for a user, we were incorrectly sending the password reset email to the user's old address. Also the new email does not come into effect until the reset password process is done, so this PR adds some notes to the admin to make this clearer.

martin · Septembre 29, 2020, 1:03

Merci, cela va simplement fusionner une correction pour l’état « complètement cassé » des choses. Un autre PR suivra !

Cela a été fait ainsi suite à des discussions dans le sujet précédent avec Sam. Je vais procéder avec le nouveau processus pour lever le voile de confusion et supprimer le lien entre ces éléments sans rapport.

martin · Octobre 7, 2020, 3:03

Je viens de fusionner cette PR qui effectue les actions suivantes :

github.com/discourse/discourse

FIX: When admin changes an email for the user the user must confirm the change (#10830)

master ← issue/fix-admin-change-user-email-flow

merged 03:02AM - 07 Oct 20 UTC

martin-brennan

+155 -62

See https://meta.discourse.org/t/changing-a-users-email/164512 for additional co…ntext. Previously when an admin user changed a user's email we assumed that they would need a password reset too because they likely did not have access to their account. This proved to be incorrect, as there are other reasons a user needs admin to change their email. This PR: * Changes the admin change email for user flow so the user is sent an email to confirm the change * We now record who the email change request was requested by * If the requested by user is admin and not the user we note this in the email sent to the user * We also make the confirm change email route open to anonymous users, so it can be clicked by the user even if they do not have access to their account. If there is a logged in user we make sure the confirmation matches the current user.

Modifie le flux de changement d’e-mail pour les utilisateurs dans l’administration afin que l’utilisateur reçoive un e-mail pour confirmer le changement
Nous enregistrons désormais qui a demandé le changement d’e-mail
Si la demande émane d’un administrateur et non de l’utilisateur, nous le mentionnons dans l’e-mail envoyé à l’utilisateur
Nous rendons également la route de confirmation du changement d’e-mail accessible aux utilisateurs anonymes, afin qu’elle puisse être cliquée par l’utilisateur même s’il n’a pas accès à son compte. Si un utilisateur est connecté, nous nous assurons que la confirmation correspond à l’utilisateur actuel.

J’espère que cela rendra le processus beaucoup plus clair !

Sujet		Réponses	Vues
On email address change second confirm fails due to email customization Support	20	1948	Décembre 26, 2019
Users getting Internal Server Error when trying to change email address Bug	6	159	Mai 15, 2025
Change email for SSO user? SSO	35	9715	Septembre 9, 2024
User can't change his email address Support	10	724	Juillet 24, 2023
PUT /u/{username}.json does not change the email Bug rest-api	8	673	Août 10, 2023

Changer l'e-mail d'un utilisateur

[Démo] Votre adresse e-mail a été modifiée

[Démo] Réinitialisation du mot de passe

[Démo] Confirmez votre nouveau compte

Sujets connexes