Ne plus procéder aux soft deletes

[francois-ferrandis]

ℹ️ Contexte

Actuellement, lorsque l'on supprime

• un RDV
• un agent
• un usager

il n'est pas réellement supprimé de la base de données, mais simplement marqué "supprimé".

Cela a plusieurs conséquences :

• nous devons, à chaque requête en base, se demande si les enregistrements supprimés sont à inclure ou exclure
• nous avons une incohérence dans les données, car il est techniquement possible d'avoir
  • un RDV sans usager (usager soft deleted)
  • un RDV sans agent (agent soft deleted)
  • une absence sans agent (agent soft deleted)
  • une plage d'ouverture sans agent (agent soft deleted)
  • une attribution de secteur à un agent qui n'existe plus (agent soft deleted)

La raison de cela, c'est qu'avec le soft delete, il est impossible d'utiliser les garanties de cohérence offertes par le système de base de données. En effet, notre base Postgres permet, lors de la suppression d'un agent, d'empêcher à coup sûr qu'un autre élément de la base y fasse référence. La vérification de cette cohérence incombe donc alors à l'application, ce qui est beaucoup trop complexe pour être fait sans bug.

Ces incohérences sont donc la cause de nombreux bugs. Un exemple de bug présent actuellement : nous avons une validation qui vérifie que l'on ne peut pas supprimer le dernier agent d'un territoire, mais cette validation permet de supprimer le dernier agent si il reste des agents supprimés. Autre exemple de bug : #3540.

Pourquoi ce système a été mis en place

Pour les usagers et agents

D'après les éléments de contexte que j'ai pu trouver, ce système a été mis en place pour les usagers et agents car les départements voulaient pouvoir "supprimer" un agent ou usager tout en gardant l'historique de ses RDVs, à des fins statistiques.

J'ai extrait ci-dessous des chiffres permettant de juger de l'impact qu'aurait une véritable suppression en base:

• Nombre de RDVs appartenant à des agents soft deleted : 40 312 (2,5 % de tous les RDVs)
• Nombre de RDVs appartenant à des users soft deleted : 5 113 (0,3 % de tous les RDVs)
• Nombre d'agents soft deleted : 2 545 (17 % sur un total de 14 626)
• Nombre de users soft deleted : 18 104 (2,6 % sur un total de 696 101)
• Nombre de RDVs soft deleted : 6 118 (0,37 % sur un total de 1 630 499)

Je pense donc qu'on pourrait faire part aux département du rapport entre la gène créée par cette feature, par rapport à la proportion de RDVs qui seraient perdus si on supprimait vraiment les agents (2,5 %).

Pour les RDVs

Le soft delete des RDVs a été mis en place dans #2691, suite à discussions sur la pertinence de ce choix (trouvables dans les pads de la PR). Nous pouvons trouver dans ce ticket les expressions de besoin des référentes : toutes expriment un besoin de pouvoir supprimer un RDV, mais pas un besoin de soft delete.

❓ Définition du problème

Nous avons donc le choix suivant :

• garder un système de soft delete et être condamné⋅es à gérer éternellement des bugs liés aux incohérence de notre modèle de données
• réellement supprimer les données et profiter des garanties offertes par notre RDBMS

Le coût de la seconde solution, c'est que lors de la suppression d'un agent ou d'un usager, ses RDVs sont supprimés en cascade, et disparaissent donc des statistiques.

💡 Solution envisagée

Une solution est déjà proposée dans la PR #3569.