Pointer sur la *plus récente* date de delib de prescription, d'approbation lorsque plusieurs délibérations sont renseignées

[CeliaVermicelli]

Contexte :

Des procédures ont parfois plusieurs délibérations renseignées et "valides". Cela arrive lorsque la CT a dû ajuster/rectifier le contenu de la première délibération et donc il n'est pas rare qu'elles doivent en saisir une deuxième, avec une nouvelle date donc.

Problème :

L'onglet "mes procédures" et le résultat de l'export csv des procédures (colonne "pc-date-prescription" et "pa-date-prescription" et "pa-annee-prescription") consignent la toute première date de prescription renseignée et ignore la 2eme alors que c'est elle qui fait foi.

Exemple :

• 15.01.2025 : delib de prescription complémentaire ou qui annule la précédente
• 22.12.2024 : délibération de prescription

La date de prescription à "pointer" est le 15.01.2025

@HermanceGauth

• Sandrine C. 2B

[HermanceGauth]

Le problème est le même, même quand la prescription a été rendu invalide dans Sudocuh : https://docurba.beta.gouv.fr/ddt/81/collectivites/81248/commune
Actuel : dans l'export date prescription du PLUi 2018-04-09
Attendu : dans l'export date de prescription du PLUi 2021-11-22

Autres cas remontés par Claire où ce problème fait qu'on affiche pas la bonne procédure en cours : ex 81041 , 81225 ,
PB sur Export procédure et export superset
ce qui confirme que la règle dans Sudocuh prend bien la prescription la plus récente, surtout quand la plus ancienne a été rendue invalide.

[UngererFabien]

@HermanceGauth @CeliaVermicelli comme on utilise la même logique pour tous les types d'events. Est ce qu'on doit faire un cas particulier pour les prescriptions ? Ou bien est ce qu'on applique cette logique pour tous les types d'events ?

Donc par exemple, si il y a 2 event d'approbation, est ce qu'on prend la plus récente ?

Y a pas de limitation technique et les deux choix (systématique le plus récents ou spécifique pour les prescriptions)prennent le même temp de dev.

Le choix systématique aura évidement plus d'impacte dans le TDB et les exports.

[HermanceGauth]

Effectivement, appliquons cette logique pour tous les évènements impactants, voir : #850

[CeliaVermicelli]

Deux Exemples remontés par la DDT 16

Nercillac (16)

1. Elaboration du PLUi de la CA du Grand Cognac : https://docurba.beta.gouv.fr/frise/7e422814-a017-473a-aea6-02bb53525c2c

• ❌ La proc. 1 est précédente alors qu'elle devrait être opposable

2. Révision du PLU de Nercillac : https://docurba.beta.gouv.fr/frise/cb8b4784-bb3c-4a82-8ddd-82c1dbc7de60

• ❌ La proc 2 est opposable alors qu'elle devrait être précédente

Cas de Mérignac (16)

1. Elaboration du PLUi de la CA du Grand Cognac : https://docurba.beta.gouv.fr/frise/7e422814-a017-473a-aea6-02bb53525c2c

• ❌ La proc. 1 est précédente alors qu'elle devrait être opposable

2. Révision du PLU de Mérignac : https://docurba.beta.gouv.fr/frise/abf18039-134c-4ee1-96b9-e79b502174a5

• ❌ La proc 2 est opposable alors qu'elle devrait être précédente

---

• Pascal, 16 (par email)

[UngererFabien]

@rik betagouv/docurba-nuxt3#16

[HermanceGauth]

Attention, parfois c'est l'event le plus récent qui est invalide et on voit que les DDT on rempli "salement" pour contourner les limitation de Sudocuh : https://docurba.beta.gouv.fr/frise/9333d7c5-e359-4ba9-9574-733ad54da2f1

[rik]

Le code est maintenant en production. J'ai fait tourner la mise à jour des statuts pour toutes les procédures. Je passe la main à Hermance et Célia pour les vérifs.

Attention, parfois c'est l'event le plus récent qui est invalide et on voit que les DDT on rempli "salement" pour contourner les limitation de Sudocuh : https://docurba.beta.gouv.fr/frise/9333d7c5-e359-4ba9-9574-733ad54da2f1

Je ne vois aucune gestion des événements "invalide" dans le code (hormis l'affichage sur la frise). Ouvrons une autre issue pour détailler le travail qu'on doit faire à ce sujet.

[HermanceGauth]

Tous les cas que j'avais remonté dans cette issue sont bien résolus.

[CeliaVermicelli]

j'ai commenté directement dans mon commentaire sur les cas de Mainxe et Gondeville qui sont encore incorrects

[HermanceGauth]

Pour les deux cas restants on est effectivement dans le cas de cette issue #1081 J'écris aujourd'hui à Claire pour comprendre pourquoi on avait mis la règle actuelle.

[HermanceGauth]

Je ne vois aucune gestion des événements "invalide" dans le code (hormis l'affichage sur la frise). Ouvrons une autre issue pour détailler le travail qu'on doit faire à ce sujet.

@rik je vais faire l'issue, en revanche celle-ci me fait dire qu'il y avait bien à un moment des choses sur les event invalide dans le code #761

[CeliaVermicelli]

@HermanceGauth donc de mon côté c'est tout bon pour les cas cités.
J'ai basculé le cas de Mainxe gondeville dans l'issue 1081. en maj mon commentaire initial.