> ## Documentation Index
> Fetch the complete documentation index at: https://api-documentation.kare-app.fr/llms.txt
> Use this file to discover all available pages before exploring further.
# Gestion des softs delete
Le soft delete est le principe de supprimer un élément en simplement définissant un champ deletedAt avec une date, afin qu'il ne s'affiche plus dans la récupérations des données, mais il n'est pas en réalité complètement supprimé.
C'est utile pour être plus souple dans les conditions de suppression d'un élément → même si des liens sont obligatoires, il suffit de renseigner le champ et il ne s'affichera plus.
Le soft delete est utilisé pour les éléments bas dans la hiérarchie (anomalie, rapport), desquels on ne souhaite plus voir les données.
Il s'oppose à l'archivage qui sera possible pour tous les éléments. Celui-ci veut garder une traçabilité de la donnée, et est obligatoire pour les éléments hauts dans la hiérarchie (IT, règles, etc.).
**Reste à déterminer précisement :** hiérarchie basse et haute
**Combinaisons possibles:**
soft delete + archivage
hard delete + archivage
**Comment gérer l'affichage pour les éléments supprimés dans le drawer ?**
Pas d'affichage drawer complet → ouvrir drawer mais afficher que l nom de l'élément, et dans body, afficher "cet élément a été supprimé"
**Comment gérer l'affichage des éléments supprimés dans les différents affichages ou ils peuvent apparaitre ?**
> Par exemple, imaginons que je puisse supprimer une IT, comment est-ce que celle-ci s'affiche sur le tableau anomalie si des anomalies étaient reliées ? pareil dans le drawer de l'anomalie ?
- simplement la masquer ?
- affiché mais grisé ? avec un tag particulier ? un badge rouge ?
- l'affiché normalement dans les tableaux, mais avec un tag dans les drawer ?
- limité la suppression au niveau du domaine ?
>
> Toutes les questions se posent aussi avec **l'archivage.**
Dans les tableaux : on masque les éléments
Dans les cases des tableaux : italique + tag/couleur/dot
Dans les drawers (d'un élément non supprimé) : italique + tag/couleur/dot
Affichage de l'icône d'une IT supprimée ? → on ne peut pas supprimée une IT, elle s'archive avec ses éléments enfants
### Liste des éléments
on soft delete toujours les éléments, et quand ça pose problème au niveau des "unique" (exemple utilisateur, il faut remplacer le champ par autre chose)
### RS
| | **Soft delete** | **Archivage** | Hard delete |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | -------------------------------------------- |
| **user** | *possible, en retirant les données de l'utilisateur (uuid*
*à la place du mail)* | *?* | |
| **Notification** | *possible sans condition ?* | *?* | |
| **unit** | *- pas possible pour l'utilisateur RS* | ? | jamais pour l'instant
(3 ans théorique) |
| **Building** | pas de condition
cascade sur ses éléments | NON | |
| **plan** | pas de condition
cascade sur ses éléments | NON | |
| **plan-item** | pas de condition | NON | |
| **equipment** | possible tant qu'il n'a pas d'élément de relié | NON | |
| **IT**
retirer un site
retirer d'une orga | A partir ou le site est relié à une règle
enfant on peut pas
ne peut pas si une anomalie ou équipement de relié
ni aucun autre élément
(sauf les sites reliés, et les règles → peut être fait en
cascade si rien de relié) | pas de condition | jamais pour l'instant |
| **rule** | à partir du moment ou quelque chose est relié
(sauf les sites reliés,→ peut être fait en
cascade si rien de relié) | pas de condition | |
| **Compliance** | | | |
| **Anomaly**
non conformité
prescription
observation | pas de condition (avec corbeille) | pas de condition | au bout de 30j |
| **Rapport**
rvre, pv | pas de condition (avec corbeille) | pas de condition | |
| **Commission** | *pas possible si la commission est signée* | *pas de condition* | |
| **Building-work** | *pas de condition ?* | *pas de condition* | |
| **Intervention**
curative, preventive | pas de condition sauf signature (sinon c'est archivage) | pas de condition | |
| **Routine** | *si des interventions sont reliées ?* | *pas de condition* | |
| **Document** | *pas de condition ?* | *pas de condition* | |
| **Attachment** | *pas de condition ?* | *- pas possible* | |
| **Comment** | *pas de condition* | *- pas possible* | |
| **Tag** | *pas de condition ?* | *- pas possible ?* | |
| **Label** | *pas de condition ?* | *- pas possible ?* | |
| **Provider** | *si des éléments sont liés ?* | *pas de condition* | |
| **Contract** | *si des éléments sont liés ?* | *pas de condition* | |
| **Calendar** | - | - | |
| **LogBook** | *pas de condition ?* | *pas de condition ?* | |
| **Formation**
(collective, exercice,
qualification) | pas de condition particulière | pas de condition | |
Les décisions pourront être prisent dans la phase d'idéation des règles du domaine.
***
> Chantier transverse (back & front). Pistes = hypothèses à valider.
## 1. Contexte
La décision droits B1 a posé que **toute suppression = soft delete** (pas de hard delete par défaut), avec **corbeille optionnelle** et une **purge définitive** (`data.purge`) **back-office uniquement** (retirée de l'app ; révisé 2026-06-25). Reste à définir **comment le soft delete se comporte de façon cohérente dans toute l'application**, côté **back** comme **front**.
## 2. Problème
Sans politique unifiée, le soft delete est traité au cas par cas selon les entités : comportements d'affichage incohérents, relations cassées (un élément supprimé encore référencé), risque pour la valeur probante du registre, et pas de parcours clair de restauration / purge.
## 3. Existant dans Kare
* Suppressions **bloquées par des garde-fous métier** : rapport non supprimable si une anomalie est résolue (`resolved > 0`), intervention non supprimable si un rapport est lié, anomalie résolue non supprimable, règle utilisée non supprimable (cf. cartographie produit 2026-06-24).
* Mécanismes proches existants : **archivage de règles par site** (le transfert de règles n'est pas développé — règles modifiables en place, révisé 2026-06-26).
* Pas de **modèle de soft delete générique** documenté (flag supprimé, filtrage, restauration, purge).
## 4. Besoins
* Un **comportement de soft delete homogène** sur toutes les entités (flag + horodatage + auteur).
* **Back** : exclusion par défaut des éléments supprimés des requêtes, intégrité référentielle (que devient une relation vers un élément supprimé ?), purge contrôlée.
* **Front** : masquage par défaut, éventuelle **corbeille** (optionnelle, B1), parcours de **restauration**, messages clairs.
* Respect du **cadre réglementaire** : ne pas détruire la preuve (archivage > suppression pour les éléments du registre) — cf. \[⚖️ Cadre réglementaire — modifications et suppressions]\(⚖️ Cadre réglementaire — modifications et suppressions).
## 5. Pistes (hypothèses — non validées)
* Champ standard `deletedAt` + `deletedBy` sur les entités concernées ; filtrage transverse au niveau requête.
* **Soft delete vs archivage** : clarifier la frontière (suppression = sortie de l'usage courant, restaurable ; archivage = conservation volontaire d'un historique). Possible convergence.
* **Corbeille** optionnelle par organisation (B1) ; purge = `data.purge` **back-office uniquement** (hors app).
* Cascade maîtrisée : définir, par relation, si la suppression d'un parent masque/bloque/conserve les enfants.
## 6. Questions à valider
* Quelles entités sont **soft-deletable** (toutes ? exceptions juridiques) ?
* Frontière **soft delete ↔ archivage** : deux mécanismes ou un seul ?
* Corbeille : activée par défaut ou option ? portée (par entité / globale) ?
* Comportement **front** : où voit-on les éléments supprimés, comment les restaurer ?
* Intégrité : une relation pointant vers un élément supprimé — masquée, conservée, ou bloquante ?
## 7. Liens
* \[Droits et permissions]\(Droits et permissions) §15 (B1 soft delete, corbeille, `data.purge`)
* \[Droits - Capabilities]\(Droits - Capabilities) §20 (B1)
* [Archivage](Archivage) — frontière avec l'archivage
* \[⚖️ Cadre réglementaire — modifications et suppressions]\(⚖️ Cadre réglementaire — modifications et suppressions) — preuve / intégrité
* \[Logique de suppression des rapports]\(Logique de suppression des rapports) — cas spécifique rapports
## 8. Décisions
* \*\*Frontière soft delete ↔ archi