Transition vers DataPass

[florimondmanca]

Je propose ici de clarifier comment j'imagine que les pièces du puzzle multi-orga + multi-catalogue + Datapass pourraient s'assembler. L'idée est de débloquer le sujet "catalogue / champs complémentaires" en se dirigeant progressivement vers une intégration complète avec DataPass.

1. Via une migration, créer une organisation "Par défaut" et son catalogue. La migration y rattachera tous les utilisateurs existants (comptes ADMIN ou USER, en local comme en prod), en utilisant un SIRET factice (ex : 0000000000000).
   • Cette étape permet d'avancer sur ces tickets qui sont bloqués tant qu'on n'a pas de notion de catalogue avec laquelle travailler :
     • Modifier le schéma d'un catalogue après sa création #277
     • Création d'un catalogue #284
     • Recherche avancée #290
2. Ajouter DataPass comme moyen de connexion alternatif : ajouter un bouton "Connexion avec DataPass" à la page de connexion. À ce stade, uniquement faire l'intégration technique OpenID Connect pour récupérer les infos du compte DataPass. On ne fera encore rien de ces infos. On affichera systématiquement la page d'infos "Contacter la DINUM pour créer une organisation" (de toute façon il n'y aura que l'orga factice en base).
3. Faire en sorte que les orgas créées avec Création d'une organisation #334 soient gérées par le système de connexion : utiliser les infos DataPass pour enregistrer un compte utilisateur lié au SIRET de l'orga existante.
   • Cette étape nécessite une refonte du système de compte utilisateur.
   • Idée : avoir deux "types" de comptes utilisateurs :
     • Legacy users = les utilisateurs existants (avec email, mdp, role, api_token)
     • DataPass users = les utilisateurs s'étant enregistrés et connectés avec DataPass (datapass_id, organization_siret, email, role, api_token)
     • La table User pourra avoir l'un OU BIEN l'autre (user.legacy_user_id et user.datapass_user_id avec une contrainte d'unicité entre les deux)
   • Créer une interface uniforme pour que l'un comme l'autre puisse être traité de la même façon par l'UI :
     • id
     • organization_siret
     • email
     • role
     • api_token
     • Un LegacyUser aura un org_siret de 00000000000000 (SIRET factice de l'org "par défaut"). On pourra éventuellement traiter comme un cas exceptionnel hardcodé pour l'affichage (notamment pour le label de l'orga, du type "Organisation par défaut").
4. (Un jour peut-être) Mettre à la remise la connexion par email/mdp par comptes créés manuellement.