Développement #99983
FranceConnect : gestion du multicompte (1 identité FC liée à plusieurs comptes Publik)
0%
Description
Nécessaire à la gestion des personnes morales, où les parcours d’habilitation invitent à la liaison à FC pour la validation de l’identité de l’usager ; usager qui doit pouvoir gérer ses différentes PMs à l’aide de comptes distincts, reliés à son identité FC.
Il y a déjà eu une idée similaire émise dans #11329 mais ça ne correspond pas exactement au besoin créé ici, je préfère créer à nouveau un ticket plutôt que reprendre celui là.
Related issues
History
Updated by Paul Marillonnet 4 months ago
- Related to Développement #11329: Finaliser la gestion multifédérations. added
Updated by Paul Marillonnet 4 months ago
- Subject changed from Gestion du multicompte (1 identité FC liée à plusieurs comptes Publik) to FranceConnect : gestion du multicompte (1 identité FC liée à plusieurs comptes Publik)
Updated by Robot Gitea 4 months ago
- Status changed from Nouveau to En cours
- Assignee set to Paul Marillonnet
Paul Marillonnet (pmarillonnet) a ouvert une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/authentic/pulls/453
- Titre : WIP: FranceConnect: gestion du multicompte (#99983)
- Modifications : https://git.entrouvert.org/entrouvert/authentic/pulls/453/files
Updated by Benjamin Dauvergne 4 months ago
Je répond au commentaire de #99992 ici:
Je voulais faire en deux temps de façon complètement découplée, mais ça introduit des migrations inélégantes sur des contraintes d’unicité du sub et de l’usager pour les liaisons FC, contraintes qu’on devrait ensuite relâcher immédiatement après dans #99983, pas top. J’abandonne cette idée et je vais tout faire d’un coup dans #99983.
Le schéma actuel vient de l'idée d'introduire l'unicité (sub, user) tout en contournant le problème des fédérations en double existantes un peu partout à l'époque. Ici si j'ai bien compris bien que le plan soit succint l'idée est de permettre une multiplicité coté user i.e. avoir une relation sub <1-n> user ou un sub peut pointer sur plusieurs utilisateurs mais pas l'inverse. À vrai dire le schéma actuel le permettrait sans rien changer (en jouant sur order) mais on peut rajouter une contrainte d'unicité sur user à la place et s'assurer du destin des sub surnuméraires sur les utilisateurs.
Updated by Paul Marillonnet 4 months ago
Le schéma actuel vient de l'idée d'introduire l'unicité (sub, user) tout en contournant le problème des fédérations en double existantes un peu partout à l'époque.
Ok, j’ignorais cela, je comprends mieux merci pour la remise en contexte.
Ici si j'ai bien compris bien que le plan soit succint l'idée est de permettre une multiplicité coté user i.e. avoir une relation
sub <1-n> userou un sub peut pointer sur plusieurs utilisateurs mais pas l'inverse.
Oui complètement, c’est ce sens (et ce sens là uniquement) de la multiplicité qui nous intéresse.
À vrai dire le schéma actuel le permettrait sans rien changer (en jouant sur order)
Ouai je voulais justement m’épargner ce jeu d’avoir à gérer un `order` unique sur les liaisons à différents comptes (jeu qui n’est reflété par aucun besoin fonctionnel ni dans l’implémentation actuelle ni dans l’implémentation visée par cette PR ; je me disais autant dégager cela.)
mais on peut rajouter une contrainte d'unicité sur user à la place et s'assurer du destin des sub surnuméraires sur les utilisateurs.
Oui tu as raison je vais déjà poser la contrainte d’unicité sur user et gérer la multiplicité des subs à partir de là ensuite.