Produits Entr'ouvert » Authentic 2

Anaïs Ecuvillon a écrit :

Quid de quand on décoche volontairement cette case ?

Et au passage, si vous pouviez nous rappeler comment tout ça fonctionne, quel paramétrage est prioritaire ?

Alors, de mémoire, pour comprendre ces paramètres un peu alambiqués, il faut avoir en tête qu’il y a dans a2 la gestion d’une unicité globale sur soit le courriel, soit le username de l’usager, mais cela peut se faire sans que ce soit nécessairement sur l’un et sur l’autre à la fois.

Prenons le cas du courriel à titre d’exemple (ce raisonnement reste valable aussi pour le username), lorsque l’unicité globale est désactivée, on peut tout de même souhaiter que dans une collectivité donnée (une "OU"), cette unicité soit respectée. Cela veut dire que plusieurs comptes de cette même collectivité ne peuvent pas partager le même courriel.

Cependant, lorsque l’unicité globale est activée, cette case à cocher dans l’écran de config de l’OU est sans effet.

Il n’y a une unicité globale par défaut que sur le username. Celle sur le courriel est désactivée par défaut, pour une raison que j’ignore.

Peut-être qu’une chose à faire pour que cet écran de configuration de l’OU devienne davantage intelligible est de désactiver la possibilité de cocher/décocher ces cases lorsque l’unicité globale est posée, avec un message en expliquant la raison ?

Perso je suis pour la disparition du paramétrage global qui n'a plus de sens, avec pour les instances où il est présent une migration qui pose email_is_unique sur chaque OU existante.

Benjamin Dauvergne a écrit :

Perso je suis pour la disparition du paramétrage global qui n'a plus de sens, avec pour les instances où il est présent une migration qui pose email_is_unique sur chaque OU existante.

Ok mais EMAIL_IS_UNIQUE = True, ce n’est pas la même chose que ∀ou, ou.email_is_unique = True. Est-ce qu’en migrant de cette façon on ne va pas casser des instances Publik pour lesquelles, w.c.s. par exemple s’attend cette unicité (genre des WF qui filtrent sur l’email en s’attendant à au plus un usager renvoyé, etc.) ?

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Perso je suis pour la disparition du paramétrage global qui n'a plus de sens, avec pour les instances où il est présent une migration qui pose email_is_unique sur chaque OU existante.

Ok mais EMAIL_IS_UNIQUE = True, ce n’est pas la même chose que ∀ou, ou.email_is_unique = True.

Tout à fait.

Est-ce qu’en migrant de cette façon on ne va pas casser des instances Publik pour lesquelles, w.c.s. par exemple s’attend cette unicité (genre des WF qui filtrent sur l’email en s’attendant à au plus un usager renvoyé, etc.) ?

Avec le recul je ne pense pas qu'on ait jamais eu besoin d'une unicité globale, l'idée date d'il y a très longtemps, l'unicité sur l'ou par défaut sert uniquement à avoir un email = un compte, pour les usagers. Après dans le cas où il y a d'autres OU c'est au cas par cas qu'on s'en servira (par exemple si on fait une liaison au SSO OIDC/SAML avec un import CSV préalable, on pourra faire la liaison par l'email ou pas).

• virer le setting EMAIL_IS_UNIQUE et tous ses usages (on peut commencer par les usages, ajouter avec un warning, et le virer à moyen terme ça évite de courir derrière les modules externes)
• prévoir une migration pour poser ou.email_is_unique partout où il était utilisé
• changer les valeurs par défaut de ou.username_is_unique/email_is_unique à True