# Moog

**Rmq :** uniquement des appels à l'api platine-pilotage

- vérifier globalement les différences fonctionnelles entre les profils gestion/assistance
- vérifier la liste des campagnes disponibles
- endpoint : **GET** /api/moog/campaigns
- recherche enquêté
- rechercher un enquêté XXX
- endpoint : **GET** /api/moog/campaigns/survey-units (appelé à chaque saisie de caractère à partir de 3)
- vérifier le multipage (25 UE max par page)
- endpoint : **GET** /api/moog/campaigns/survey-units (appelé à chaque changement de page)
- rechercher selon les différentes colonnes (cf. doc Moog)
- tester le cas où le croisement idContact x idUE est mobilisé pour plusieurs campagnes
- tester le cas où un idContact est mobilisé pour plusieurs idUE de la même campagne
- tester le cas où un idContact est mobilisé pour plusieurs idUE de différentes campagnes
- consulter les événements d'un enquêté (refus, ...)
- endpoint : **GET** /api/moog/campaigns/{campaign}/survey-units/{id}/management-monitoring-infos
- ajouter des événements à un enquêté (refus, ...)
- endpoint : **POST** /api/moog/campaigns/{idCampaign}/uploads
- tester le cas où le croisement idContact x idUE est mobilisé pour plusieurs campagnes : ajouter des événements sur les différentes lignes
- tester le cas où un idContact est mobilisé pour plusieurs idUE de la même campagne : ajouter des événements sur les différentes lignes
- tester le cas où un idContact est mobilisé pour plusieurs idUE de différentes campagnes
- vérifier qu'il est impossible d'ajouter un événement si la campagne est en dehors des dates de collecte
=> + vérifier l'apparition des événements qui remontent automatiquement (INITLA, PND, PARTIELINT, VALINT, RELANCE) avec les cas complexes cités précédemment
- supprimer un événement
- endpoint : DELETE /api/moog/uploads/{id}
- accéder au site miroir de collecte : accès au bon questionnaire, en lecture seule
- tester le cas où un idContact est mobilisé pour plusieurs idUE de la même campagne
- tester le cas où le croisement idContact x idUE est mobilisé pour plusieurs campagnes => pas encore possible, à rajouter quand l'api Queen le permettra
- tester le cas où un idContact est mobilisé pour plusieurs idUE de différentes campagnes
- vérifier la possibilité de télécharger la preuve de dépôt pour un questionnaire validé
- consultation du mail d'un enquêté
- endpoint : **GET** /api/moog/contact/{id}/mail
- reinit mdp : vérifier l'url de renvoi vers le formulaire de reinit
- sélection d'une campagne : apparition des boutons vers les fonctionnalités propres à la campagne
- enregistrement d'événement de masse
- endpoint : **POST** /api/moog/campaigns/{idCampaign}/uploads
- affichage du libellé de la campagne sélectionnée
- absence bouton + message si la campagne est en dehors des dates de collecte
- tester format de fichier incorrect (casse, nommage des colonnes, statuts impossibles...)
- tester les différents statuts possibles
- tester 1 vs plusieurs événements
- tester d'ajouter plusieurs événéments pour le même idContact x idUE
- tester l'ajout d'événement sur une UE inconnue (croisement idContact x idUE inconnu pour cette campagne)
- tester le cas où un idContact est mobilisé pour plusieurs idUE de la même campagne
- tester le cas où le croisement idContact x idUE est mobilisé pour plusieurs campagnes
- suivi de collecte
- affichage du libellé de la campagne sélectionnée
- tableau d'avancement :
- endpoint : **GET** /api/moog/campaigns/{idCampaign}/monitoring/progress
- affichage de toutes les partitions
- vérifier les comptages selon les événements ajoutés, et en tenant compte des règles de priorisation, cf. doc Moog
- tableau des relances :
- endpoint : **GET** /api/moog/campaigns/{idCampaign}/monitoring/follow-up
- message en l'absence de relance
- affichage de toutes les relances et partitions
- vérifier comptages selon relances effectuées
=> attention sur le fonctionnement de ce tableau pour les comptages : si je relance l'UE A, puis plus tard je relance les UE A+B, dans le tableau la 1e relance comptera les 2 UE et la 2e relance ne comptera que l'UE A
- relancer des enquêtés
- endpoint : **GET** /api/moog/campaigns/{idCampaign}/survey-units/follow-up
- affichage du libellé de la campagne sélectionnée
- absence bouton + message si la campagne est en dehors des dates de collecte
- vérifier la liste des UE présentes dans l'extraction
- tester le cas où un idContact est mobilisé pour plusieurs idUE de la même campagne
- tester le cas où le croisement idContact x idUE est mobilisé pour plusieurs campagnes
- vérifier l'indicatrice de PND
- consultation d'archives
- affichage des archives
- endpoint : **GET** /api/moog/campaigns/{idCampaign}/uploads
- suppression d'une archive
- endpoint : **DELETE** /api/moog/uploads/{id}
- archive créée par un upload unitaire (depuis la recherche d'enquêté) : vérifier suppression de l'événement
- archive créée par un upload de masse : vérifier suppression de l'événement

- console d'admin
- la liste des campagnes disponibles
- endpoint : **GET** /api/moog/campaigns
- extraction des données d'une campagne
- endpoint : **GET** /api/moog/campaigns/{idCampaign}/extraction
- modification d'une campagne (label, dates)
- endpoint : **PUT** /api/moog/campaigns/{id}
- suppression de campagne
- endpoint : **DELETE** /api/moog/campaigns/{id}
=> attention : pas intuitif sur le swagger, rangé dans le groupe metadata
- vérifier la suppression impossible si campagne en période de collecte

# Parcours répondant

- authentification
- modification de mdp à première connexion
- ajout/modification de l'adresse mail si portail paramétré à true
- absence de composant d'ajout/modification de l'adresse mail si portail paramétré à false
- reinit de mdp avec mail connu
- reinit de mdp sans mail connu
- aiguillage
- cas de redirection vers portail mes enquêtes
- cas de redirection directe vers le questionnaire
- cas enquêté 0 (pas de collecte en cours) : reste sur promotion avec message associé
- cas de collecte en cours : renvoie vers le bon questionnaire
- portail mes enquêtes
- vérifier la présence du bouton d'accès au questionnaire selon les dates (voir la règle précise)
- bouton présent : renvoie vers le bon questionnaire
- questionnaire
- vérifier la personnalisation de la page de garde (métadonnées campagne + personnalization UE)
- tester la persistence des données ?? (niveau séquence)
- déconnexion par inactivité ??
- bouton de déconnexion en cours de questionnaire
- persistence des données
- renvoi vers la bonne page (promotion ou portail mes enquêtes)
- déconnexion effective (nécessite de se re log pour se reconnecter)
- passage batch SynchronizeQuestionnaireStates pour capter le init questionnaire)
- validation questionnaire
- passage batch SynchronizeQuestionnaireStates pour capter le validated questionnaire
- téléchargement preuve de dépôt
- déconnexion (idem à bouton déco du menu, mais pas besoin de check la persistence)
- reconnexion sur un questionnaire validé ?? (retour sur page de téléchargement de preuve de dépôt)
- formulaire assistance
- envoi de formulaire d'assistance sans être authentifié
- envoi de formulaire d'assistance en étant authentifié

