Enregistrement et connexion

[johanricher]

User stories

• ETQ agent dans un ministère, j'ai besoin de m'enregistrer et de me connecter sur catalogue.data.gouv.fr afin de faire des recherches dans les catalogues des différents ministères.
• ETQ agent dans un ministère, j'ai besoin de savoir si celui-ci existe sur catalogue.data.gouv.fr afin de savoir si je peux m'enregistrer et me connecter (sinon je dois en faire la demande cf. Création d'une organisation #334)

Critères d'acceptation

Pour la prod

• Un bouton de connexion est visible hors connexion
• Liste publique des organisations #358
• Une personne peut s'enregistrer sur l'instance si elle a un compte Mon Compte Pro rattaché à une organisation qui peut être liée à une organisation sur l'instance.
• ETQ agent d'un ministère qui n'existe pas sur l'instance, lorsque j'essaie de m'enregistrer un message d'erreur m'informe que l'organisation n'existe pas encore et comment demander la création d'une organisation Rediriger vers la doc dans la page d'ajout d'organisation #439
• ETQ agent de plusieurs ministères qui existent sur l'instance, lorsque je m'enregistre sur l'instance je peux choisir une seule organisation à laquelle je peux appartenir. Ce choix est définitif.

Parcours et design

• Flowchart
• Figma : Page d'accueil non connecté
• Figma : Si l'utilisateur n'appartient à aucune organisation enregistrée
• Figma : Si l'utilisateur appartient à plusieurs organisations enregistrées

Implémentation

• Déléguer la gestion du compte utilisateur et des orgas à Comptes Datapass ETQ user je peux me connecter via DataPass (Front) #373
• Rediriger vers la doc dans la page d'ajout d'organisation #439

Voir aussi #288

Alternatives envisagées

• Implémenter un système de gestion d'organisations ad-hoc, propre à notre outil
  • Travail dupliqué par rapport à Comptes DataPass, notamment sur le process de validation des organisations et membres

Idées pour plus tard

• Possibilité pour un utilisateur d'appartenir à N organisations : je peux contribuer à tous les catalogues des organisations auxquelles j'appartiens et je peux voir leurs entrées en accès restreint (cf. Régler le niveau d'accès d'une entrée dans le catalogue #289).
• Possibilité pour un utilisateur d'appartenir à 1 organisation mais avec possibilité de switcher après l'inscription
  • Comptes DataPass le permet, mais ça nécessiterait une UI pour "switcher" entre les différentes organisations (exemple de Scaleway), et une complexité supplémentaire.

[florimondmanca]

Proposition et idées, à discuter/découper/prioriser cc @johanricher @DaFrenchFrog @Volubyl

TL;PL

Trop long; pas lu

Je pense qu'un plan d'attaque pourrait être celui-ci, découpé en deux phases (A et B), séparées par le fait qu'on se dote à un moment d'un système d'emailing :

Phase A :

• S'attaquer à 1/ (création de compte), mais en simplifiant : plutôt qu'autoriser n'importe quel utilisateur à créer un compte (ce qui nécessite un mécanisme de restriction de domaines, et d'envoi d'email de vérification), seul un admin peut inviter un utilisateur à partir d'un email. [Comment ? On voit venir une notion de "back office"...]
• S'occuper de 2/b/ (changement de mdp). Ça ne nécessite tjr pas de système de vérification ou d'envoi d'email, mais permet de démarrer la page du compte utilisateur. L'email est visible mais en lecture seule : "L'email ne peut pas être modifié pour le moment".

Phase B : une fois muni d'un système d'emailing... (ex : MailJet)

• S'occuper de 2/a/ (modification d'email), avec vérification du nouvel email.
• S'occuper de 3/ : mot de passe oublié = réinitialisation à partir d'un email de récupération.
• Revenir sur 1/ pour permettre la création autonome d'un compte utilisateur, avec restriction des domaines email et vérification d'email. [Ne semble pas nécessaire tant qu'on invite nous-mêmes des utilisateurs de test.]

Analyse détaillée - Etat visé lointain - Exploration

Présupposés :

• Un utilisateur ne peut avoir qu'un seul email actif. (À l'inverse, certains sites permettent de gérer plusieurs adresses email dont une "primaire", cf GitHub.)

1/ ETQ nouvel utilisateur, je peux créer un compte sur l'outil en toute autonomie

Scénario

• L'utilisateur clique sur un lien "Créer un compte" sur la page de connexion.
• L'utilisateur indique email/password dans une page dédiée à la création du compte.
  • Restriction des emails par domaine, configurable par environnement (demo, sandbox, etc).
• Lorsque c'est fait, un email de confirmation est envoyé.
  • L'utilisateur doit avoir confirmé son email avant d'accéder à l'outil. La connexion via la page de login échoue tant que l'email n'est pas confirmé.
  • Cas 1 : l'utilisateur tente de se connecter sans avoir vérifié son email
    • Un message d'erreur s'affiche. Un bouton "Renvoyer un email de confirmation" est proposé.
  • Cas 2 : l'utilisateur confirme son email
    • L'utilisateur ouvre l'email de confirmation, et clique sur le bouton "Vérifier mon email".
    • Le lien débouche sur la page de login et l'utilisateur peut désormais se connecter.

API

Existant :

• POST /auth/users/ - Crée un nouvel utilisateur avec email/password

Modifications :

• POST /auth/users/ : doit envoyer un email de vérification.
• POST /auth/login/ : doit renvoyer une 401 si l'utilisateur n'a pas encore confirmé son email.

Ajouts :

• POST /auth/users/email-confirmation/ - Envoie un (nouvel) email de vérification. Tout précédent email de vérification est marqué comme expiré.
• POST /auth/users/email-confirmation/<key>/ - Marque l'email de l'utilisateur comme vérifié (lien incorporé à l'email de vérification).

UI

• Lien "Créer un compte" sur la page de connexion.
• Page avec un formulaire de création de compte.
• Page de connexion : gérer le cas où l'utilisateur n'a pas encore vérifié son email. Bouton "Renvoyer un email de vérification" avec le message d'erreur.

2/ ETQ utilisateur connecté, je peux modifier mon compte en toute autonomie

Scénarios

• a/ Modifier mon email
  • L'utilisateur connecté clique sur un lien "Réglages" ou "Compte".
  • Une page dédiée au compte s'affiche.
  • L'utilisateur modifie son email et clique sur "Enregistrer".
  • Un email de vérification est envoyé.
  • L'utilisateur ouvre l'email de vérification et cliquer sur "Vérifier mon email"
  • Le nouvel email est désormais actif. L'ancien n'est plus actif.
• b/ Changer mon mot de passe
  • Dans la page de gestion du compte, l'utilisateur renseigne le mot de passe courant, un nouveau mot de passe, et clique sur "Enregistrer".
  • Lorsque c'est fait, le mot de passe a été modifié et l'utilisateur est redirigé vers la page de connexion.

API

• PUT /auth/users/email/ - Déclenche la modification d'email de l'utilisateur authentifié. Effet de bord : envoie un email de vérification.
• PUT /auth/users/password/ - Modifie le mot de passe de l'utilisateur authentifié - Payload : current_password, new_password. L'effet est de modifier le password_hash et de regénérer l'api_token de l'utilisateur. Ainsi, toute utilisation de l'ancien api_token (utilisateur connecté via l'ancien mdp) envoie une 401 à l'UI ce qui a pour effet de déconnecter l'utilisateur et de l'inviter à se reconnecter.

UI

• Page "Réglages", avec un formulaire pour modifier l'email, un autre pour modifier le mot de passe.

3/ ETQ utilisateur, je peux réinitialiser mon mot de passe en cas d'oubli

Scénario

• L'utilisateur clique sur un bouton "Mot de passe oublié ?" sur la page de connexion
• L'utilisateur est invité à renseigner son email
• L'outil informe l'utilisateur qu'un email de récupération lui a été envoyé
• L'utilisateur ouvre l'email, clique sur le bouton "Réinitialiser mon mot de passe"
• L'utilisateur arrive sur une page dédiée qui lui permet de renseigner un nouveau mot de passe.
• Une fois fait, l'utilisateur est redirigé vers la page de login et peut se connecter avec le nouveau mot de passe.

API

Ajouts :

• POST /users/password-reset/ - Envoyer un email de récupération de mot de passe - Payload : email.
• POST /users/password-reset-from-key/ - À partir d'une clé secrète incorporée à l'email de récpuération, accepte un nouveau password. (L'UI doit vérifier password avec un champ password_confirm.)

UI

• Page de connexion : lien "Mot de passe oublié ?".
• Page avec formulaire pour indiquer l'email de récupération.
• Page pour renseigner un nouveau mot de passe.

Implémentation

L'implémentation pourra être accélérée (en fait, ça m'a permis de faciliter cette analyse) en s'inspirant d'implémentations existantes, par exemple django-allauth ou django-registration.

[DaFrenchFrog]

Super boulot @florimondmanca !
Je ne me rends pas bien compte du temps que prennent les deux phases mais est-ce que cela ne vaudrait pas le coup de directement passer à la phase B ? Je pense que nous allons rapidement avoir besoin de gérer des notifications (notamment lors des créations/modifications de fiches) une fois en production et peut-être que l'on gagnera du temps à mettre l'effort sur la phase B directement plutôt que de le faire en deux phases ?

Nous n'avons à priori pas d'impératif de temps puisque tant que le schéma organisation ne sera pas implémenté il n'y aura pas d'utilisation en production.

[florimondmanca]

@DaFrenchFrog En fait je vois plus les phases A et B comme une progression logique, par étapes, ce qui peut nous aider à planifier le travail.

Par contre j'ai fait une erreur dans le A/1/ : la création de compte "par invitation" nécessiterait aussi un envoi d'email, pour prévenir la personne qu'elle a été invitée. Ou alors on génère un mot de passe aléatoire, pour envoyer email/tmp_password à la personne et on l'invite à le modifier grâce au A/2/.

Dans tous les cas, 2/ (changement de mdp) peut être fait dès aujourd'hui, c'est en fait orthogonal à la question de la création de compte.

Et pour le reste, il semble qu'on doive se munir d'un distributeur de mails, même si on peut commencer à développer sans (la conception est plug'n'play - on développera sur un backend de mails "factice" qui log dans la console). Et donc ce système de mails pourrait constituer une étape technique préalable...

[johanricher]

j'ai fait une erreur dans le A/1/ : la création de compte "par invitation" nécessiterait aussi un envoi d'email, pour prévenir la personne qu'elle a été invitée.

Est-ce que justement ce ne serait pas une façon itérative et minimaliste de traiter ce besoin dans un premier temps ? Une feature d'invitation par email qui est dans un "back office" accessible aux seuls admins du catalogue. Cela nous ferait avancer sur l'implé de l'envoi des emails et un panneau admin dont on va avoir besoin de toute façon.

[johanricher]

Dans le cadre de la création / gestion de compte j'en profite aussi pour remettre sur la table les solutions existantes et qu'on va peut-être être amenés à implémenter dans le futur, en particulier le login avec un compte data.gouv.fr (voir publier.etalab.studio pour un exemple de parcours utilisateur) et Datapass. Autant commencer à y penser dès maintenant.

@DaFrenchFrog Est-ce que tu as des insights sur les solutions d'authentification déjà utilisées par les agents au MC ? Est-ce qu'ils utilisent leur adresse email pro pour se connecter à des services ? est-ce qu'ils se connectent une seule fois à l'intranet ou doivent-ils se connecter à chaque outil ? est-ce qu'il y a un SSO... ?

[florimondmanca]

Lors de l'atelier du 10/06 on n'a pas évoqué le sujet de la méthode de création de compte, cf message de Johan ci-dessus : qu'utilise le MC à ce jour ? Adresse mail pro ? SSO ?

J'ai reporté ce qu'on a dit dans la description de ce ticket, mais ça reste encore flou sur la façon de procéder. Je pense qu'on a besoin de design cc @DaFrenchFrog

[DaFrenchFrog]

@Volubyl @florimondmanca @johanricher Avant de faire le design je préfèrerais qu'on sache précisément quel moyen on utilise pour vérifier l'identité pour avoir le bon discours. Il se trouve qu'aujourd'hui j'ai pour voisin de bureau l'équipe datapass et ils me confirment que l'on peut utiliser datapass comme passerelle d'inscription. L'utilisateur devra se créer un compte datapass (si ce n'est pas déjà le cas) et nous recevrons en retour ses informations et le SIRET de son organisation (qui nous permettra de vérifier le bon ministère) correspondance pour automatiquement valider l'inscription. Ce process implique du coup de lister dès la page de connexion les ministères autorisés afin que l'utilisateur ne s'inscrive pas pour rien.

