# Doc Flux

## Flux 3 accès aux candidatures transmises aux bailleurs

Pour répondre à ce besoin deux routes accessiblent via l'API :

- GET api/dmo/housing_offers/with_validated_applications
- GET api/dmo/housing_offers/with_validated_applications/{id}

### Paramètre obligatoire : "from"

Pour ces deux appels est nécessaire le paramètre **"from"**.

    {uri}?for={yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}

Paramètre de filtrage pour limiter la date minimale de passage au statut "TRANSMIS BAILLEUR".

### Paramètres de recherche accessibles

Il est possible d'employer tous les champs et utilitaires de recherche accessibles pour les offres.

### Autre paramètre optionnel : "to"

Pour ces deux appels, est possible l'utilisation du paramètre **"to"**.

    {uri}?to={yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}

Paramètre de filtrage pour limiter la date maximale de passage au statut "TRANSMIS BAILLEUR".

### Liste des offres ayant des candidatures au statut "TRANSMIS BAILLEUR"

uri :

    GET api/dmo/housing_offers/with_validated_applications?from={yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}

Affiche la liste des offres ayant une ou plusieurs candidatures au statut **"TRANSMIS BAILLEUR"**, et qui ont pris ce statut depuis **"from"**.

### Liste des candidatures ayant l'état "TRANSMIS BAILLEUR" pour une offre donnée

uri :

    GET api/dmo/housing_offers/with_validated_applications/{id}?from={yyyy}-{mm}-{dd}T{hh}:{mm}:{ss}:{msms}

Le paramètre de chemin **"id"** étant l'id de l'offre souhaitée.
Affiche la liste des candidatures au statut **"TRANSMIS BAILLEUR"** pour une offre donnée, et qui est passée à ce statut depuis **"from"**.

## FLux 4 Gestion des statuts d'une offre

### route spécifique bailleurs

    POST     /api/dmo/housing_applications/update_status/

    {
    "data":{
      "attributes":{
                 "unique_number":"0690412654321G3U05",
                 "external_ref":"CVL-000014",
                 "status":"Visite proposée",
                 "last_status_update_date":"01/01/0001",
                 "lessor_event_informations ":"0"
        }
      }
    }

### Explication rapide du concept de "status"

Pour gérer au niveau du moteur le cycle de vie d'un objet, nous employons le concept de **"status"**.
Ceux-ci permettent de discriminer des objets entre eux en fonction de l'état "métier" dans lequel ils se trouvent.

Pour gérer ces statuts il y a deux méthodes accessibles :

- 1. Modifier un champ "status" sur une offre
- 2. Produire un "status" détaillé par la route : **POST api/dmo/statuses**

### Changement de "status" simple

Dans le cas des offres, les champs accessibles pour gérer ces changements non-détaillés de "status" sont les suivants :

- **lessor_status:** status fournit par le bailleur
- **offer_status:** status fournit par SOPRA ou produit par effet de bord
  Changer la valeur d'un de ces champs vers la valeur adéquate, permet au moteur de produire les effets souhaités.

### Changement de "status" détaillé

uri :

     POST api/dmo/statuses

