API Particulier: impossible aux éditeurs d'accéder aux jetons

[skelz0r]

Problème remonté aujourd'hui https://mattermost.incubateur.net/betagouv/pl/5xkw6bphpbfsprm89sjbmwkrmw et https://support.etalab.gouv.fr/#ticket/zoom/48313

Ce que j'ai dit sur le thread:

Pour le contexte: sur notre plateforme seul les demandeurs peuvent récupérer les jetons. Lui c'est un éditeur ( exemple: https://datapass.api.gouv.fr/api-particulier/13261 ), et je n'ai aucune trace de lui dans notre BO (car ça rentre pas dans notre nomenclature) ... :grimacing:

Là c'est un peu compliqué, vu qu'on ne crée plus de jetons sur l'ancien backend je ne peux juste pas faire le switch sur l'ancienne plateforme facilement.

Donc 2 choix:

1. On rebranche l'ancien backend + l'ancien bridge de DataPass, mais du coup c'est le bordel pour les jetons..
2. On implémente du multi users direct pour gérer ça ( dans API Particulier chaque demande possède N emails, on fait les N users lié à ces demandes)

[skelz0r]

Si on part sur 2., il faut:

1. Créer une nouvelle nomenclature de Contact ( technique, éditeur.. à voir en inspectant les data )
2. Permettre à ces contacts de se connecter
3. Lister les jetons associés aux demandes du contact

Dès que c'est codé: refaire un import des données de contact et les lié aux demandes DataPass.

[Haelle]

De mémoire on avait décidé de :

• fusionner la notion de contact avec celle de user
• un user a un type (demandeur, tech, métier) et peut voir tous les jetons auquel il est affecté peut importe son rôle (comme API Part en fait)
• pour API Part on avait oublié d'importer les contacts donc faudra faire ça aussi

[Samuelfaure]

Je prend ce sujet, je m'y met dès que j'ai finit la 2nd PR liasses fiscales

[Haelle]

Voir commentaire suivant, celui-ci gardé pour l'historique

Je partage ce qu'il faut faire

SQL/model

• ajouter une colonne de type array contact_type (demandeur et/ou métier et/ou tech)
• migrer les contacts vers users (attention il y a BEAUCOUP de doublons !)
• une authorization_request peut maintenant avoir n users
• reprendre les created_at/updated_at actuels

Code

• modification du traitement d'un webhook Datapass
• faire une passe sur l'utilisation de la colonne contact_type qui passe en array
• nettoyage du code morts modèle Contact par exemple

⚠ ATTENTION ⚠ Si c'est fait en une seule PR la migration devra être faite en SQL car on va jeter la table contacts, et donc en SQL on aura pas les contraintes d'intégrités sur users, genre les emails uniques.

Je pense donc qu'une première PR de fonctionnalité puis une PR de nettoyage me paraît bien.

[Haelle]

On part sur une solution plus simple : on envoie un magic link aux contacts techniques et métiers.

Ainsi on bypass les comptes api.gouv.fr et on peut garder notre politique d'email générique pour les contacts techniques et métiers.

• 1. [x] importer les contacts API Part (qui n'ont pas été importé lors de la migration)
• 2. [ ] refondre le login ; si l'email c'est un User login classique, si l'email est un contact alors envoi d'un Magic Link
• 3. [ ] refonte du système de Magic Link (lié à un email comme ça on peut retrieve direct les jetons) à voir avec @skelz0r je pensais que ça marchait déjà comme ça...
• 4. [ ] Faire une "nouvelle" page accessible avec ce magic link (ou une session ? ça serait pas mal) pour lister tous les jetons lié à ce contact

Je ne sais pas si c'est vraiment chronologique il y a peut-être des dépendances que j'ai pas vue

[skelz0r]

PI je viens d'importer les contacts techniques manquants (j'ai constaté que j'avais oublié de les importer au moment de la migration) https://github.com/etalab/migrate_api_particulier_tokens_to_siade/commit/68a5ae2e788369261bb0445df8f643974f45be23

[Samuelfaure]

@skelz0r du coup il reste des contacts API part à migrer ou c'est bon pour cette partie?

[skelz0r]

C'est bon tout est migré (et dtf c'est indépendant de l'implémentation de la feature).

[skelz0r]

L'url pour le préremplissage sur auth-api -> https://auth.api.gouv.fr/users/start-sign-in?login_hint=email@domain.com

[Samuelfaure]

closed par #776