Doc pour l'implémentation : https://github.com/betagouv/api-auth#readme

Je pense que cela vaut le coup de se pencher un peu sur le sujet avant de partir de rien.

[florimondmanca]

@DaFrenchFrog @johanricher

J'ai exploré un peu l'option DataPass. J'ai mis qq notes techniques dans #294 mais pour ce qui est du fonctionnel voici ce que j'ai trouvé. Au global, ça semble assez prometteur, avec quelques questions en suspens.

Je me suis créé un compte sur auth.api.gouv.fr, en cliquant sur "Créer un compte" sur l'accueil DataPass : https://datapass.api.gouv.fr/

Voici la procédure :

1. On me demande une adresse mail : je saisis mon email pro Fairness.
2. Je saisis un mot de passe.
3. Un code de vérification m'est envoyé.
4. Je remplis mon profil : prénom, nom, numéro de tél. pro, poste occupé
5. Une page "Rejoindre une organisation" s'affiche : "Veuillez saisir le numéro SIRET de l'organisation que vous souhaitez représenter". De ce que je comprends, il n'y a pas de "rattachement magique". On me demande explicitement d'indiquer le SIRET d'une organisation à rejoindre. Le système semble branché sur l'"API Entreprise" car si j'indique le SIRET de Fairness, la page détecte automatiquement le nom associé : "Organisation : FAIRNESS". Je peux aussi indiquer le SIRET du MC, et il est trouvé également.

