---
tags: 🐔 construction cocorico 🐔
---
# API Pilotage SIC

Modèle de données: https://github.com/InseeFrLab/datacollection-management-api/tree/master/docs

## Domaine Contacts

### Besoins

- Portail: Affichage/modification des informations perso (identité, adresse ...) - onglet mon compte
- Pilotage: Affichage/modifications des informations perso (identité, adresse ...) - onglet gestion des contacts
- Pilotage: suivi des modifications d'un contact (gestion des contact-events)
:::info
:straight_ruler: Processus de création d'un contact (pour Coltrane: via batch ou Pilotage)
- création d'un contact via l'annuaire -> __idec__ :+1:
- création en base du contact (avec le même idec)
- pas de ~~POST~~ : _/contacts_ -> on ne l'implémente pas, n'a pas trop de sens d'un point de vue identifiant (Rappel: POST permettrait de créer un contact sans identifiant donné en entrée)
:::

### Endpoints nécessaires

#### Domaine Contact

- [x] PUT : _/contacts/{id}_
- Renvoie 201 si create
- Renvoie 200 si update
- Adresse optionnelle

  {
    "identifier": "string",
    "civility": "string",
    "lastName": "string",
    "firstName": "string",
    "function": "string",
    "email": "string",
    "phone": "string",
    "address": {
      "streetNumber": "string",
      "streetName": "string",
      "city": "string",
      "zipCode": "string",
      "countryName": "string"
      }
    }
    OU
      {
    "identifier": "string",
    "civility": "string",
    "lastName": "string",
    "firstName": "string",
    "function": "string",
    "email": "string",
    "phone": "string"
    }

- [x] GET : _/contacts/{id}_

  {
    "identifier": "string",
    "civility": "string",
    "lastName": "string",
    "firstName": "string",
    "function": "string",
    "email": "string",
    "phone": "string",
    "address": {
      "streetNumber": "string",
      "streetName": "string",
      "city": "string",
      "zipCode": "string",
      "countryName": "string"
      }
    }

- [x] DELETE : _/contacts/{id}_
Suppression en cascade de l'adresse du contact et de ses contactEvents
(correction faite: suppression de view + habilitations)

- pas de ~~POST~~ : _/contacts_ (cf Besoins)

#### Address

- [x] GET _/contacts/{id}/address_

{
    "streetNumber": "string",
    "streetName": "string",
    "city": "string",
    "zipCode": "string",
    "countryName": "string"
}

:warning: champs d'adresse à modifier selon la modélisation harmonisée

- [x] PUT _/contacts/{id}/address_

{
    "streetNumber": "string",
    "streetName": "string",
    "city": "string",
    "zipCode": "string",
    "countryName": "string"
}

