
# Doc Offres logement

## 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 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 intial =>  **profile_epci_score** 
 - Scoring actuel (si positionné) => **score_with_position** 
 - Rang initial => **eligible_position** 
 - Rang actuel (estimation ou réél si positionné) => **applicated_position**
 - Taux d’effort => **effort_rate**
 - 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_epci_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"
	    }
    }

#### 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" dans la "housing_offer": 

    PATCH/PUT sur /api/dmo/housing_offers/{housing_offers_id}
    
avec en params du body: 
    
        "data":{
    	    "attributes":{
    		   "offer_status": "RETIRE PAR LE BAILLEUR" 
    	    }
        }

## 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"
    	    }
        }


## 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":{
		   "als_request_ids":[
			    “als_request_id1”, //id de demande tels que présent dans le back
			    “als_request_id2”,
			    “als_request_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

### 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 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" 
    	    }
        }



## Affichage des offres de logements publiques

Le front-end peut lancer des requêtes afin de récupérer l'ensemble des offres de logements publiques (housing_offer avec le champ "is_public" à true)

Il n'est pas nécessaire d'être identifié pour y avoir accès (pas besoin de token).

    GET /api/dmo/public_housing_offers

Les paramètres de tri et de pagination possibles sont décris dans le swagger : 

[https://als-hermes-scoring-rec.be-idys.com/api/swagger/index.html#operations-tag-API_DMO_PUBLIC_HOUSING_OFFERS](https://als-hermes-scoring-rec.be-idys.com/api/swagger/index.html#operations-tag-API_DMO_PUBLIC_HOUSING_OFFERS)

Une expliquation plus détaillée de l'utilisation des query params pour préciser la recherche se trouve au premier chapitre de cette documentation.

Il est aussi possible de réaliser une requête pour récupérer le détail d'une seule housing_offer dont le champ is_public est à true sans être identifié (pas besoin de token) :

    GET /api/dmo/public_housing_offers/{id}




**Attention, après sa création, le code est valable pendant 15 jours**




## Bailleur

### housing_offer

Création d'une nouvelle offre

    POST /api/dmo/housing_offers

Mise à jour d'une offre

    PUT /api/dmo/housing_offers/{housing_offer_id}

Champs interdits pour le role `'bailleur'`

    :als_siren
    :dalo
    :status
    :status_updated_at

### housing_request

Retrouver toute les housing_requests relative au current_user (si celui-ci à le role `'bailleur'`)

    GET /api/dmo/housing_requests?available=true

### Gestion de la requalification

Un bailleur peut reserver un logement qu'il a integré à la plate forme pour requalification, la requalification consiste à rapprocher une demande du SNE avec le logement existant dans Hermes.
Pour cela, le bailleur doit saisir les champs suivants lors de la création/mise à jour de son offre :

    {
        "offer_status": 'REQUALIFICATION'
    }

Grace à ce status, l'offre passera en `requalification: true`, il sera alors possible de la récupérer en utilisant le filtre de recherche adéquat.

Ensuite, il pourra directement lier l'offre à un candidat donné. Pour cela le bailleur doit fournir l'id de l'offre en question ansi que l'id du candidat. Si celui-ci n'est pas connu ou qu'il n'existe pas encore sur la plateforme, alors le bailleur peut utilisé le NUD ainsi que la date de naissance du candidat en question. Cette dernière sera utilisé à des fins de vérification.

**Utilisation avec applicant_id** [se reporter au swagger si besoin](/api/swagger/index.html)

    POST /api/dmo/housing_applications/attribution
    {
        "data": {
            "attributes": {
                "housing_offer_id": "5dc30a5ba70bf23b53a26475",
                "applicant_id": "5dc3c9bfa70bf25732aaa55b"
            }
        }
    }

**Utilisation avec NUD** [se reporter au swagger si besoin](/api/swagger/index.html)

Attention la date de naissance doit être sour le format `'YYYY-MM-DD'`

    POST /api/dmo/housing_applications/attribution
    {
        "data": {
            "attributes": {
                "housing_offer_id": "5dc30a5ba70bf23b53a26475",
                "nud": "123456789012345678",
                "birth_date": "1992-06-24"
            }
        }
    }

|status|raison|
|---|---|
|201|Attrribué avec succès|
|404|NUD inconnu|
|422|date de naissance invalide|






## Filtrer les offres publiques par dates

    GET api/dmo/public_housing_offers

Ajouter les paramètres 

    date_publication_start[$gte]=${date limite inférieure} // au format YYYY-MM-DD
    publication_end_date[$lte]=${date limite supérieure} // au format YYYY-MM-DD

La requête va retourner toutes les offres publiques dont les dates de publication sont comprises entre les 2 paramètres.

## Récupération de l'historique des décomptes bailleurs par n° d'offre

    GET api/dmo/housing_offers/{id de l'offre}/history

La requête va retourner le tableau d'historique des décomptes bailleurs pour une offre, si l'utilisateur est le reservataire ou le bailleur de cette offre.

Le champ `created_at` est le timestamp du moment où un objectif a été réalisé.  
Les `target_by_typologies` et `realized_by_typologies` sont les copies des "attendus" et "réalisés" à ce moment.

```
  [  
    {
      "id": "5e4fdc8b3604e9cfbf4d055e",
      "type": "lessor_objective_history",
      "attributes": {
        ...
        "created_at": "2020-02-21T14:35:07.613+01:00",
        "lessor_objective_id": "5dc3c9bfa70bf25732aaa55b",
        "lessor_id": "5dc2d6b6a70bf24cc5b33594",
        "housing_offer_id": "5dc30a5ba70bf23b53a26475",
        "target_by_typologies": {
          "T3": 25,
        },
        "realized_by_typologies": {
          "T3": 3,
        }
      }
    }
  ]
```


## Récupération du score détaillé par n° d'offre pour un demandeur donné


Si l'utilisateur est demandeur sur l'offre, la requête va retourner son score détaillé.

    GET api/dmo/housing_offers/{id de l'offre}/detailed_score

Si l'utilisateur est au moins lecteur de l'offre, le paramètre `applicant_id` est **obligatoire**. La requête ne retourne le score pour ce demandeur que si l'utilisateur est également au moins lecteur du demandeur.

    GET api/dmo/housing_offers/{id de l'offre}/detailed_score?applicant_id={id de l'applicant}




## Renseigner la date de visite pour une candidature

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

avec en body de la requête : 

    {
      "data": {
        "attributes": {
          "visit_conducted_date": 'DD/MM/YYYY' // date de la visite
        }
      }
    }


## Fonctionnement de la création/update/auto_delete des offres 

Lorsqu'on crée un offre, un recherche est effectuée sur le champs lessor_id et external_ref.
Si une offre correspondante existe, elle est mise a jour avec les infos transmises lors de l'update.

A chaque modifications de l'offre via l'api, si l'offre a le champs housing_offer.auto_destroy_next_day à true, un compte à rebour de 36h se déclenche.
A l'issue de ce compte à rebours, si aucune requête de création ou d'update n'a été faite sur l'offre par le bailleur, le offer_status passe à "RETIRE PAR LE BAILLEUR"
et les actions suivantes sont exécutées :

 - envoi du flux 12 pour informer sopra de la reprise par le bailleur (status "RBA").
 - à spécifier
 - à spécifier






## Trier les offres par codes postaux souhaités en premiers

    GET api/dmo/housing_offers

Ajouter en paramètre un array de codes postaux dans l'ordre souhaité

    postal_codes[]={code postal souhaité 1} (e.g. 75100)
    postal_codes[]={code postal souhaité 2} (e.g. 34200)

La requête va retourner en premier les offres dont les codes postaux sont "75100" puis les offres dont les codes postaux sont "34200" puis toutes les autres offres.

**Pour afficher le positionnement d'un candidat par rapport à sa localisation**


Si l'utilisateur courant est demandeur sur l'offre :

    GET api/dmo/housing_offers/{id de l'offre}/score_position

Si l'utilisateur courant n'est pas demandeur :

  Pour avoir le score d'un applicant, vous pouvez ajouter le paramètre `applicant_id` :

    GET api/dmo/housing_offers/{id de l'offre}/score_position?applicant_id={id de l'applicant}

  Si le score est trouvé, la requête retourne alors le positionnement de l'utilisateur courant (s'il est demandeur) ou du candidat renseigné via l'`applicant_id` : 

    {
      "position_by_department": 4,
      "total_by_department": 10,
      "position_by_postal_code": 4,
      "total_by_postal_code": 10
    }

  Sans le paramètre `applicant_id` vous recevrez juste les totaux :
  
    {
      "total_by_department": 10,
      "total_by_postal_code": 10
    }

Avec "total_by_department/postal_code", le nombre de scores de l'offre pour le departement/code postal du candidat.  
Et "position_by_department/postal_code", la position sur l'offre pour le departement/code postal du candidat.



## Trier les offres par localisation

    GET api/dmo/housing_offers?longitude=44.55127&latitude=4.75386&distance=130

|fields|type|default|
|---|---|---|
|:longitude|:float|`null`|
|:latitude|:float|`null`|
|:distance|:integer|`20`|
|:unit|`km | meter`|`km`|

Le filtre sur la localisation étant apliqué en dernier, les conditions de récupération des offres reste exactement les mêmes.

Si les paramètres `:longitude` et `:latitude` sont fournis, alors le filtre sur la localisation sera appliqué.


## Règles de dépublication d'une offre

### Pour administrateurs uniquement en CRUD complet

Exemple de création d'un nouveau réglage de dépublication : 

    POST api/dmo/housing_offer_expiration_settings

Avec en body 

    {
      "data": {
        "attributes": {
          "department": '34',
          "max_applicants": 10,          // seuil de candidatures max
          "minimal_publication_days": 3, // durée de vie minimale de l'offre en jour
          "expiry_days": 7,              // nombre de jours avant dépublication
          "lessor_id": {id du bailleur} 
        }
      }
    }

### Automatisation de la dépublication

Une offre **publiée**, créée ou éditée, récupère automatiquement le `max_applicants` et le `minimal_publication_days` (par défaut 3) du réglage correspondant à son département et lessor_id.

La date de dépublication (`publication_end_date`) est alors automatiquement calculée et enregistrée à `date_start_publication + expiry_days` (par défaut 7).

Lorsqu'une offre dépasse son seuil de candidatures **et** sa durée minimale de vie, elle est automatiquement dépubliée (offer_status: 'COMMERCIALISATION NON PUBLIEE')

### Remarques

Si le `max_applicants` n'est pas renseigné, l'offre n'a pas de seuil de candidatures.

Si un `expiry_days` est set à la création ou à l'édition d'une offre, il prend le pas sur celui du réglage (`housing_offer_expiration_setting`)  
- Exemple : si j'enregistre une offre avec `expiry_days = 20` et qu'il existe un réglage avec `expiry_days = 11`, ma date de dépublication sera de `publication_start_date + 20`

Si une date de dépublication (`publication_end_date`) est set à la création ou à l'édition d'une offre, c'est elle qui sera prise en compte quelque soit le réglage et/ou le `expiry_days` existant(s).







## Vérification si une référence existe

    GET /api/dmo/housing_offers/reference_exist?external_ref=reference

## Besoin front sprint 25

5411 -a Pour qu'on puisse récupérer les candidatures d'une offre il faut soit ajouter les ID de candidatures actives sur une offre, soit permettre de requêter des objets candidature par housing_offer_id + status "EN ATTENTE ou "TRANSMIS BAILLEUR" ou "ACCEPTEE EN CAL"
pour récuperer les candidatures souhaités :

    GET /api/dmo/housing_applications&housing_offer_id=<id>&status[$in][]="ACCEPTEE EN CAL"&status[$in][]="TRANSMIS BAILLEUR"&... etc

5411 -b Il nous manque sur l'objet candidature les infos suivantes :
        - l'ID de l'offre chez le bailleur (external_ref de l'offre)
        - nom et prénom du candidat (main_applicant de la demande)
        - nur/nud (nud de la demande)
        - numéro de la demande (als_id de la demande)
        
du coup au niveau de la vue json j'ai rajouté ces champs : 

      housing_application: {
          ...
          "unique_numbers" => [
          [0] "AL056473357466383880"
          ],
          "offer_external_ref" => "EXTERNALREF01",
          "main_applicant_first_name" : "martin",
          "main_applicant_last_name" : "Matin",
          "request_als_id" : "0000000002",
          "rank" : 2,
          ...
      }

Pour trier via score, il faut utiliser le paramètre `offer_id`

GET /api/dmo/housing_applications?offer_id={housing_offer_id}&sort[applicated_position]=1