Il semble donc qu'un agent puisse effectivement en toute autonomie créer son compte api.gouv puis s'y rattacher à une organisation quelconque via son SIRET.

À noter :

• Un utilisateur peut rattacher son compte DataPass à plusieurs organisations, cf FAQ.
• Pour ce qui est de la gestion de son compte / profil utilisateur DataPass, c'est possible, mais il n'y a pas de bouton sur https://datapass.api.gouv.fr. Il faut aller dans la FAQ où il y a un lien vers les différentes pages par lesquelles on est passé lors de la création de compte.
• Si l'organisation existe déjà, il y a une procédure de validation sous 5 jours ouvrés. (Je suis tombé dessus car j'ai en fait d'abord créé un compte avec mon adresse du Mattermost BetaGouv. Cela a créé l'organisation Fairness sur DataPass. Réalisant que DataPass n'était pas restreint aux agents publics, j'ai retenté avec mon adresse pro Fairness : ça a fonctionné, mais l'organisation existait déjà donc la procédure de validation s'est déclenchée.)

Une fois le compte DataPass de l'agent créé, on peut ensuite ensuite techniquement récupérer les SIRETs des organisations dont fait partie l'utilisateur lors de l'authentification.

Si jamais on passe sur un système "Authentification uniquement par DataPass", l'avantage est que ça nous soulage de la gestion des organisations et des comptes utilisateurs (du moins pour les données qui ne sont pas propres à l'outil : il y aura tjr une notion "d'utilisateur Catalogage").

