La prise en compte des COMD dans le périmètre des procédures a été fait via https://github.com/MTES-MCT/Docurba/blob/29fbdfd4254228b5e0c325933426b01a29d8d389/nuxt/daily_dump/steps/7-updateComdPerimTable.mjs.
Ce script utilise des copies figées d'un appel à une API Sudocuh retournant des informations sur les DU approuvés et les DU en cours avec des COMD. Pour les procédures en question, il trouve la procédure Docurba avec l'identifiant from_sudocuh correspondant et insère une ligne dans la table procedures_perimetres avec les infos de la COMD.
Les conséquences de cette approche que l'on a pu remarqué :
- Les procédures qui ne sont ni en cours, ni opposables n'ont pas été modifiées et ne contiennent donc que la COM dans le périmètre.
- Dans les procédures en cours et opposables, certaines procédures ont un périmètre avec uniquement la COMD, d'autres avec la COMD et la COM. Je ne vois rien dans le script expliquant ce comportement.
Si/Quand on voudra ré-importer plus proprement ces données, on pourra se baser sur les tables communefusionprocedure et communefusion qui contiennent les informations.
La prise en compte des COMD dans le périmètre des procédures a été fait via https://github.com/MTES-MCT/Docurba/blob/29fbdfd4254228b5e0c325933426b01a29d8d389/nuxt/daily_dump/steps/7-updateComdPerimTable.mjs.
Ce script utilise des copies figées d'un appel à une API Sudocuh retournant des informations sur les DU approuvés et les DU en cours avec des COMD. Pour les procédures en question, il trouve la procédure Docurba avec l'identifiant
from_sudocuhcorrespondant et insère une ligne dans la tableprocedures_perimetresavec les infos de la COMD.Les conséquences de cette approche que l'on a pu remarqué :
Si/Quand on voudra ré-importer plus proprement ces données, on pourra se baser sur les tables
communefusionprocedureetcommunefusionqui contiennent les informations.