--- tags: 🐔 construction cocorico 🐔 --- # 🐔 Pilotage ## 🔒 Rôles - 🔒 accès à l'application -> rôles dans LDAP - repondant : pour les contacts - internal_user : pour les utilisateurs internes (gestionnaire, assistance, admin, ...) - web_client : les API externes qui communique avec Pilotage (Protools par ex.) - 🙎 habilitations et droits fins -> rôles en BDD - repondant ~ check_habilitation - internal_user : on regarde son rôle dans la BDD + ses habilitations aux enquêtes ~ créer méthode check_habilitations pour les "internal_user" - web_client : pas de restriction à priori, a accès à tout ? - Mode noauth : - droits internal_user appliqués - accés total aux différents services ## 🚊 Aiguillage Cocorico [🐔 Aiguillage, évolution pour Cocorico - HackMD](https://hackmd.io/@laurentC35/BkhbeunGo) ## Fonctionnalités ### Fonctionnalités MVP - PILOTAGE-API #### Évolution modèle de donnée - [ ] __contact__ : - ajouter nouvel attribut `externalId` (sert à identifier à faire la correspondance entre le contact en base et le contact correspondant venant de l'extérieur de l'Insee (contact DARES, SSM agri)) - ajouter nouvel attribut `emailVerify` (booléen à false) (hors MVP mais pas cher) - ajouter nouvel attribut `firstLogin` : booléen à true par défault - [ ] __partitionning__ : ajouter un nouvel attribut `label` - [ ] __adresse__ : [cf carte trello](https://trello.com/c/1pbNERwX/1601-instruction-sur-la-mod%C3%A9lisation-des-adresses-dans-sabiane-et-coleman-cocorico-coltrane) #### Évolution des end-points (Protools) - [ ] GET __/api/main-contact?campaign=xxx&survey-unit=yyy__ : pour savoir à quel contact envoyer les courriers/mails, on interroge Coleman-Pilotage pour savoir qui est le contact principal. (même objet que _/api/contacts/{id}_) - [ ] PUT __/api/metadata__ ([cf note end-point Protools](https://hackmd.io/nR7BU9cySR-zWTFWun8p5A?view#Metadata), permet de créer d'alimenter le domaine Metadata, autrement dit, créer des partitions) - [ ] PUT __api/questionning__ ([cf note end-point Protools](https://hackmd.io/nR7BU9cySR-zWTFWun8p5A?view#UEContact) ### Fonctionnalités MVP - PILOTAGE-IHM - [ ] Onglet "Enquetes" simples, où l'on voit les enquêts en base avec les metadata - [ ] Mettre à jour l'IHM avec la nouvelle modélisation d'adresse ### 📧 Modification Email **Remarque** : l'email ne sera pas dans le LDAP, seulement l'**idec** et les **rôles applicatifs** #### Circuit "enquêté-contact-répondant" 1. L'utilisateur change l'email dans l'application, PUT sur _/api/contacts/{idec}/email_ | Steps | Actions back | Table BDD | Service-externe | HTTP | | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ----------------- | ----------------------- | | **1** | passer l'attribut "emailVerify" du contact idec à false | contact 🔄 | | | | **2** | créer lien avec token unique avec timestamp (h+12h) | | | | | **3** | créer nouvelle ligne dans table "mail_change" (idec,new_email,token,timeout:h+12h) ou mise à jour si une ligne avec cet idec existe (on recommence) | mail_change ➕ | | | | **4** | demande d'envoie de mail avec ce lien au nouveau mail | | RadioHead ou SPOC | | | **5** | créer un contact-event de type 'try-email-change' | contacts_events ➕ | | | | **6.1** | Réponse au front succès de prise en compte | | | 202 - Accepted | | **6.2** | Réponse au front si idec n'existe pas | | | 404 - Not Found | 2. L'utilisateur consulte son mail et click sur le lien https://mes-enquetes.dev.insee.io/verifier-mail?token=xxxxyyy25qfHnlakjAidnKJLKJ 3. le front appel le back avec _/api/email-validation?token=xxxxyyy25qfHnlakjAidnKJLKJ_ | Steps | Actions back | Table BDD | HTTP | | -------- | ---------------------------------------------------------------------------------------------------- | --------------------------- | ----------------- | | **1** | Verification du token et si le timestamps est bon par rapport à la date/heure | mail_change 🔍 | | | **2.OK** | passer l'attribut "emailVerify" du contact idec à true + mise à jour du mail (cf table mail_change) | mail_change 🔍 + contact 🔄 | | | **3.OK** | suppression de la ligne dans table "mail_change" (celle avec le token) | mail_change ❌ | | | **4.OK** | créer un contact-event de type 'email-change' | contacts_events ➕ | | | **5.OK** | Réponse au Front | | 200 - OK | | **2.KO** | Réponse au Front | | 400 - Bad request | | Résultat | Actions Front | Actions Back | |:------------------------------------- |:---------------------------------------------------------------------- |:-------------------------- | | OK :heavy_check_mark: | retourner à mon compte | Mets à jour le mail en BDD | | KO :negative_squared_cross_mark: | Message KO pour le front expliquant la raison (timeout, lien invalide) | Rien | 7. Le lien est identifiant, pas besoin d'être connecté pour valider le mail - **Front** : la route "_/verifier-mail_" n'est pas protégé par l'authentification - **Back** : le end-point "_/api/email-validation_" n'est pas protégé par l'authentification #### Circuit "gestionnaire" ou "assistance" Même circuit, sauf que c'est l'assistance qui modifie l'adresse mail. __FRONT : _Nouvelle Route à prévoir___ - _/verifier-mail_ : non protégé par KC - si OK : message "Votre email a bien été modifié" + bouton invitant à retourner à mon compte "Consulter mon compte" -> redirect vers _/portail/mon-compte_ - si KO : message en fonction de l'erreur : - "Le lien n'est plus valide." - "Une erreur est survenue, veuillez recommencer." __BACK : _Nouveau end-points à prévoir___ - __PUT__ : _/api/contacts/{idec}/email_ : protégé par KC - data : `{ "email" : "nouveau@cocorico.fr" }` - __POST__ : _/api/email-validation?token={token}_ : sans protection KC - queryParam : token ## Fonctionnalités Pilotage ### Maquette d'écran [🖥️ Maquette d'écran](https://viewer.diagrams.net/?tags=%7B%7D&highlight=0000ff&edit=_blank&layers=1&nav=1&title=cocorico-pilotage.drawio#Uhttps%3A%2F%2Fraw.githubusercontent.com%2FlaurentC35%2Fdrawio%2Fmain%2Fcocorico-pilotage.drawio) # :construction_worker: La suite est en cours de réflexion :construction_worker: :construction: :construction: :construction: :construction: :construction: :construction: :construction: :construction_worker: ### Contacts Existant: - [ ] Rechercher un Contact - [ ] Associer/dissocier des droits - [ ] Créer un contact - [ ] Mettre à jour un contact - [ ] Consulter une unité enquêtée :new: - [ ] Rechercher une UE :new: ## Assistance ### Contacts - [ ] Renouveler un mot de passe - [ ] Modifier information contacts - email ? ## Super Admin - [ ] Recherche utilisateur (annuaire et/ou bdd pilotage) - idep - nom, prénom - [ ] Ajouter un utilisateur (existant dans l'annuaire) - [ ] Ajouter/supprimer droits annuaire - [ ] Ajouter droits base pilotage - Administrateur - Responsable / Gestionnaire - sources à choisir (liste déroulante) - Assistance (Insee Contact ?) - toutes les sources - [ ] ## Idée migration pour COLTRANE tout en gardant orbeon Migration Big-Bang de la partie Pilotage et Mes-Enquêtes pour Coltrane. - mapping des données (données coltrane données cocorico) : voir avec Jérémy Léonard + Guylène pour étudier le mapping - branchement orbeon à "mes-enquêtes" ? - pas d'évolution aiguillage à prévoir, mes-enquêtes s'appuiesur la partie pilotage aussi - évolution des batchs d'intégration à prévoir - évènements orbeon "questionnaire commencer/validé" -> comment les propager ? - évolution orbeon pour appeler l'api pilotage : - possible : créer nouvelle librairie "externe" orbeon - s'inspirer de "[stromae-logging](https://github.com/InseeFr/Stromae/tree/main/stromae-logging)" - cette librairie est une servlet, il faut l'ajouter au web.xml sur le end-point de validation (ou de sauvegarde) - dans la servlet, appeler la nouvelle api-pilotage pour créer des contacts-event