

### Simplifications du modele de données et de l''api lié a l'abandon de la gestion avancée des Pieces justificatives

#### supression des routes :

        send_files

        delete_files

        start_treatment

        gedfile

#### suppression des comportements

        suppression de la notion de fichiers liés a un required document
        abolition du lien vers la ged
        abolition des liens vers le sne
        suppression du kyc

#### supression champs

    required_document
        :metas,
        :tagset_id,
        :tagsetLocation,
        :files,
        :last_xml_validation_report,
        :last_send_has_error,
        :validity_limit,
        :is_still_valid,
        :validation_errors,
        :kyc_needed,

    housing_request_folder
        :file_upload_from_sne_complete
        :validity_limit



### 10475 En tant que demandeur je souhaite savoir si je suis radié afin de connaitre la procédure à suivre

lorsque une demande est radiée, on ajoute plusieurs elements au niveau de la housing_request :
            
            is_striked_off : booleen ,
            striked_off_motives : {
                motive_code: "string",
                sub_motive_code: "string",
                striked_off_date: date
            }

### 10205 En tant que demandeur n'ayant pas de NUD, je saisis mon département de recherche afin d'être redirigé vers mon site d'enregistrement
la liste et le paramettrage des nuds providers se fera a partir d'une interface d'admin de la plateforme.
pour les récuperer au detail :

	    GET /api/dmo/nud_providers/{numéro du departement ou id du nud_provider}
		retour

        "data": {
            "attributes": {
                        "id": "1111111",
						"name" : "SNE" ,
						"department_codes": ["01", "02", "03", "04", "05"],
						"url" : "https://www.demande-logement-social.gouv.fr/index"
					},
					
            }
        }

si rien n'est trouvé, nous renvoierons une erreur 404 avec le message : 

    "Aucun département trouvé pour le code [numéro envoyé]".

#### liste/ajout/modifications/supression des nuds providers
à moyen terme il y aura une interface admin pour gérer cela, mais dans un premier temps
l'objet nud_provider dispose d'une api permettant le listing
-le listing 
    
    GET /api/dmo/nud_providers

l'ajout

    POST /api/dmo/nud_providers
    avec en body :
     "data": {
            "attributes": {
						"name" : "SNE" ,
						"department_codes": ["01", "02", "03", "04", "05"],
						"url" : "https://www.demande-logement-social.gouv.fr/index"
					},
					
            }
        }

l'édition : 

    PUT/PATCH /api/dmo/nud_providers/{:id}
    avec en body :
     "data": {
            "attributes": {
						"name" : "SNE" ,
						"department_codes": ["01", "02", "03", "04", "05"],
						"url" : "https://www.demande-logement-social.gouv.fr/index"
					},
					
            }
        }
la supression :

    DELETE /api/dmo/nud_providers/{:id}
   
### 10588 En tant que demandeur ayant rentré mon NUD, je dois saisir mon code d'accès pour confirmer la création de ma demande
lorsque un probleme survient au moment de la verification du code d'accès, l'api renvoie une 422 avec comme message d'erreur:
- "pin_code_missing" (absence de code pin)
- "wrong_pin_code" (erreur dans le code pin)

### 10555 En tant que demandeur, je souhaite voir dans ma demande quels sont les champs obligatoires manquants afin de les remplir sur mon site d'enregistrement
le back se chargera d'effectuer une routine de validation des champs
la routine back viendra rajouter un champ a l'objet housing_request listant les erreurs de validations :
		"housing_request" : {
			... ,
			"form_sne_validation_errors": [
				{
				"field" : "amount_year_minus_two",
				"error" : "Revenu Fiscal de référence 2019 sur avis d'imposition 2020 manquant"
				},
				{},
				...
			],
            "form_front_validation_errors" : [
				{
				"field" : "amount_year_minus_two",
				"error" : "Revenu Fiscal de référence 2019 sur avis d'imposition 2020 manquant"
				},
				{},
				...
			],
			...
			}

le front pourra ainsi verifier la conformité du formulaire en testant la longueur du tableau, et proposer un affichage des erreurs a l'utilisateur au besoin.
### 11550 11561 En tant que demandeur salarié, je souhaite choisir si je rattache ma demande à l'entreprise de demandeur principal ou du co demandeur
voir avec @gaetan

### 10184 En tant que demandeur, je dois cocher les PJ à fournir sur mon site d'enregistrement afin de finaliser ma demande
on garde les routes existantes, pas de changement :

    POST /api/dmo/housing_requests/:id/housing_request_folder/change_confirmed
        {
            required_documents:{
                Id_1 : false,
                Id_2 : true,
                Id_3 : true
            }
        }
        ou 
        {
            required_documents:{
                all: true|false
            }
        }

les pièces ont un champs "category" qui pourra peut etre aider a réaliser le tri et la classification des pieces par type comme on le voit dans la maquette :
nous n'avons plus les specifications avec lesquelles cela avait été créé mais en "rétro-ingénieurant" on obtient :
| required_document.category | Catégorie |
|--|--|
| HANDI |  pièces relatives au handicap|
| PC | pièces personnes à charge |
| SPI | justificatifs d'identité |
| MD | pieèces relatives aux motifs de la demande |
| SPL |  justificatifs de logement (loacataire)|
| SPR | justificatifs de ressources |
| SF | situation familliale |
| RFR | revenus fiscaux |
| SF | situation familliale |

### 10555 Controle des champs de la de la demande coté back

un champs "housing_request.form_validation_errors" de type tableau est ajouté.lorsque des verifications sont non valides, alors les erreurs sont ajoutées a ce tableau.
le retour des housing_requests est alors ainsi :
    
        {"data":
            {"attributes":
                { 
                    ...,
                    ...,
                    "form_validation_errors":[
                        {
                            "category" : "Situation personnelle",   //catégorie du tableau csv, pour l'affichage front
                            "sub_category" : "Demandeur",           //!! optionel, peut etre null !! sous-catégorie du tableau csv, pour l'affichage front
                            "alin_field" : "Mail personnel",        // champ AL'in du tableau csv, pour l'affichage front
                            "csv_rule_line" : "8"                   //permet de savoir la ligne du csv des conditions de validations incorrecte afin de faciliter les eventuels correctifs/debuggage
                            "hermes_field" : "applicant.email",     //nom du champs hermes, permet aussi de faciliter le débuggage
                            "rule" : "presence",                    //regle qui s'applique, idem
                            "verification_condition" : "none"       //situation dans laquelle le controle est sencé s'appliquer a des fins de débuggage
                            "csv_rules_version" : "01"              //version du fichier de regles de verifications utilisée (a des fins de débuggage aussi)
                        },
                        {
                            "category" : "Motifs et logement recherché",  
                            "sub_category" : null, 
                            "alin_field" : "Acceptez-vous que votre demande soit élargie aux autres communes de l'agglomération ? (communauté urbaine ou d'agglomération ou de communes) * :",
                            "csv_rule_line" : "40",
                            ...
                            ...
                        },
                        {
                            ...
                        }
                    ],
                    ...,
                    ...
                }
            }
        }

dans le cas d'une demande valide, on aura donc : 

   
        {"data":
            {"attributes":
                {
                     ...,
                    "form_validation_errors":[],
                    ...
                }
            }
        }