# Chantier territoire v2

## Problématiques & objectifs

1. Actuellement, la gestion des territoires permet difficlement de synchroniser les données avec les producteurs (insee, cerema, etc.). Ce qui rend la mise à jour des informations compliquée à automatiser ;
2. La création de territoires "personnalisés" rend l'ensemble de l'arbre des territoires fragiles avec l'introduction d'erreur (territoire récursif par ex.) et de données incomplète (pas de territoire parent) ;
3. Actuellement, nous ne gérons pas l'historisation des territoires. Le rapport bénéfice cout avait été jugé insuffisant. Dans l'idéal la refonte doit permettre de suivre les changements de territoire (exemple : une ville change de département, fusionne, etc.).

Il nous faut donc conduire un changement répondant à ces objectifs :
- permettre la synchronisation facilement
- permettre la création/modification de territoire en anticipation des producteurs de données
- permettre la création/modification de territoire personnalisés ne faisant pas partie d'un référentiel géographique (territoire utilisateur exclusivement donc.)
- permettre de suivre les évolutions d'un territoire

## Impacts
### Commun
Synthèse:
* Incertitude : moyen
* Complexité : moyen
* Volume : faible

Description:
* Système de permissions (authorized territories)
* Système de visibilité (authorized operators) > à voir avec l'atelier opérateur

### Service Normalisation
Synthèse:
- Incertitude : faible
- Complexité : faible
- Volume : faible

Description:
- Réécrire TerritoryProvider
- MAJ des tests

### Service Policy
Synthèse :
- Incertitude : faible
- Complexité : moyen
- Volume : moyen

Description:
- Réécrire TerritoryProvider
- Réécrire la règle "TerritoryFilter" & "InseeFilter" + migration des campagnes existantes + impact sur le front (?)
- Réécrire la vue "policy.trip" ou changer le paradygme pour "tirer" les trajets
- MAJ des tests

### Service Territory
Synthèse:
- Incertitude : moyen
- Complexité : moyen
- Volume : important

Description:
- Découper les données en deux tables (géo, usergroup)
- Réecrire le provider territory
- Redéfinir les besoins frontend
- Réécrire les actions
- MAJ des tests

### Service Trip
Synthèse:
- Incertitude : moyen
- Complexité : moyen
- Volume : moyen

Description:
- Réécrire ScopeToGroupMiddleware
- Réécrire le selecteur dans TripRepositoryProvider
- Réécrire la vue trip.list_view
- MAJ des tests

### Frontend:
- Filtre XXX SelectBox ;
- Manipulation des groupes d'utilisateur (création, modification, liste, détail et ajout/suppression d'utilisateur) ;
- Manipulation des mailles géo EN ANTICIPATION des producteurs de données (création, modification, liste, détail) ;

## Sous chantiers
### Database design
Actuellement, les territoires sont sur 3 tables :
- territory.territories contenant les données geo, population, surface, nom et les données liés au "compte" (adresse, contacts, etc)
- territory.territory_codes contenant les codes rattachés au territoires (code postal, code insee, ...)
- territory.territory_relation contenant les relations du territoires

A ces 3 tables s'ajoutent plusieurs fonctions :
- territory.get_descendants
- territory.get_ancestors
- territory.get_relation
- territory.get_breadcrumb
- territory.get_code
- territory.get_data

L'idée est d'aplatir la table pour regrouper les données géographique au sens large dans une seule table et donc d'avoir :
- une table geo avec nom, population, surface, contour, code postal, code insee, code département, code région, code epci, etc. par année
- une table group avec les informations liées au groupe utilisateur
- une table avec les relations avec les codes géos type&valeur

Exemple :
| territory_id | code_type | code_value |
| ------------ | --------- | ---------- |
| 1 | insee | 97682 |
| 1 | dep | 91 |

Cela permettrait de :
- synchroniser les données avec les producteurs de données (insee, cerema, etc.)
- annualiser les données
- séparer les territoires dans le sens officel des comptes qui peuvent être custom

Question à résoudre :
- quid des couches type epci, groupe d'epci, etc ? > est-ce qu'on a une liste exhaustive des types de codes possibles

### Permissions
Les territoires sont utilisés pour filtrer les trajets accessibles. La liste des territoires autorisés sont stockés dans redis via des informations customs ajoutés sur l'utilisateur (authorizedTerritories). Ces données sont utilisés par le ScopeToGroupMiddleware. Il faudrait remplacer authorizedTerritories comme int[] par un tableau de tuple type/valeurs et mettre à jour middleware et les tests associés.

Exemple:
IDFM = [['region',11]]

### Territory : geo vs usergroup
Actuellement il y a 13 actions possibles dans le service territoire. Avec le découpage usergroup vs geo, on peut :
- séparer les services en deux
- repartir les besoins du frontend pour redéfinir les actions

Dans tous les cas, le service devra être réécrit entièrement.

### Synchronisation de données
Il faudra prévoir une migration des données existante pour préserver les start/end_territory_id.

## Phasage

