Connexion : Ne plus rendre obligatoire ProConnect [GEN-2246]#5664
Connexion : Ne plus rendre obligatoire ProConnect [GEN-2246]#5664
Conversation
francoisfreitag
left a comment
There was a problem hiding this comment.
🧹 Pas mal de nettoyage, ça simplifie !
| if not request.user.is_authenticated: | ||
| return False |
There was a problem hiding this comment.
Je ne suis pas convaincu de la pertinence de ce check? (pour une autre PR)
There was a problem hiding this comment.
en effet, ça ne devrait jamais arriver
|
|
||
| def login(self, request, redirect_url=None): | ||
| ret = super().login(request=request, redirect_url=redirect_url) | ||
| accept_all_pending_invitations(request) |
There was a problem hiding this comment.
Ce n’est pas de ton fait, mais je trouve étrange qu’on accepte toutes les invitations en attente à la connexion. Un utilisateur n’a peut-être pas envie d’être rattaché à une structure ?
There was a problem hiding this comment.
Uhuh c'est vrai qu'avec l'abandon partiel de ProConnect, https://gip-inclusion.slack.com/archives/C01AQKD7MAN/p1731421358591279 revient en force 🙈
There was a problem hiding this comment.
C'est un bon point.
On peut sans doute ne pas accepter automatiquement en se connectant avec Django tout en le laissant pour ProConnect pour le moment.
Et même le retirer pour ProConnect tout en mettant un bandeau warning 'vous avez des invitations non acceptées" avec eventuellement un lien pour renvoyer l'email ?
There was a problem hiding this comment.
Oui. Et proposer d’accepter l’invitation directement depuis le site ? (pas besoin d’envoyer un email)
There was a problem hiding this comment.
Le soucis ce sont les pro sans entreprise. il faudrait les rediriger de force sur une page pour accepter les invits s'ils en ont une (là ou pour le moment on les déconnecte de force)
|
En se connectant en tant qu’admin au site: 💥Environment: |
|
Après discussion avec le métier, on va privilégier la connexion des utilisateurs existants. |
391eb8b to
0ecc3f5
Compare
0ecc3f5 to
f63a5d1
Compare
| # Allow ProConnect and Inclusion Connect users to bypass ProConnect if FORCE_PROCONNECT_LOGIN is False | ||
| and ( | ||
| settings.FORCE_PROCONNECT_LOGIN | ||
| or user.identity_provider not in [IdentityProvider.PRO_CONNECT, IdentityProvider.INCLUSION_CONNECT] |
There was a problem hiding this comment.
Je me demande si on ne devrait pas changer l’identity provider de IC vers DJANGO plutôt que de forcer à PC?
There was a problem hiding this comment.
Le seul soucis c'est qu'on cache de la logique.
Mais on pourrait en effet tous les passer à DJANGO en créant l'EmailAddress correspondant
| has_completed_welcoming_tour=True, | ||
| **ProConnectPrescriberData.user_info_mapping_dict(user_info), | ||
| identity_provider=IdentityProvider.DJANGO, | ||
| with_verified_email=True, |
There was a problem hiding this comment.
Pour un utilisateur inscrit via IC/PC, il n’aura pas d’email vérifié. On entrera donc dans le parcours de vérification d’email d’allauth, avec un message disant qu’on a bien enregistré leur inscription.
Est-ce qu’on veut une migration pour ajouter un email vérifié dans allauth pour les PC et IC et éviter cette étape ?
allauth gérait ça via social login, qui appelle https://github.com/pennersr/django-allauth/blob/c11e1429d90aa12373fb97705e18b1d8c602c417/allauth/account/utils.py#L246-L280.
There was a problem hiding this comment.
C'était en partie ce que calum avait commencé à faire, et qu'on a droppé car trop chronophage et qu'on souhaite supprimer allauth à terme.
There was a problem hiding this comment.
Yep 👍
En l’état, c’est très bizarre que le système demande de confirmer l’inscription au moment de la connexion par Django.
There was a problem hiding this comment.
Je n'ai pas réussi à ajouter à la volée l'EmailAdress manquante au moment du login.
Le code ne passe pas par l'adapter pour trouver l'EmailAddress : https://github.com/pennersr/django-allauth/blob/main/allauth/account/stages.py#L143-L150
Dans les possibilités :
- on laisse comme ça, de toute manière c'est normalement une solution de contournement temporaire pour une faible partie des utilisateurs
- envoyer un email mais ne pas bloquer la connexion (aka le traiter en
Optional) (cf le commit que j'ai revert juste après pour que la recette garde le fonctionnement "utilisateur bloqué") - monkey patcher
has_verified_email()pour dire OK pour les utilisateurs SSO - synchroniser les
EmailAddressavec un cron toutes les heures/jours - enregistrer proprement les
EmailAddressau login avec un SSO (et donc virer allauth avant -> trop de boulot)
Je serais d'avis de laisser comme ça, parce que c'est la solution la moins coûteuse, et d'organiser un point avec le métier pour discuter de ce qu'on fait en plus sur le sujet connexion sans ProConnet :
- gestion de la création de comptes
- gestion de la validation des emails
- gestion des invitations
There was a problem hiding this comment.
J’attends la résolution de https://gip-inclusion.slack.com/archives/CU8ATF54L/p1740484789002009.
Pourquoi est-ce qu’une migration qui ajouterait une EmailAddress(verified=True) pour les utilisateurs de PC/IC ne suffirait pas ?
- S’ils peuvent se connecter avec PC, a priori pas concernés par ces changements.
- Les utilisateurs bloqués ne peuvent pas se créer de compte sur IC ni avec Django, donc en injectant les
EmailAddress(verified=True)en une fois (migration), on devrait leur permettre de se connecter sans confirmation. Et on gérera les nouveaux comptes lorsqu’on permettra à nouveau l’inscription via les emplois ?
There was a problem hiding this comment.
En effet, ça va fonctionner
There was a problem hiding this comment.
J'ai commencé par nettoyer tous les objets qui pouvaient poser problème:
Tous les EmailAddress sur les comptes IC et PC (que ce soit la bonne adresse ou non)
Tous les EmailAddress qui utilisent une adresse email d'un compte IC ou PC et qui sont donc liés à des comptes non prescripteurs et employeurs vu l'étape précédent. Malheureusement il y en a.
Puis j'ai créé les objets qui vont bien pour les comptes IC et PC
f63a5d1 to
876106d
Compare
|
🥁 La recette jetable est prête ! 👉 Je veux tester cette PR ! |
c7aceb0 to
209dfa9
Compare
209dfa9 to
633e081
Compare
| # Normally all the IC/PC users | ||
| users_qs = User.objects.filter( | ||
| identity_provider__in=[IdentityProvider.INCLUSION_CONNECT, IdentityProvider.PRO_CONNECT] | ||
| ).exclude(Exists(EmailAddress.objects.filter(user=OuterRef("pk")))) |
There was a problem hiding this comment.
On vient de les supprimer, le exclude me semble inutile?
There was a problem hiding this comment.
Tout à fait, je retire ainsi que le commentaire.
francoisfreitag
left a comment
There was a problem hiding this comment.
Autrement ça devrait être bon 🤞
We are allowing again users to log without a SSO
633e081 to
1017c0a
Compare
1017c0a to
acdfd53
Compare

🤔 Pourquoi ?
Certains utilisateurs sont bloqués depuis 2 mois et le support ProConnect n'arrive pas à les aider.
On va donc permettre de se connecter (pas de créer un compte pour le moment) avec les crédentials Django.
🍰 Comment ?
🚨 À vérifier
🏝️ Comment tester ?
💻 Captures d'écran