# API pilotage webclients

Voir avec Audrey :smirk:

# API pilotage - intégration - suppression (hors webclients)

- création de owner
- création de support
- création de source
- création de survey
- création de campaign
- création de partitioning

# API questionnaire - intégration - suppression (hors webclients)

- création du contexte de campagne : **POST** api/campaign/context

# Batchs

## sampleProcessing

Vérifier que les différentes étapes du batch fonctionnent :
- cas de l'intégration d'UE
- création d'un compte (id/mdp) dans l'annuaire pour l'UE (step ldap) - (se connecter avec ce compte pour voir si ça fonctionne)
- création de l'UE dans Platine pilotage (step pilotage)
- création de l'UE dans Platine questionnaire (step datacollection)
- création d'un fichier calc contenant les id/mdp créés pour chaque UE (step outputfile - uniquement en recette)
- création d'un fichier xml à destination de l'éditique dans le cas d'une demande d'envoi de courrier (step output - <Option type="destination-postalmail">yes</Option>)
- si <Option type="destination-RNVP">no</Option>, le fichier doit être créé dans le dossier `\\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\out\editique` (pour la dv2)
- si <Option type="destination-RNVP">yes</Option>, le fichier doit être créé dans le dossier `\\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\out\editique\rnvp` (pour la dv2)
- dans les 2 cas, le fichier doit être aussi créé dans le dossier `\\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\out\sampleProcessing\enquête...\...\courrier\` (sauvegarde du fichier)
- dans le fichier xml en sortie, vérifier la présence de Ue_CalcIdentifiant et Ue_CalcMotDePasse
- réception d'un mail dans le cas d'une demande d'envoi de mail (step output - <Option type="destination-mail">yes</Option>)
- création de l'état INITLA dans Moog : à vérifier directement dans Moog ou bien dans la base Platine pilotage avec le endpoint GET /api/moog/campaigns/{campaign}/survey-units/{id}/management-monitoring-infos (step moog - <Goal>create</Goal>)

- cas de la relance d'UE déjà créées : attention, le contenu du fichier sampleProcessing est différent du cas d'au-dessus, avec notamment une variable `IdeC` qui correspond à l'identifiant de connexion et qui est à mettre dans la balise `Contact`
- création d'un fichier xml à destination de l'éditique dans le cas d'une demande d'envoi de courrier (step output - <Option type="destination-postalmail">yes</Option>)
- dans le fichier xml en sortie, vérifier notamment la présence de la variable `Ue_CalcIdentifiant` qui doit être égal à `IdeC`
- réception d'un mail dans le cas d'une demande d'envoi de mail (step output - <Option type="destination-mail">yes</Option>)
- dans le mail reçu, vérifier notamment la présence de l'identifiant de connexion (qui doit correspondre à la valeur de la variable `IdeC`)
- création de l'évènement RELANCE dans Moog : à vérifier directement dans Moog ou bien dans la base Platine pilotage (évènement FOLLOWUP) avec le endpoint GET /api/moog/campaigns/{campaign}/survey-units/{id}/management-monitoring-infos (step moog - <Goal>update</Goal>)

- cas d'une séquence 2 d'un enquête à séquences (type enquête Logement) - préalable : avoir supprimé la campagne dans la base Platine questionnaire (mais pas dans Platine pilotage)
- intégration d'UE avec idUe et idcontact existants en base Platine pilotage (vérifier qu'on retrouve bien dans Moog)
- création d'un fichier xml à destination de l'éditique dans lequel on doit trouver la variable `Ue_CalcIdentifiant` égale à `IdeC` mais pas le mdp (avec options ouverture/web dans step output)

- tests spécifiques à l'envoi de courriers
- vérifier le calcul du nom du fichier xml de sortie selon les options mises dans output ("operation-type", "operation-mode","operation-protocol","with-questionnaire")
- vérifier dans le fichier xml de sortie que les variables suivantes sont présentes et se calculent comme il faut :
- IdOperation = concaténation de COLM_ + `idSource` + _ + MODE + PROTOCOLE + _ + TYPE + (_ QST) ; avec MODE = TEL/FAF/WEB selon la valeur de la variable `operation-mode` , PROTOCOLE = SEQ/PAN ou `vide` selon la valeur de la variable `operation-protocol` , TYPE = OUV/REL/LIB selon la valeur de la variable `operation-type` et QST si `with-questionnaire` vaut yes
- TypeGenerateur = courrier_fo
- PartieNomFichierLibreZip = concaténation de `idSource` + _ + `millesime` + _ + MODE + PROTOCOLE + _ + TYPE ; avec MODE = TEL/FAF/WEB selon la valeur de la variable `operation-mode` , PROTOCOLE = SEQ/PAN ou `vide` selon la valeur de la variable `operation-protocol` , TYPE = OUV/REL/LIB selon la valeur de la variable `operation-type`
- Barcode = IS + date de dépôt du courrier sur 3 positions (=numéro de jour dans l'année, par exemple le 11/10/2023 est le jour n° 284 de l'année 2023) + numéro d'édition tronqué des 2 premiers caractères + `Identifiant` + des espaces pour arriver à 35 caractères ==> pas besoin de vérifier le calcul exact du barcode (je l'ai mis pour qu'on ait en tête comment il est calculé), mais peut-être juste vérifier sa présence et le fait qu'on retrouve bien l'identifiant de l'UE `Identifiant` dedans
- InitAccuseReception = non
- NumeroDocument : vérifier la présence de cette variable qui correspond au numéro du document dans le fichier (commence à 00000001)
- AdresseRetourL1 à AdresseRetourL7 : vérifier la présence de ces variables dans le fichier, elles sont toujours à vide
- CodePostalDestinataire = `CodePostal`
- BddIdentifiantUniteEnquetee = `Identifiant`
- BddAdressePosteeL1 = concaténation de `Civilite`, `Prenom`, `Nom`
- BddAdressePosteeL2 = `ComplementAdresse` (ou partie de `ComplementAdresse` inférieure à 38 caractères dans le cas où `ComplementAdresse` > 38 caractères)
- BddAdressePosteeL3 = partie de `ComplementAdresse` supérieure à 38 caractères (cas où `ComplementAdresse` > 38 caractères)
- BddAdressePosteeL4 = concaténation de `NumeroVoie` `IndiceRepetition` `TypeVoie` et `LibelleVoie`
- BddAdressePosteeL5 = `MentionSpeciale`
- BddAdressePosteeL6 = concaténation de `CodePostal` et `LibelleCommune`
- BddAdressePosteeL7 = FRANCE (en dur a priori)
- vérifier que `&amp;#x2028;` en entrée de batch se transforme en `&#x2028;` en sortie de batch (c'est le code pour signifier un retour à la ligne pour l'édition des courriers par l'éditique) => tester avec `<Enq_MailAssistance>https://enquetes.stat-publique.fr/tic&amp;#x2028;Rubrique « Contacter l’assistance »</Enq_MailAssistance>`
- tester le cas où il manque une variable dans la balise `Metadonnees` ou dans la balise `Metadonnees_Ue` par rapport au modèle souhaité (normalement plantage du batch)
- tester le cas où il y a une variable en trop dans la balise `Metadonnees` ou dans la balise `Metadonnees_Ue` par rapport au modèle souhaité (normalement le batch filtre et c'est ok)
- tester l'option use-sample dans le step output `<Option type="use-sample">yes</Option>`
- si `yes`, ça doit aller chercher les infos dans le fichier de perso et pas dans Platine pilotage
- si `no`, ça va chercher dans Platine pilotage
- tester l'envoi d'un courrier avec questionnaire
- vérifier le nommage du fichier xml en sortie
- vérifier le calcul de IdOperation (avec `_QST` à la fin)
- tester l'envoi d'un courrier non standard
- vérifier le nommage du fichier xml en sortie
- vérifier le calcul de IdOperation = COLM_ `idSource` _ CUST

- Tests spécifiques à l'envoi de mails
- vérifier la présence des modèles de mails sous applishare (sur chaque plateforme dv, dv2, beta, prod)
- tester l'envoi des mails standards pour tous les modèles existants ("operation-type", "operation-mode","operation-protocol")
- tester l'envoi d'un mail non standard

## extractdata
(= extraction différentielle des données et des paradonnées)

préalable : avoir validé le questionnaire d'une ou plusieurs UE

vérifier pour chaque campagne où des UE ont été validées (càd que l'état de questionnaire de l'UE = VALIDATED) :
- la création d'un fichier data.diff.IDCAMPAGNE.JOUR_ET_HEURE_DE_L_EXTRACTION.xml dans `\\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\out\extractData\extractdata\IDCAMPAGNE\differential\data` contenant les données de questionnaire de chacune des UE validées
- la création d'autant de fichier de paradatas que d'UE extraites : paradata.diff.IDCAMPAGNE.IDUE.json dans `\\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\out\extractData\extractdata\IDCAMPAGNE\differential\paradata`

Vérifier pour les UE extraites le passage d'état de questionnaire à EXTRACTED

NB : pour consulter l'état de questionnaire d'une UE => api platine questionnaire : state-data-controller endpoint **GET** /api/survey-unit/id/state-data

## extractdataComplete

vérifier l'extraction des datas/paradatas des validés/partiels pour une campagne (faire plusieurs tests pour voir si ça extraie bien ce qui est demandé : uniquement les datas des partiels, datas+paradatas des validés, datas+paradatas des validés+partiels, etc.)
- Pour les datas : création d'un fichier data.complete.partial.IDCAMPAGNE.JOUR_ET_HEURE_DE_L_EXTRACTION.xml dans `\\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\out\extractData\extractdata\IDCAMPAGNE\complete\data`
- Pour les paradatas : création de fichiers paradata.complete.IDCAMPAGNE.IDUE.json pour chaque UE extraite dans `\\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\out\extractData\extractdata\IDCAMPAGNE\complete\paradata`
- une extraction des partiels (que ce soit les datas ou paradatas) doit faire l'extraction pour les UE dont l'état de questionnaire est à INIT
- une extraction des validés (que ce soit les datas ou paradatas) doit faire l'extraction pour les UE dont l'état de questionnaire est >= VALIDATED (en pratique aujourd'hui : VALIDATED/EXTRACTED)

NB : pour consulter l'état de questionnaire d'une UE => api platine questionnaire : state-data-controller endpoint **GET** /api/survey-unit/id/state-data

## importPND

préalable : avoir une campagne en cours de collecte

Démarche générale :
- préparer un fichier fictif de PND de la forme de ceux qu'on reçoit de l'éditique avec des UE qui appartiennent à une campagne en cours de collecte
- mettre le fichier dans le dossier \\hp_as_st_d2_50\st_data_hp\sic_dv2\batch\in\editique
- lancer le batch importPND
- vérifier que le fichier a été traité : déplacé du dossier `...\editique` au dossier `...\editique\treated`
- vérifier dans Moog que l'évènement PND est bien ajouté aux UE qui étaient dans le fichier (si elles sont bien dans le champ, voir les cas de tests ci-dessous)

Cas de tests :
- une UE dans une campagne en cours
- une UE dans une campagne pas démarrée
- une UE dans une campagne terminée
- une UE en interséquence
- etc. (jouer sur les dates et s'assurer notamment des dates limites jour de début de collecte, jour de fin de collecte)
- 2 fichiers PND en même temps dans le dossier

## reinitPasswordPostalMail

- faire une demande de nouveau mot de passe via le portail de promotion
- pour un compte sans adresse email
- pour un 2e compte sans adresse email
- pour un compte avec adresse email
- vérifier que les fichiers de demandes unitaires sont créées sous applishare Platine : 2 demandes (les 2 pour qui il n'y avait pas d'adresse email)
- lancer le batch reinitPasswordPostalMail
- vérifier la création du fichier xml pour l'éditique (un fichier avec les 2 UE ci-dessus)
- vérifier le bon fonctionnement du nouveau mot de passe (dans les 2 cas mail/courrier)

## synchronizeQuestionnaireStates

- pour une UE, valider un questionnaire
- pour une autre UE, démarrer le questionnaire sans le valider
- lancer le batch synchronizeQuestionnaireStates
- vérifier dans Moog :
- l'ajout de l'évènement VALIDATED pour la 1ère UE (ainsi que l'horaire)
- l'ajout de l'évènement PARTIELINT pour la 2e UE (ainsi que l'horaire)
(possibilité aussi de vérifier dans la base Platine pilotage)

Nb : actuellement l'horaire de l'événement est celui du passage du batch, et non pas celui de modification de l'état du questionnaire

# Autres

- test du flux interapplicatif d'import des PND depuis l'éditique vers l'applishare Platine (UNIQUEMENT EN PROD, nécessite de se coordonner avec l'éditique) - à vérifier lorsqu'il y a une migration applishare ou autre
- vers le dossier `\\pd_as_st_d1_50\st_data_pd\sic_pd\batch\in\editique` quand enquête web sous Platine
- vers le dossier `\\pd_as_st_d1_50\st_data_pd\sic_pd\batch\in\editique\hors-platine` sinon

- test du flux interapplicatif de dépôt des fichiers de courriers de Platine vers l'editique (UNIQUEMENT EN PROD, nécessite de se coordonner avec l'éditique)
- cas RNVP = yes
- cas RNVP = no

#

idées : chargement de masse d'event dans moog