Avant d'entamer, il faut effectuer deux actions préparatoire au développement :
1. Définition Api (Nico + Julien) :arrow_forward:
2. Design de données (Nico + Ludo) :black_square_for_stop:

### Re-définition des besoins front

**Objectif**
* Déterminer les besoins du front afin d'implémenter les nouvelles APIs à développer coté BE

**Lexique**

* **"Un territoire geo" = zone** => Un territoire connu par les organismes publiques et répertorié par l'INSEE
* **"Un territoire utilisateur" = territoire** => Le user groupe, simple utilisateur de type 'territoire' sur la plateforme.
* **"Une AOM"** => Le regroupement de zones sur laquel un territoire a la compétence mobilité

**Utilisation Actuelle**

On créé un utilisateur territoire et le territoire géographique associée dans le même formulaire.
Les notions d'AOM et de zones géographiques sont confondues.

#### (New) Administration des zone par anticipation

Anticiper les MAJ des territoires (Doivent être ecrasés à la synchronisation avec le CEREMA)

**Besoins**
1. Créer une zone géographique nouvelle
2. Fusion de commune
3. Chancement de rattachement d'une commune (département, EPCI)

:warning: A voir si dans premier temps on fait juste des actions qui seront exécutées via CLI coté BE.

#### Création d'un utilisateur territoire

Création d'un territoire et de son AOM.
Une AOM est définie par un regroupement de zones géographique

**Besoins API**
1. Récupérer toutes les zones géographiques pour toutes les granularités (département, région, comune, EPCI ...)
3. Créer un utilisateur territoire et son AOM
5. Mettre à jours les informations d'un territoire et de son AOM

#### Récupérer les informations d'un utilisateur territoire

**Besoins API**
1. Récupérer un utilsiateur territoire via un id

#### Création d'une campagne

**Besoins API**
1. Récupérer une liste de zone de type communes (town) avec leur codes INSEE
~~2. Récupérer les opérateurs visibles par l'utilisateur territoire~~

#### Filtres statistiques

**Besoins API**
1. Obtenir une liste de zone géographique à partir de son nom ou département

Résumé des APIs :
1. CRUDL sur les territoires
2. L sur les zones avec filtres : textSearch sur numéro de departement ou nom ("95", "Franconville") et le type (town, region, ...)

### Définition des APIs

`zone:list`

export type ZoneListFilter = {     // Ancien TerritoryListFilter
  search?: string;  
  levels?: ZoneLevelEnum[];       // Ancien TerritoryLevelEnum
  skip?: number;
  limit?: number;
};

:warning: Le champ search fait une recherche sur la column 'name' actuellement (comportant les informations de departement et de nom)

`territory:create`

export type TerritoryCreate = {
    name
    level,
    company_id
    contacts, // R technique, R traitement, Délégué protection donnée 
    address,
}

:question: Une AOM a forcément une structure juridique ou est ratachée à une structure juridique ?
:question: Peut-on supprimer le nom d'usage ? (Le nom suffit)
:question: Peut on supprimer les champs active et activable ? (Une AOM créé sur RPC a forcément la compétence mobilité, et est partenaire du registre)
:question: A t-on toujours besoin du niveau de l'AOM ? (région ? département, ect ...)

### Impacts front

#### Fonctionels

:question: :pencil: Renomer l'actuelle liste de territoires en "AOM" fera une liste des AOM créés via formulaire ou recupéré via le CEREMA (cf dernière publication à ce sujet https://www.cerema.fr/fr/actualites/liste-composition-autorites-organisatrices-mobilite-au-1er-3)
:question: :pencil: (optionel) Ajouter un onglet en readonly permetant de lister toutes les zones géographiques utilisables (Pas nécéssaire mais permet d'avoir qqch d'iso avec aujourd'hui)

#### Techniques

1. Update des APIs
2. Enlever les unused call coté front
* getOperatorVisibility
* dropdown
* find (merger avec le list)
* getRelationUIStatus
* findByInsees
* getDirectRelation
* listOperator

##### Création d'un utilisateur territoire
1. :question: Enlever les 2 checkbox du formulaire de création de territoire "Ce territoire est partenaire du registre" et "Ce territoire a la compétence mobilité (AOM)" => Un territoire ajouté a forcément la compétence mobilité et est forcément partenaire du registre
2. Enlever la checkbox sur le choix entre Commune / Territoire parent => Uniquement via liste de code INSEE
3. Améliorer l'input existant permettant d'ajouter une liste de code INSEE => Ajout de nom de zone et recherche via nom de zone géographique (Envoi d'une liste de code INSEE au BE)
4. :question: Enlever l'autocompletion de la structure juridique du territoire
5. Remplacer le call à territory:dropdown par la liste des zones (`zone:list`)

##### Consultation de l'admin d'un territoire
1. Enlever la gestion parent/enfant dans les formulaire

##### Création d'une campagne
##### Filtres statistiques
1. Update avec le nouveau endpoint de list

La recherche d'un territoire via code INSEE pourra être implémenté coté front (afin de les valider lors de la saisie dans le formulaire, pas fait actuellement)