Il s'agit ensuite de fournir un corps de requête adéquat.
Pour le détail fonctionnel des champs présents dans notre swagger [https://als-hermes-scoring-rec.be-idys.com/api/swagger/index.html](https://als-hermes-scoring-rec.be-idys.com/api/swagger/index.html):

- **status_label:** complément de status indiquant à quel concept ce status est associé (ex: _lessor_, _offer_, _request_, _entity_, ...)
- **motive:** description du motif de passage à ce status
- **title:** intitulé du status. IMPORTANT : La validité parfaite de sa valeur est essentielle => ce champs détermine - pour le moteur, l'état métier actuel de l'objet associé.
- **object_id:** id de l'objet associé
- **performer_id:** dans le cas d'une possibilité de "status" concurrents, il est essentiel d'indiquer ici l'id du déclencheur de ce status. _(non utile dans le cas du bailleur)_

### Correspondance des évènements aux status

**NOUS AVONS BESOIN DE FAIRE UN POINT SUR CETTE CORRESPONDANCE.**

| évènement | label de status | valeur PAW |
| --------- | --------------- | ---------- |
|           |

## Flux 5 Mise à jour des bien MAD

Ce flux se déclenche lors d'une mise à disposition d'un bien, ou lors de la modification d'une offre en état MAD.
Son déclenchement implique la mise à jour de l'objet SOPRA associé.

## Flux 6A, 6B, 6C et 39 infos générales

uri globale :

    GET api/dmo/housing_offers/${id}/eligible_request

Avec pour ${id} l’id de l’offre choisie.

Mapping des valeurs :

- Numéro interne demande ALS => **als_id**
- Scoring => **profile_score**
- Rang initial => **eligible_position**
- Rang actuel (estimation ou réél si positionné) => **applicated_position**
- Nombre de candidatures du demandeur => **applications_nb**

### Flux 6A Instruction d'une offre - Onglets candidatures Affichage de la liste des propositions en cours d'instruction

Utilisez le paramètre de recherche « ids » contenant la liste des demandes éligibles à étudier :

    ids[]=${id1}&ids[]=${id2}&ids[]=${id3} …

Pour obtenir les demandes éligibles à une offre portant les ids saisis.

Ou

    ?als_id[$in][]=${id1}& als_id[$in][]=${id2}& als_id[$in][]=${id3} …

Pour Obtenir les demandes éligibles à une offre portant les als_id saisis.

### Flux 6B et 6C infos générales

Trier par scoring, exemple :

    ?sort[profile_score]=(-1 || 1)

Disponible aussi - comme pré-décrit, sur tous les autres champs des demandes.

#### Flux 6B Instruction d'une offre - Affichage de la liste des candidatures et de leurs scoring respectifs

Ajouter le paramètre

    housing_offer_ids=${id}

${id} étant l’id de l’offre en question, pour obtenir toutes les demandes positionnées sur l’offres.

#### Flux 6C Instruction d'une offre - Demandes éligibles Affichage de la liste des demandeurs éligibles (non positionnés sur l'offre) et de leurs scoring respectifs

Ajouter le paramètre

    housing_offer_ids[$ne]=${id}

${id} étant l’id de l’offre en question, pour obtenir toutes les demandes non positionnées sur l’offres.

#### récuperer l'ensemble des candidatures liées a une offre donnée :

la demande liée à la candidature sera dépliée dans la réponses (champs housing_reqquest + main_applicant)

    GET /api/dmo/housing_offers/{id}/all_applications

### Flux 39 Affichage de la demande et de la liste des offres éligibles pour cette demande

Utilisez ensuite les utilitaires de recherche (cf : Utilitaires de recherche) sur les champs souhaités pour filtrer les demandes éligibles selon les critères définis.

## Flux 7 Liste des offres à traiter par les différents rôles (COL, ROL, CDL-C)

    GET api/dmo/housing_offers

Utilisez le paramètre **« ids[] »** ou **« als_id[$in] »** pour rechercher un lot spécifique d’offre.

Mapping des champs :

- Nombre de demande éligibles par orientation => **eligible_requests_nb_detailed**
  - Contient potentiellement (absent ou à 0 si aucune demande correspondante) :
    - **priority_public** (dalo inclut)
    - **single_parent** (monoparentale)
    - **mutation**
    - **entities** (objet de forme) :
      - **id_paw1** : quantité
      - **id_paw2** : quantité
      - ...
- Nombre de candidats positionnés sur l’offre => **applicated_nb**
- Nombre de photos => **pictures_nb**

## Flux 10 gestion des photos

[https://als-hermes-scoring-rec.be-idys.com/api/swagger/index.html#operations-API_DMO_HOUSING_OFFERS-post_api_dmo_housing_offers**housing_offer_id**pictures](https://als-hermes-scoring-rec.be-idys.com/api/swagger/index.html#operations-API_DMO_HOUSING_OFFERS-post_api_dmo_housing_offers__housing_offer_id__pictures)

Les photos sont systématiquement ratachées à une housing_offer.

Le nombre maximal de photos par housing offer est de 5. Au-dela la création est bloquée.
Dans ce cas, il faut alors soit :

- Éditer une photo
- En supprimer une, puis rajouter celle souhaitée

Formatage du json pour une picture :

    {
        "id" :"5dc5975b88cb110b0543a829",
        "type" : "pictures",
        "attributes" : {
    	    "responsible" : {
    		    "id" : "5dc5975a88cb110b0543a822",
    		    "first_name" : "Martin",
    		    "last_name" : "Durand"
    	    },
    	    "readers" : [],
    	    "writers" : [],
    	    "read_level" : "write",
    	    "created_at" : "2019-11-08T17:27:07.560+01:00",
    	    "updated_at" : "2019-11-08T17:27:08.538+01:00",
    	    "thumb240" : “urlDeLaMiniature240pixel.png”,
    	    "thumb1000" : “urlDeLImageEn1000pixelDeLarge.png”,
    	    "full_size" : “urlDeLImageEnTailleOriginale.png”,
    	    "housing_offer_id" : "5dc5975b88cb110b0543a828"
        }
    }

#### image par défaut

lorsqu'aucune image n'est fournie, l'api fournit une image par défault réalisée a partir de google map.
un booléen is_default=true est ajouté au json de l'image en question

    housing_offer => {
    ...
    ...
      "department" => "30",
                                             "pictures" => [
                    [0] {
                                "id" => nil,
                              "type" => "pictures",
                        "attributes" => {
                                  "is_default" => true,
                                    "thumb240" => "https://maps.googleapis.com/maps/api/streetview?size=240x240&location=14+rue+edgard+quinet+30100+&key=AIzaSyB44UtIXYeMCKhtwUWeUdO16KVDMUAHHqQ",
                                   "thumb1000" => "https://maps.googleapis.com/maps/api/streetview?size=1000x1000&location=14+rue+edgard+quinet+30100+&key=AIzaSyB44UtIXYeMCKhtwUWeUdO16KVDMUAHHqQ",
                                   "full_size" => "https://maps.googleapis.com/maps/api/streetview?size=1500x1500&location=14+rue+edgard+quinet+30100+&key=AIzaSyB44UtIXYeMCKhtwUWeUdO16KVDMUAHHqQ",
                            "housing_offer_id" => "5ee8720088cb11fea71b2c57"
                        }
                    }
                ],
                                          "pictures_nb" => 0,
                                  "ordered_picture_ids" => [],
                                         "main_picture" => {
                            "id" => nil,
                          "type" => "pictures",
                    "attributes" => {
                              "is_default" => true,
                                "thumb240" => "https://maps.googleapis.com/maps/api/streetview?size=240x240&location=14+rue+edgard+quinet+30100+&key=AIzaSyB44UtIXYeMCKhtwUWeUdO16KVDMUAHHqQ",
                               "thumb1000" => "https://maps.googleapis.com/maps/api/streetview?size=1000x1000&location=14+rue+edgard+quinet+30100+&key=AIzaSyB44UtIXYeMCKhtwUWeUdO16KVDMUAHHqQ",
                               "full_size" => "https://maps.googleapis.com/maps/api/streetview?size=1500x1500&location=14+rue+edgard+quinet+30100+&key=AIzaSyB44UtIXYeMCKhtwUWeUdO16KVDMUAHHqQ",
                        "housing_offer_id" => "5ee8720088cb11fea71b2c57"
                    }
                },
                                 "publication_end_date" => nil,
                                 ...
                           }

#### Création

    POST /api/dmo/housing_offers/{housing_offer_id}/pictures

avec un file dans les formDatas

renvoie les infos sur la picture créée

#### Recuperation des images liées à une offre

uri :

    GET /api/dmo/housing_offers/{housing_offer_id}

Renvoie 3 champs concernant les pictures

    {
        "ordered_picture_ids": ["id1","id2"] ,
        /*(éditable) liste ordonnée des ids de pictures liées a l’offre
        * (max 5) la première de l’array est la picture principale*/


        "main_picture": {…} 	,
        /*objet contenant les infos de l’image principale
        * première picture de l'array "ordered_pictures"
        * (non éditable directement)*/

        "pictures": [
    	    {…},
    	    {…}
        ]
        /*liste d’objets du type picture
        * (non editable directement)*/
    }

### Edition

    PUT ou PATCH     /api/dmo/housing_offers/{housing_offer_id}/pictures/{picture_id}

avec un champ "file" contenant le fichier image dans dans les formDatas

### Suppression

    DELETE     /api/dmo/housing_offers/{housing_offer_id}/pictures/{picture_id}

### Changement d’ordre dans les pictures

pour changer l’ordre des photos, il faut éditer le champ « ordered_picture_ids » de l’housing offer, la premiere de l’array en deviendra la picture princiaple (main_picture).

    PUT ou PATCH sur /api/dmo/housing_offers/{housing_offer_id}

avec en params :

    "data":{
        "attributes":{
    	    "ordered_picture_ids":[
    		    “picture3.id”,
    		    “picture1.id”,
    		    “picture2.id”
    	    ]
        }
    }

### changement de la main picture

pour changer la main picture il faut réordonner les pictures afin que la picture souhaitée se retrouve au début du tableau « ordered_picture_ids »

## Flux 11 Rendre l'offre au bailleur (entrant)

Modifier la valeur du "offer_status" et "lessor_status" dans la "housing_offer":

    PATCH/PUT sur /api/dmo/housing_offers/{housing_offers_id}

avec en params du body:

        "data":{
    	    "attributes":{
    		   "offer_status": "RENDU AU BAILLEUR",
           "lessor_status": "RENDU AU BAILLEUR CONFIRME"
    	    }
        }

## Flux 12 Reprise offre par le bailleur (sortant sopra)

Transmission au back sopra via un appel de WS du status d'une offre donnée (housing_offer) lorsque celle ci à son status qui passe à reprise par le bailleur ('RBA')

## Flux 13 Confirmer la reprise de l'offre par le bailleur

https://code.plugandwork.net/plugandwork.app/hermes/commit/cbe458dd5376cd92d934fbb07319c9225e011f9a
c'est une édition d'une entité offre, elle s'appele sur la route :

    PATCH/PUT sur /api/dmo/housing_offers/{housing_offer_id}

avec en params du body:

        "data":{
    	    "attributes":{
    		   "lessor_status" : "RETIRE" ,
    		    "offer_status" : "RETIRE PAR LE BAILLEUR"
    	    }
        }

ou

        "data":{
          "attributes":{
            "lessor_status" : "RETIRE" ,
            "offer_status" : "RETIRE PAR ALS"
          }
        }

## Flux 14 Gérer l'orientation d'une offre

L'orientation d'une offre est composée par les champs suivants :

- **priority_public**: Boléen statuant sur l'accessibilité à l'offre par les publiques prioritaires uniquement
- **mutation**: Boléen statuant sur l'accessibilité à l'offre par les demandes en situation de mutation uniquement
- **single_parent**: Boléen statuant sur l'accessibilité à l'offre par les familles monoparentales uniquement
- **reserved**: Boléen statuant sur l'accessibilité à l'offre par les demandeurs des entreprises liées à l'offre
- **entity_ids**: Liste des ids des entreprises liées à l'offre

Pour modifier l'orientation d'une offre il s'agit donc de mettre à jour les champs indiqués plus haut au niveau de l'offre souhaitée.

## Flux 15 Gérer la publication d'un offre

L'offre doit passer au statut : "LOGEMENT PUBLIE".
Pour ce faire :

    PATCH /api/dmo/housing_offers/{id}

body :

    {
      "data":{
        "attributes":{
          "details": "string", // description du bien
          "dpe_ges": "string", // étiquette GES
          "dpe_conso": "string" // étiquet DPE
        }
      }
    }

## Flux 16 Commercialiser l'offre sans publication

c'est une édition d'une entité offre, elle s'appele sur la route :

    PATCH/PUT sur /api/dmo/housing_offers/{housing_offer_id}

avec en params du body:

        {
          "data":{
            "attributes":{
                    "offer_status": "COMMERCIALISE SANS PUBLICATION",
                    "lessor_status": "PUBLIE",
                    "publication_end_date": Date
            }
          }
        }

## Flux 17 Commercialiser une offre avec publication

c'est une édition d'une entité offre, elle s'appele sur la route :

    PATCH/PUT sur /api/dmo/housing_offers/{housing_offer_id}

avec en params du body:

        "data":{
    	    "attributes":{
    	            "offer_status": "LOGEMENT PUBLIE",
                    "lessor_status": "PUBLIE",
                    "publication_end_date": Date
    	    }
        }

- les offres avec le champ is_public à true sont des offres qui resortirons pour les candidats quelque soit les critères d'eligibilité
- les offres avec le status offer_status=='LOGEMENT PUBLIE' seront visible en mode visiteur

## Flux 18 Dépublier une offre

c'est une édition d'une entité offre, elle s'appele sur la route :

    PATCH/PUT sur /api/dmo/housing_offers/{housing_offer_id}

avec en params du body:

        "data":{
    	    "attributes":{
    		   offer_status : "EN COURS DE DESIGNATION"
    		    lessor_status : "EN DESIGNATION"
    	    }
        }

## Flux 19 Suite à l'action 'Transmettre au bailleur", envoi des candidats choisis pour une offre donnée

### Transmission au front als des demandes retenues

    POST sur /api/dmo/housing_offers/{housing_offer_id}/selected_applications

avec en params du body:

    "data":{
        "attributes":{
    	   "housing_application_ids":[
    		    “id1”,
    		    “id2”,
    		    “id3”,
    		    ...
    	    ]
        }
    }

Entraine une modification du statut de la candidature à "TRANSMIS BAILLEUR" et renvoie la liste des candidatures ainsi éditées avec en embed les demandes associées
Les autres candidatures active sur cette offre seront passer à "NON RETENUE".
En cas d'erreur ou la candididature fournie dans la liste `housing_application_ids` n'est pas trouvé, pas active ou pas sur l'offre donnée, on retroune une erreur 422 :
  
  
        [
            {id: id1, message: 'not active, status : ANNULEE'},
            {id: id2, message: 'not found on this housing_offer'},
            {id: id1, message: 'not found'},
        ]


### recupération des candidatures enregistrées sur le front avec un status à TRANSMIS BAILLEUR pour une offre donnée

pour une offre donnée, récupération des candidature dont le statut est à « TRANSMIS BAILLEUR » avec pour chacune la housing_request associée en embed dans le json

    GET api/dmo/housing_offers/${id}/selected_applications

Avec pour ${id} l’id de l’offre choisie.

il est possible d’ajouter des options de recherche et une pagination à cette requete comme pour les autres requêtes ; documentation accesible sur notre [swagger](https://als-hermes-scoring-rec.be-idys.com/api/swagger).

## Flux 20 Annuler la commercialisation d’une offre

c'est une édition d'une entité offre, elle s'appele sur la route :

    PATCH/PUT sur /api/dmo/housing_offers/{housing_offer_id}

avec en params du body:

        "data":{
    	    "attributes":{
    		   "offer_status" : "EN ATTENTE COMMERCIALISATION",
    		   "lessor_status" : "EN ATTENTE PUBLICATION"
    	    }
        }

## Flux 21 Envoi d'une candidature au back sopra (sortant sopra)

Ce flux se déclenche lors de la création d'une candidature pour une offre ( au create d'une
housing_application ). Il envoie une requête vers Sopra indiquant l'offre concerné et la demande concernée ainsi que la date de positionnement.

## Flux 30 Envoi d'une demande (sortant sopra)

ce flux se déclanche a la création ou a l'update d'une housing_request et permet de renseigner le back sopra sur les modifications d'une demande de logement.

## Flux 32 Envoit d'un NUD au FRONT

Pour créer un Nud :

uri:

    POST /api/dmo/nuds

body :

    {
      "data": {
        "attributes": {
          "housing_request_id": ,// String, id PAW de la demande concernée (utilisez aussi l'als_id si vous preferez)
          "als_id":             ,// String, als_id de la demande concernée (connue sous le nom de ref_interne chez sopre
          "department":         ,// String, code du département rattaché au nud
          "creation_date":      ,// DateTime, date de création rattaché au nud
          "unique_number":      ,// String, numéro unique du nud
          "is_active":           // Boolean, true si toujours d'actualité, false pour désactiver la validité
        }
      }
    }

Cette méthode API gère aussi les doublons :
Si la paire **"unique_number"** <==> **"housing_request_id"**, est déjà réferencée, alors l'objet portant cette correspondance sera récupéré et mit à jour.

Vous pouvez vous référer au [swagger](https://als-hermes-scoring-rec.be-idys.com/api/swagger/index.html) pour connaitre le reste de ses fonctionnalités classiques.

## Flux 36 Validation d'une demande par une entreprise (sortant sopra)

ce flux se déclenche quand entity_validated est modifié

## Flux 37 Dès détection d'une modification de l'orientation sur une demande suite au traitement automatique de détermination

    GET api/dmo/housing_requests/clp_details?als_ids[]=${id1}&als_ids[]=${id2}…

Le paramètre **_« als_ids »_** est ici obligatoire. C’est l’équivalent du paramètre **_« ids »_** mais pour la correspondance avec le champ « als_id » porté par une demande.

Ce paramètre n’existe que pour cette action !!! Autrement il faut utiliser **« als_id[$in] »** pour reproduire son effet.

Mapping des champs :

- Nombre de candidatures => **applicantions_nb** Date dernière
- candidature => **last_application_date** Nombres d’offres éligibles
- détaillé => **eligible_offers_nb_detailed** Objet qui contient les
- clefs : Nombre non commercialisées => **non_commercialized** Nombre
  - commercialisées et non publiées => **commercialized_non_pubicated**
    - Nombre commercialisées et publiées => **commercialized_publicated**

## Flux 38 Gérer l'orientation d'une demande

### rappel généraux

Dans notre solution une demande est un objet composite formé :

- d'un demandeur principal **Applicant**
- d'une demande de logement **HousingRequest**
- d'aucun à plusieurs co-titulaire **Applciant**

Les informations présentes sur chacun de ces objet produit l'orientation d'une demande.

Champs concernés pour :

- Le demandeur principal et les co-titulaire :

  - **entity_id**: entreprise du demandeur principal ou du co-titulaire

- La demande de logement :
  - **entity_validated**: validation entreprise (pour l'instant ne prend en compte que la validation de l'entreprise du demandeur principal)
  - **single_parent** (automatique): Boléen calculé en fonction de la composition familiale de la demande et statuant sur l'état "monoparental" ou non du foyer de la demande
  - **mutation**: Boléen statuant sur l'état "mutation" de la demande
  - **priority_public**: Boléean statuant sur l'état "publique prioritaire" de la demande

Pour modifier l'orientation d'une demande il s'agit donc de mettre à jour les champs indiqués plus haut au niveau de la demande souhaitée, excepté pour **single_parent** qui est produit par plusieurs composantes :

- situation familiale du demandeur principale
- si le foyer inclut ou non des enfants à charge

### application au flux 38

    PATCH/PUT sur /api/dmo/housing_requests/{housing_request_id}

avec en params du body:

        "data":{
    	    "attributes":{
    		   "priority_public" : Boolean
    	    }

## Flux 40 Notification du changement de statut d'une candidature (entrant)

Modifier la valeur du "status" dans la "housing_application":

    PATCH/PUT sur /api/dmo/housing_applications/{housing_application_id}

avec en params du body:

        "data":{
    	    "attributes":{
    		   "status": "A L'ETUDE ALS"
    	    }
        }

## Flux 50 à 56 Communication d'évènements candidature (sortant sopra)

Ce flux se déclenche lors de la modification du statut d'une candidature (champ "status" d'une housing_application).  
Il envoie une requête indiquant l'évènement vers Sopra avec un code évènement tel que décrit ci dessous.

### Statuts des candidatures

Cette liste peut être amenée à évoluer car certaines corrrespondances avec les précédents statuts ne sont pas encore bien établies.

A présent il est indispensable de séparer les statuts de commissions des statuts de visite, il existe donc deux champs sur le modèle HousingApplication qui sont `status` et `visit_status`

Actuellement la correspondance avec le code évènement fonctionne avec les anciens et les nouveaux statuts.   
Si un ancien statut est utilisé alors il sera converti suivant ce tableau.  
Le code évènement sera renvoyé avec les anciens et nouveaux statuts (si correspondance)

| status                        | visit_status             | Ancienne correspondance    | Code évènement renvoyé |
| ----------------------------- | ------------------------ | -------------------------- | ---------------------- |
| EN ATTENTE                    |                          | Waiting                    |                        |
| PLO                           |                          | PLO                        |                        |
| TRANSMIS BAILLEUR             |                          | Inscription CAL            | INSCAL                 |
| RETENUE EN CAL               |                          | Attribution lot avec rang  | DESCAL                 |
| REFUSEE EN CAL                |                          | Refus attribution          | DESCAL03               |
| NON RETENUE                   |                          | Refus lot demandeur        | REFLOG                 |
| NON RETENUE EN CAL            |                          | Radiation attribution      | RADATT                 |
| DESISTEMENT SALARIE AVANT CAL |                          |                            |                        |
| ANNULEE BAILLEUR              |                          |                            |                        |
| DESISTEMENT                   |                          |                            |                        |
| ANNULEE                       |                          |                            |                        |
| A L’ETUDE ALS                 |                          |                            |                        |
| DESISTEMENT APRES CAL         |                          |                            |                        |
| **RETENUE EN CAL**           | VISITE PROPOSEE          | Visite proposée            | VISPRO                 |
| **RETENUE EN CAL**           | VISITE EFFECTUEE         | Visite effectuée           | VISEFF                 |
|                               | DESISTEMENT APRES VISITE |                            |                        |
|                               | ACCORD APRES VISITE      |                            |                        |
| **RETENUE EN CAL**           |                          | Attribution lot            | DESCAL01               |
| **RETENUE EN CAL**           |                          | Attribution sous condition | DESCAL02               |

### dates et rang dans les flux 50-56

les champs du xml sont remplits avec les information de la candidature si elles sont présentes :
|champ du XML| correspondance champ hermes| modifiable via flux 4 sur "/api/dmo/housing_applications/update_status/"| note|
|---|---|---|---|
|rang_decision|housing_application.rank|oui|optionnel, pas de valeur par défault|
|date_survenance_evenement|housing_application.date_event|oui|optionnel, pas de valeur par défault|
|date_creation_evenement|housing_application.last_status_update_date|oui|obligatoire, date du jour si non précisé|

### Déclanchement des effets de bords

A la suite de certaines modifications sur les statuts d'une HousingApplication, cela peut déclencher une série d'évènements.

| status                         | visit_status     | Effet                | Impact      |
| ------------------------------ | ---------------- | -------------------- | ----------- |
| si inclut le mot 'DESISTEMENT' | VISITE EFFECTUEE | Re-calcul du scoring | - 35 points |
| RETENUE EN CAL                | NA               | Re-calcul du scoring | + 35 points |

### Affichage de l'historique des statuts pour un candidat

Un candidat peut afficher la liste des statuts de ses candidatures via la requête suivante :

    GET /api/dmo/statuses/applications_history

La notion d'historisation est liée au filtrage par 2 paramètres disponibles, `start_date` et `end_date`, que l'on peut ajouter à la requête soit l'un ou l'autre, soit les deux :

    GET /api/dmo/statuses/applications_history?start_date=01/01/2020&end_date=31/12/2020

Le requête est alors filtrée sur les statuts dont la date de mise à jour (`updated_at`) est comprise entre les bornes datées.

      POST /api/dmo/lessor_contacts
      data:{
        attributes:{
          name: 'name', # requis
          email: 'email', # non requis
          phone: 'phone', # non requis
          lessor_id: 'id' #requis si non superadmin
        }
      }

Les comptes superadministateur peuvent créer toutes les operations/secteurs/contacts (avec/sans lessor_id)
Les autres comptes doivent avoir des droits d'accés au bailleur pour pouvoir ajouter des operation/secteur/contact liés

Pour récupérer la liste des operations/secteurs/contacts :

      GET /api/dmo/operations
      GET /api/dmo/management_areas
      GET /api/dmo/lessor_contacts

Retourne toutes les opérations/secteurs sans lessor_id + ceux avec un lessor_id dont l'utilisateur a les droits d'accés.
Possiblité de filtrer par lessor_id en ajoutant &lessor_id=id