- Pas de POST et de DELETE (delete géré en cascade lors d'un delete contact)

#### ContactEvents

:::warning
:question: qui a la responsabilité de les créer ? ~~Front~~ :-1: Back :+1:

- Si Front :
- GET (pour pilotage et monCompte)
- POST (le front le fait après réponse positive après un PUT)
- DELETE (en cas de création par erreur)

- Si Back :
- implémente une seule transaction lors d'un appel en écriture d'un autre end-point:+1:
- GET (pour pilotage et monCompte)

:::

:::info
:straight_ruler: Règles sur les events
- si besoin d'aggrégation -> calcul côté back (en tps réel :warning:: c'est couteux en temps de calcul ou vue (process de mise à jour, tous les combien de temps ?) -> à étudier, voir paramétrage possible)
- ex: tableau de suivi Moog (% d'avancement)
- sinon, on renvoie tout côté front
- ex: mesEnquetes -> tous les questioning Events, "j'ai déjà répondu", "à compléter", etc... -> le front prend le dernier event
:::

- [x] GET : _/contacts/{idec}/contact-events_
- renvoie toutes la liste des events : le front se débrouille pour les ranger et calculer le "dernier" event

{
    content : [
        {
            id,
            idec,
            date,
            type,     
            payload
        },
        { id, idec, date, type, payload},
        ...
    ]
}

- [x] :question: POST : _/contacts/{idec}/contact-events_

 {
    id,
    idec,
    date,
    type,     
    payload
}

- [x] :question: DELETE : _/contact-events/{id}_
:warning: les suppressions d'events ne se font que via la suppresion de l'entité correspondante (suppression en cascade). Cet endpoint est utile en cas de création par erreur.

## Domaine Questioning

### Operator
- Operator : Insee/SSP/DARES : qui a la responsabilité de la gestion de l'opération statistique, MOA d'enquête, support assistance niveau 2 (mail d'assistance) ("service collecteur")
:::warning
:question: revérifier les définitions de Operator, Owner, OperatorService...
:::

### Questioning

- [x] POST : _/questioning_
- params :
- surveyUnit
- partitioning (allotissement)
- model de questionnaire
- operatorService ?

- [x] GET : _/questioning/{id}_
### SurveyUnit

- [x] POST : _/survey-unit_

{
    idSurveyUnit : technique -> unique !!!!,
    identificationCode : (metier) n° SIRET ou SIREN, (peut-être vide dans le cas ménage)
    identificationName : (à la place de companyName),
    address : { 
     niveau donnée : peut-être la même que celle du contact
     voir la modélisation harmonisée !!!
    }
}

- [x] GET : _/survey-unit/{id}_
- [x] GET : _/survey-unit/{id}/questionings_ ?? à voir, peut-être utile pour de la maintenance, pas prioritaire en tout cas !

### QuestioningAccreditation

- [x] POST _/questionings/{idQuestioning}/questioning-accreditation
- params :
- isMain : true/False
- idec: id du contact
:::warning
:question: Mise à jour de la table pivot idec/idSu/CampaignId
:::

- [x] Ajout du GET _/questionings/{idQuestioning}/questioning-accreditation

### QuestioningEvents

- [x] POST : _/questionings/{idQuestioning}/questioning-event_

{
    idQuestioning,
    date,
    type [ex pour questioning enum : ] 
    @IEnum -> chaque classe d'event implémente son Enum (4 Enums : UserEvent, CampaignEvent, ContactEvent, QuestioningEvent)
    payload: (jsonb in Postgre) : optionnel 
}

- [x] GET : _/questionings/{idQuestioning}/questioning-events_
- récupère tous les events assaocié à un questionings
- (pour Moog, MesEnquêtes, Pilotage)

## Multi-domaines

### Besoins

- Pilotage: recherche de contacts multi-critères
- Pilotage: affichage des accreditations d'un contact
- CheckAccreditation (idSurveyUnit,idContact,idPartionning)
- Moog: recherche
- Moog: suivi
- Portail: mesEnquetes

### Pilotage : recherche de contacts multi-critères

- [x] search (cf [swagger](https://datacollection-management-api.dev.insee.io/swagger-ui/index.html))
- _/contacts?identifier=xxx&name=yyy&email=[e-mail]_

{
    content : [
        {result1}, {result2}
    ]
}

### Pilotage : affichage des accréditations d'un contact

- [x] GET _/contacts/{idec}/accreditations_

{
    content : [
        {result1}, 
        {result2}
    ]
}

### Portail: mesEnquetes

- _/my-questionings/{idec}_ (avant my-surveys encore avant mes-enquêtes)
- Ajouter dans la réponse de ce end-point l'idQuestioning de toutes les enquêtes
- :question: comment récupérer les questioningEvents pour chaque questioning
- le front boucle sur les ids
- compilé par le back dans la requête _/my-questionings_

### Moog: suivi

- :question: compilation des questioningEvents ??
- :question: endPoint spécial ? , calcul en BDD ?

## Glossaire
**Operator et OperatorService**:
Gestionnaire et service Gestionnaires= personnes et services en charge de l'assistance. Un questionanire peut être géré par plusieurs gestionnaires. Attention, un même gestionnaire peut être en charge de plusieurs enquête et avoir un numéro de téléphone différent pour chacune.
En cas de demande d'aide: tel du gestionnaire et mail du service. Si le service gestionnaire a une adresse: mail du service, sinon mail du service collecteur(Support)

**Support**
Service collecteur

    <ServiceCollecteur>
        <Identifiant>PEE</Identifiant>
        <Nom>Insee Occitanie - PEE</Nom>
        <Telephone>0123456789</Telephone>
        <AdresseMessagerie>[e-mail]</AdresseMessagerie>
        <Adresse>
            <NumeroVoie>36</NumeroVoie>
            <TypeVoie>Rue</TypeVoie>
            <LibelleVoie>des 36 Ponts</LibelleVoie>
            <MentionSpeciale>BP 94217</MentionSpeciale>
            <CodeCedex>31054</CodeCedex>
            <LibelleCedex>TOULOUSE CEDEX 4</LibelleCedex>
        </Adresse>
        <ChefSignataire>
            <Fonction>Le directeur des Statistiques d'Entreprises</Fonction>
            <Nom>Sylvain MOREAU</Nom>
        </ChefSignataire>
    </ServiceCollecteur>
    <ServiceCollecteur>
        <Identifiant>DARES</Identifiant>
        <Nom>DARES-ACEMOTRIM</Nom>
        <Telephone>0100000000</Telephone>
        <AdresseMessagerie>[e-mail]</AdresseMessagerie>
        <Adresse>
            <NumeroVoie>39-43</NumeroVoie>
            <TypeVoie>Quai</TypeVoie>
            <LibelleVoie>ANDRE CITROEN</LibelleVoie>
            <ComplementAdresse>DEPT SCS - POLE ACEMO</ComplementAdresse>
            <CodeCedex>75902</CodeCedex>
            <LibelleCedex>PARIS CEDEX 15</LibelleCedex>
        </Adresse>
        <ChefSignataire>
            <Fonction>Le sous-directeur de la DARES</Fonction>
            <Nom>Malik KOUBI</Nom>
        </ChefSignataire>
    </ServiceCollecteur>
    <ServiceCollecteur>
        <Identifiant>PIPA</Identifiant>
        <Nom>DARES - DEPT SCS</Nom>
        <Telephone>0100000000</Telephone>
        <AdresseMessagerie>[e-mail]</AdresseMessagerie>
        <Adresse>
            <NumeroVoie>39-43</NumeroVoie>
            <TypeVoie>Quai</TypeVoie>
            <LibelleVoie>ANDRE CITROEN</LibelleVoie>
            <CodeCedex>75902</CodeCedex>
            <LibelleCedex>PARIS CEDEX 15</LibelleCedex>
            <ComplementAdresse>Département SCS</ComplementAdresse>
        </Adresse>
        <ChefSignataire>
            <Fonction>Le sous-directeur de la DARES</Fonction>
            <Nom>Malik KOUBI</Nom>
        </ChefSignataire>
    </ServiceCollecteur>
    <ServiceCollecteur>
        <Identifiant>SSNE</Identifiant>
        <Nom>Insee Normandie - SSNE</Nom>
        <Telephone>0123333333</Telephone>
        <AdresseMessagerie>[e-mail]</AdresseMessagerie>
        <Adresse>
            <NumeroVoie>5</NumeroVoie>
            <TypeVoie>Rue</TypeVoie>
            <LibelleVoie>Claude Bloch</LibelleVoie>
            <MentionSpeciale>BP 95137</MentionSpeciale>
            <CodeCedex>14024</CodeCedex>
            <LibelleCedex>CAEN CEDEX</LibelleCedex>
        </Adresse>
        <ChefSignataire>
            <Fonction>Le directeur régional de l'Insee Normandie</Fonction>
            <Nom>Philippe SCHERRER</Nom>
        </ChefSignataire>
    </ServiceCollecteur>

**Owner**
Service producteur

    <ServiceProducteur>
        <Identifiant>INSEE</Identifiant>
        <Article>l'</Article>
        <Libelle>Institut national de la statistique et des études économiques</Libelle>
        <MinistereTutelle>de l'Économie, des Finances et de la Souveraineté industrielle et numérique</MinistereTutelle>
        <Logo>
            <Identifiant>1</Identifiant>
        </Logo>
        <ChefSignataire>
            <Fonction>Le directeur des Statistiques d'Entreprises</Fonction>
            <Nom>Sylvain MOREAU</Nom>
        </ChefSignataire>
    </ServiceProducteur>
    <ServiceProducteur>
        <Identifiant>DARES</Identifiant>
        <Article>la </Article>
        <Libelle>DARES</Libelle>
        <MinistereTutelle>du Travail</MinistereTutelle>
        <MinistereTutelle>de l'Économie, des Finances et de la Souveraineté industrielle et numérique</MinistereTutelle>
        <Logo>
            <Identifiant>2</Identifiant>
        </Logo>
        <ChefSignataire>
            <Fonction>Le sous-directeur de la DARES</Fonction>
            <Nom>Malik Koubi</Nom>
        </ChefSignataire>
    </ServiceProducteur>
``