-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connexion: Utilisation du modèle EmailAddress et refonte du parcours de modification d'adresse mail [GEN-2216] #5088
base: master
Are you sure you want to change the base?
Conversation
8ba6071
to
b9f6941
Compare
🥁 La recette jetable est prête ! 👉 Je veux tester cette PR ! |
b9f6941
to
9092579
Compare
{% autoescape off %} | ||
Nous avons bien enregistré votre demande d'inscription et vous remercions de votre confiance. | ||
|
||
Afin de finaliser votre inscription, cliquez sur le lien suivant : | ||
|
||
{{ activate_url }} | ||
|
||
Si vous n'êtes pas à l'origine de cette demande, merci de ne pas prendre en compte ce message. | ||
{% include "layout/base_email_signature.txt" %} | ||
{% endautoescape %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fonctionnalité de django-allauth, ce gabarit sera utilisé lorsque signup=True
(docs)
9092579
to
6a40156
Compare
6a40156
to
8827113
Compare
EmailAddress.objects.bulk_create( | ||
EmailAddress(user=x.user, email=x.email, primary=True, verified=False) for x in users_missing_addresses | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
J'aurais aimé éviter verified=False
dans le mesure de possible. Avec notre système du courant la logique verified=(x.last_login_date > x.modified_at)
serait fiable, mais on ne stocke pas un champ modified_at
🥁 La recette jetable est prête ! 👉 Je veux tester cette PR ! |
8827113
to
10f0e77
Compare
Previously the user would need to try to login before the notification was sent Fix requesting email modification does not lock users out of their account Better conflict handling in EditUserEmailForm Ensure EmailAddress consistency when user email changes
Use EmailAddress model in user query email_already_exists Override create_user to prevent EmailAddress conflicts Fix language in error of create_user May be shown to users Creation of candidate by third party considers EmailAddress (JobSeekerExistsForm)
Many users on production have User.email set with no corresponding email address model Fix migration should assume emails are not verified Fix migration typo
Emails are case insensitive (RFC 5321 Part 2.4)
10f0e77
to
2602f6d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
J'ai un peu l'impression qu'on profite de l'existence du modèle EmailAddress
de django-allauth
pour implémenter notre changement d'adresse email.
Je me demande s'il ne faudrait pas plutôt le faire avec notre modèle à nous plutôt que de donner l'impression d'utiliser (en la détournant fortement) la fonctionnalité de django-allauth
?
@@ -173,13 +173,15 @@ def inclusion_connect_activate_account(request): | |||
return HttpResponseRedirect(params.get("previous_url", reverse("search:employers_home"))) | |||
|
|||
user_kind = params.get("user_kind") | |||
user = User.objects.filter(email=email).first() | |||
email_address = EmailAddress.objects.filter(email__iexact=email).first() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
email_address = EmailAddress.objects.filter(email__iexact=email).first() | |
email_address = EmailAddress.objects.filter(email__iexact=email).select_related("user").first() |
Et a priori à chaque fois qu'on utilise EmailAddress
pour récupérer un User
.
.values("id", "email") | ||
) | ||
|
||
EmailAddress.objects.bulk_create( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Il y en a beaucoup ? Ça vaudrait ptet le coup de faire un migration atomic = False
.
migrations.RunPython( | ||
create_email_addresses_for_users, | ||
reverse_code=migrations.RunPython.noop, | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tu peux rajouter elidable=True
si elle peut être squashée.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bien vu merci !
queryset = cls.objects.filter( | ||
id__in=EmailAddress.objects.filter(email__iexact=email).values_list("user_id", flat=True) | ||
) | ||
if exclude_pk: | ||
queryset = queryset.exclude(pk=exclude_pk) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
queryset = cls.objects.filter( | |
id__in=EmailAddress.objects.filter(email__iexact=email).values_list("user_id", flat=True) | |
) | |
if exclude_pk: | |
queryset = queryset.exclude(pk=exclude_pk) | |
queryset = EmailAddress.objects.filter(email__iexact=email) | |
if exclude_pk: | |
queryset = queryset.exclude(user_id=exclude_pk) |
Je suis pour l'utilisation du modèle de Qu'est ce que tu penses ? |
# We want to control how EmailAddress is managed during this view | ||
re_path( | ||
r"^accounts/confirm-email/(?P<key>[-:\w]+)/$", | ||
signup_views.ItouConfirmEmailView.as_view(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pourquoi ne pas garder celle de django-allauth ?
Je suis pas forcément très convaincu de la direction de la PR : |
🤔 Pourquoi ?
Quand un utilisateur modifie son email, l'accès à son compte est bloqué jusqu'à ce qu'il soit vérifié. S'il s'est trompé, il n'aura pas accès à son compte jusqu'à il peut accèder l'adresse mail ou il est débloqué par le support. Toutefois, il ne recevra cet e-mail avant qu'il essaie de se connecter avec le nouvelle adresse.
🍰 Comment ?
Ce PR propose une refonte du parcours de modification plus clair, et que la notification soit envoyée immédiatement, et que l'utilisateur soit rédirigé vers la page d'instruction.
Un utilisateur peut démander une seconde adresse mail, et le moment que il le vérifie son
user.email
sera remplacé. Si l'utilisateur se connecte avec son ancien e-mail il peut, mais ça va annuler sa réquête à changement d'adresse mail. S'il démande un 3ème la réquête sera remplacée et l'adresse mail en cours de vérification annulée/relâchée.Tandis qu'un e-mail est en cours de vérification, il est réservé et un tiers ne peut pas inscrire sur notre plate-forme en l'utilisant.
Impliqué par ces changements est que le modèle
EmailAddress
doit être utilisé lorsque que l'unicité d'adresse mail est importante, car unEmailAddress
en cours de vérification est quand même réservé au utilisateur qui l'a démandé. Il inclut donc des changements auUser.save
pour gerer la création / modification des adresses mails, et une migration temporaire pour remplir toutes les adresses mails manquante sur le base de données du prod.🚨 À vérifier
🏝️ Comment tester