Ça pose cela dit un certain nb de questions sur l'évolution technique et design. Le sujet principal est que le compte utilisateur est alors géré par ce tiers (DataPass). Dès lors :

• Comment faire le lien entre les organisations de l'utilisateur sur DataPass, et les catalogues dans l'outil ? @DaFrenchFrog je crois que c'est un point de design/conception en soi.
• Le modèle "utilisateur" (User) existera toujours mais il devra évoluer pour être constitué de {ID DataPass, SIRET orga} d'une part, et des données propres à notre outil d'autre part. On a par exemple toujours besoin du role (admin, responsable d'orga, standard). Comment / à quel moment attribuer ces rôles ?
• Comment restreindre la contribution aux catalogues aux seuls agents publics (si c'est bien l'objectif) ? Restreindre aux organisations qui ont déjà un catalogue ? Comment alors autoriser la création autonome de catalogue (Création d'un catalogue #284) ? La procédure de validation côté DataPass lorsqu'on crée un compte pour une orga existante ne semble pas suffisante. En effet, DataPass ne fait pas de distinction entre ministère / organisation publique et organisation privée : on peut s'y créer un compte rattaché à une société (ex : moi avec Fairness). C'est même tout le but puisque DataPass permet de gérer les habilitations juridiques pour accéder aux données de l'Etat.
• (Technique) Quel impact sur le modèle de déploiement ? Chaque environnement "live" (sandbox, staging, demo) devra être enregistré comme application auprès de DataPass (URL de callback pour Open ID Connect). Le compte DataPass unique pourra en principe être utilisé dans chaque environnement, mais chaque environnement aura tjr un User(DataPassID, ...) dédié.
• (Technique) Quel impact sur le dev et les tests ? En local, utilisera-t-on un vrai compte DataPass pour développer ? Faudra-t-il un backend d'authentification "factice" qui contourne DataPass ?

[johanricher]

Merci Florimond pour cette exploration.

Mes premières réflexions et questions :

• Si le service Datapass s'occupe de la vérification qu'une personne physique appartient bien à une organisation (ou plusieurs), c'est une solution à un problème qu'on avait aussi (s'appuyer sur la détention d'une adresse email et le lien entre nom de domaine et organisation n'est pas satisfaisant).
  • (Question pas importante pour nous mais je suis curieux : comment Datapass effectue cette vérification ?)

Elements de réponses à tes questions :

Comment faire le lien entre les organisations de l'utilisateur sur DataPass, et les catalogues dans l'outil ?

Si mon interprétation est correcte cela revient à poser la question suivante :

Si une personne appartient à plusieurs organisations dans Datapass, comment gérer ça dans catalogue.data.gouv.fr ?

Dans une première version de l'implé : on reste sur 1 personne -> 1 organisation. Dans ce cas laquelle ? les organisations sont-elles classées ou y a-t-il une notion d'organisation principale dans l'API de Datapass ?)
Plus tard (parce que cela me paraît complexe mais je me trompe peut-être et si on ne le fait pas maintenant ce sera très compliqué) : on fait évoluer notre modèle vers 1 personne -> n organisations. Quand l'utilisateur se connecte il a des droits sur les catalogues des organisations auxquelles il appartient (par exemple ; y ajouter et éditer des fiches dans ces catalogues ; lire les catalogues complets y compris les entrées qui n'ont pas un accès public).

Comment / à quel moment attribuer les rôles d'utilisateurs (user, resp orga, admin) ?

• Le fait de rendre les rôles modifiables depuis l'UI n'est pas un must have pour le lancement.
• Un rôle de responsable d'organisation est attribué dans le cadre de Création d'un catalogue #284.
• Tous les autres utilisateurs se voient attribués un rôle d'utilisateur au moment où leur compte est créé (c'est ici sur ce ticket qu'on voit ça !).
• L'attribution du rôle d'admin est suffisament peu fréquent pour qu'il nécessite une intervention à la main en base.

Comment restreindre la contribution aux catalogues aux seuls agents publics ?

Je ne comprends pas cette question puisque si je comprends bien c'est justement le rôle de Datapass (je me fie à ce que tu dis toi-même : "DataPass permet de gérer les habilitations juridiques pour accéder aux données de l'Etat.")

Datapass doit nous certifier qu'un compte utilisateur sur Datapass appartient (par exemple) à un agent d'un ministère. Si Datapass ne répond pas à ce besoin, c'est un deal breaker pour nous.

En effet, DataPass ne fait pas de distinction entre ministère / organisation publique et organisation privée : on peut s'y créer un compte rattaché à une société (ex : moi avec Fairness).

Pas un problème : une personne avec un compte Datapass ne pourra créer un compte sur catalogue.data.gouv.fr que s'il peut être lié à une organisation sur catalogue.data.gouv.fr. Si Datapass nous certifie l'organisation (SIRET) à laquelle appartient la personne, on n'aura plus qu'à faire un match avec l'organisation sur catalogue.data.gouv.fr.

[DaFrenchFrog]

Peut-être une version plus simple :
Si en tant qu'agent je souhaite m'inscrire et rejoindre une organisation, je saisis mon mail dans un formulaire (en sélectionnant l'organisation que je veux rejoindre) et cela envoie un email aux admins de l'organisation qui le valident ou non en cliquant sur un lien oui/non présent dans l'email.

Problème : il peut y avoir à terme des conflits si un admin accepte un membre qui est en réalité dans une autre organisation, et que cette organisation est créée par la suite... L'utilisateur ne sera plus dans la bonne organisation.

J'ai donc rien dit !

[florimondmanca]

(Question pas importante pour nous mais je suis curieux : comment Datapass effectue cette vérification ?)

Le process de vérification que j'ai indiqué (seulement dans le cas où on rejoint une orga existante sur DataPass) se fait comme @DaFrenchFrog le suggère... Une demande est envoyée côté admins de api.gouv, qui doit alors valider manuellement la création du compte DataPass et son rattachement à l'organisation sous 5 jours ouvrés. Dans le cas de mon "compte doublon" avec l'email Fairness, j'ai envoyé un email dans la foulée à l'adresse de contact pour m'expliquer, et une personne responsable m'a répondu en validant ce nouveau compte.

On aurait donc pas besoin de faire cette vérification de notre côté : une fois arrivé dans la partie "inscription" de l'outil, on sait que l'utilisateur fait bel et bien partie des organisations que DataPass nous renvoie. Donc a priori de contribuer à leur catalogue dans le cas où l'organisation en a un. N'est-ce pas ?

Dans une première version de l'implé : on reste sur 1 personne -> 1 organisation. Dans ce cas laquelle ? les organisations sont-elles classées ou y a-t-il une notion d'organisation principale dans l'API de Datapass ?

Non, l'API DataPass nous renvoie une liste d'organisations indifférenciée, et dans l'UI DataPass il n'y a pas de mécanisme "d'organisation préférée". De mon point de vue, s'il y en a plusieurs, il faut que notre UI demande à l'utilisateur de choisir à quel catalogue contribuer

La question subsidiaire, c'est : que se passe-t-il si l'utilisateur souhaite contribuer à plusieurs catalogues ? Auparavant on disait "il faudra se créer un nouveau compte", désormais ce serait impossible, car il y a un compte unique (DataPass) qui a ce lien vers toutes les organisations de l'utilisateur.

Je ne comprends pas cette question puisque si je comprends bien c'est justement le rôle de Datapass (je me fie à ce que tu dis toi-même : "DataPass permet de gérer les habilitations juridiques pour accéder aux données de l'Etat.")
Datapass doit nous certifier qu'un compte utilisateur sur Datapass appartient (par exemple) à un agent d'un ministère. Si Datapass ne répond pas à ce besoin, c'est un deal breaker pour nous.

Il y a peut-être une incompréhension ici, car je suis d'accord avec le dernier paragraphe de ton msg. Je parlais de restreindre aux agents publics qui peuvent avoir un catalogue (membre d'un "ministère" pour simplifier), en excluant toute personne qui ne serait pas membre d'un ministère. DataPass a un modèle qui ne fait pas cette distinction. En tant que membre de Fairness je peux donc en théorie me connecter à l'outil Catalogue avec mon compte DataPass, mais je ne suis pas censé pouvoir créer de catalogue, car Fairness n'est pas un ministère. Cela veut dire que nous devons avoir de notre côté une liste d'organisations "connues" : si on n'en fait pas partie, on dit par ex "Vous n'avez pas de catalogue, veuillez contacter un admin". Et à ce moment il y a l'étape de validation pour savoir si l'organisation X est autorisée à avoir son catalogue.

[johanricher]

Si en tant qu'agent je souhaite m'inscrire et rejoindre une organisation, je saisis mon mail dans un formulaire (en sélectionnant l'organisation que je veux rejoindre) et cela envoie un email aux admins de l'organisation qui le valident ou non en cliquant sur un lien oui/non présent dans l'email.

Tu suggères une vérification à la main de chaque inscription, qu'une personne appartient bien à un ministère et ce pour tous les utilisateurs (donc des centaines) ? Qu'est-ce qui permet à un humain de vérifier qu'une personne appartient bien à l'organisation à laquelle il dit appartenir ? C'est justement le rôle de Datapass donc si Datapass le fait on n'aura pas besoin de "valider" une inscription et le parcours d'inscription d'un utilisateur sera automatisé (à condition que son organisation existe déjà sur catalogue.data.gouv.fr et que Datapass fonctionne bien comme je l'ai compris).

Comme le dit Florimond :

une fois arrivé dans la partie "inscription" de l'outil, on sait que l'utilisateur fait bel et bien partie des organisations que DataPass nous renvoie.

C'est en effet ce que je comprends.

[johanricher]

Utilisateur qui fait partie de plusieurs organisations

Si le modèle de données de Datapass est : 1 user -> n organisations et qu'on adopte Datapass il me semble qu'il faut qu'on adopte le même modèle de données...

il faut que notre UI demande à l'utilisateur de choisir à quel catalogue contribuer

Il faudra alors demander à l'inscription sur catalogue.data.gouv.fr (via Datapass) de choisir parmi ses organisations de rattachements sur Datapass, 1 organisation sur catalogue.data.gouv.fr qui sera la seule dont il fera partie (avec ce que ça a comme conséquences en terme de permission de lecture et d'écriture), et potentiellement sans possibilité de la changer par la suite. C'est une solution mais je suis pas sûr qu'elle soit acceptable.

[johanricher]

Restriction de l'accès à des personnes qui ne sont pas membres d'un ministère

Une personne qui a un compte Datapass ne pourra créer un compte sur catalogue.data.gouv.fr que s'il peut être lié à une organisation sur catalogue.data.gouv.fr (match SIRET dans Datapass -> SIRET dans catalogue.data.gouv.fr).

Puisque les organisations et catalogues ne pourront être créés qu'après validation d'un administrateur de catalogue.data.gouv.fr il n'y aucun risque qu'une organisation "Fairness" soit créée et qu'une personne faisant partie de Fairness puisse s'inscrire (puisque l'organisation n'existera pas).

Pour les exceptions, nous concernant par exemple puisque nous ne sommes pas des agents de la DINUM, il faudra peut-être conserver le système actuel de connexion par identifiant (adresse email) et mot de passe. En base nos users appartiendraient à l'organisation DINUM.

[florimondmanca]

@johanricher @DaFrenchFrog

Avec @Volubyl on a traduit le processus d'inscription / création orga en termes techniques. Le résultat est dans le Mural. Je rajoute le lien à ce ticket.

J'ai aussi mis à jour la description du ticket vu les dernières discussions, sur la base de l'idée : on va passer par DataPass.

[johanricher]

@florimondmanca @Volubyl
Concernant les compte Datapass qui sont rattachés à plusieurs organisations (cf. mon précédent message) : quel est le choix que vous préconisez ?

1. On adopte le même modèle que Datapass (1 user -> n organisations)
2. On reste sur le modèle privilégié jusqu'à présent (1 user -> 1 organisation) auquel cas il faut décider de l'implémentation

Dans le 2ème choix, que se passe-t-il

• ... si une personne a un compte Datapass rattaché à plusieurs organisations qui existent sur catalogue.data.gouv.fr lorsque elle s'inscrit sur catalogue.data.gouv.fr ? (par exemple : demander à l'utilisateur de choisir 1 organisation sur catalogue.data.gouv.fr, une fois pour toute)
• ... si une personne rattache à son compte Datapass une deuxième organisation qui existe sur catalogue.data.gouv.fr après son inscription sur catalogue.data.gouv.fr ? (par exemple : ne rien faire)
• autres hypothèses ?

[florimondmanca]

@johanricher

quel est le choix que vous préconisez ?

Lors de l'atelier flowchart on avait envisagé l'approche 1 user - 1 orga, sur un mode "limitation pour l'instant". On s'est basé là-dessus pour le diagramme de séquence à droite du flowchart. On le voit dans l'hypothèse "len(existing_orgs) == n" : "Afficher page choix organisation", etc.

Dans le 2ème choix, que se passe-t-il

• Plusieurs orgas DataPass -> Choix d'1 orga une bonne fois pour toute
• Nouvelle orga DataPass -> Aucune conséquence, l'utilisateur garde son unique orga précédente

(Je rajouterais une autre situation : suppression du lien entre l'utilisateur et l'orga dans DataPass -> Pas sûr de ce qu'on devrait faire, qq soit le modèle adopté. Mais est-ce possible par DataPass ? Aucune indication en ce sens dans leur FAQ à ce jour.)

Si l'objectif est une sorte d'autonomie d'ici octobre, ça peut être sacrément limitant, car sauf à avoir plusieurs emails pro, un utilisateur ne peut avoir qu'1 seul compte DataPass, pas moyen de contourner. Si ?

Dans un modèle 1 user - n orgas, il faudrait décider :

• Du cas "N orgas" lors de l'inscription : prévenir l'utilisateur des différentes orgas qu'il ou elle va rejoindre ? Ne rien faire ?
• De la présentation dans l'UI des orgas auxquelles on appartient : dans la maquette, le header indique "John Doe, Ministère de la Culture" -> Y met-on toutes les orgas dont l'utilisateur est membre ? Ou seulement une "orga courante" ? (mais comment est-elle déterminée ?)
• De la présentation dans l'UI lors des écritures
  • Contribution : devra-t-on décider d'à quel catalogue on souhaite ajouter un jeu de données ? Un champ "Catalogue" dans le formulaire ? Une page préliminaire ?
  • Edition : devra-t-on "basculer" entre les orgas pour contribuer à tel ou tel catalogue ? Ou aura-t-on accès au bouton "Modifier" dès lors qu'on fait partie de l'orga correspondante ?

[johanricher]

1 user - 1 orga. 👍 Je vais compléter les critères d'acceptation en conséquence.

[DaFrenchFrog]

@johanricher @Volubyl @florimondmanca J'ai mis à jour les maquettes pour coller au workflow du compte datapass. J'ai mis les lien dans le descriptif du ticket.

[johanricher]

Pour les workflows "aucune organisation enregistrée" / "plusieurs organisations enregistrées", j'ai ajouté des commentaires sur Figma. Hormis ces points de détails pour moi c'est ok. 👍

[johanricher]

La vérification des critères d'acceptation se fera avec une personne du MC, en conditions réelles, donc après la cloture de :

• Déployer l'instance de production sur catalogue.data.gouv.fr #430
• Supprimer un champ du schéma MC catalogage-donnees-config#22
• Import du fichier catalogue du MC #456
• Gestion multi-catalogue #122

[johanricher]

C'est validé bravo à tous !