Afin de respecter la RGPD, je voudrais ajouter une fonction de suppression des adhérents qui n’ont plus renouvelé leur adhésion depuis 3 ans pour la lancer en tâche planifié tous les soirs.
Je pense la rajouter dans le fichier /var/www/html/dolibarr/htdocs/adherents/class/adherent.class.php entre la fonction delete($rowid, $user, $notrigger = 0) et setPassword($user, $password = ‹ ›, $isencrypted = 0, $notrigger = 0, $nosyncuser = 0) .
Voici ce que j’ai écrit pour l’instant :
/**
* Suppression des adherents qui n'ont plus renouvelle leur adhesion depuis 3 ans
*/
public function suppr_tres_anciens_adherents($user) {
$nbrowsaffected=0;
$this->db->begin();
dol_syslog(get_class($this)."::update update member", LOG_DEBUG);
$sql1 = "SELECT rowid FROM ".MAIN_DB_PREFIX."adherent WHERE (datefin IS NOT NULL AND datefin<DATE_ADD(CURRENT_DATE, INTERVAL -3 YEAR))";
$resql1=$this->db->query($sql1);
if ($resql1) {
$nbrowsaffected+=$this->db->affected_rows($resql1);
while ($row = $resql1->fetch_assoc()) {
$this->delete($row['rowid'], $user, $nbrowsaffected);
}
}
return $nbrowsaffected;
}
Ça ne fonctionne pas (j’ai bien essayé en passant AdminDolibarr dans les paramètres de la tâche planifié). Si vous avez une idée comment faire, je suis preneur de toute correction.
Si je remplace la ligne $this->delete($row['rowid'], $user, $nbrowsaffected); par echo $row[rowid]; j’ai bien la liste des rowid des adhérents qui ont « expiré » depuis plus de trois ans.
Il me semble donc que c’est la ligne $this->delete($row['rowid'], $user, $nbrowsaffected); qui est incorrect mais je ne sais pas pourquoi.
J’ai essayé $this->delete($row['rowid'], 'AdminDolibarr); mais ça ne fonctionnait pas non plus.
J’y pense, il faudra que j’essaye $this->delete($row['rowid'], $user, 1);
/**
* Suppression des adherents qui n'ont plus renouvelle leur adhesion depuis 3 ans
*/
public function suppr_tres_anciens_adherents($user) {
$nbrowsaffected=0;
$this->db->begin();
$sql1 = "SELECT rowid FROM ".MAIN_DB_PREFIX."adherent WHERE (datefin IS NOT NULL AND datefin<DATE_ADD(CURRENT_DATE, INTERVAL -3 YEAR))";
$resql1=$this->db->query($sql1);
if ($resql1) {
$nbrowsaffected+=$this->db->affected_rows($resql1);
while ($row = $resql1->fetch_assoc()) {
$rowids[]=$row['rowid'];
}
$this->db->commit();
$array_length = count($rowids);
for ($i = 0; $i < $array_length; $i++) {
$this->delete($rowids[$i], $user, 1);
}
}
return $nbrowsaffected;
}
Si quelqu’un a une proposition plus propre, je suis preneur.
Je me demande sil ne conviendrait pas d’utiliser la méthode de la classe adhèrent. En procédant directement dans la base vous risquez de laisser des « traces ». Typiquement les cotisations liées, les tiers, les factures, etc. concernant les adhérents vont subsister.
C’est à dire utiliser la méthode de la classe adhèrent?
Il me semblait qu’utiliser la fonction delete() de adherent.class.php permettait justement de supprimer tout ce qui est relatif à un adhérent.
$this->delete($rowids[$i], $user, 1);
Pourriez-vous m’indiquer comment modifier le code pour qu’il soit meilleur?
Excusez-moi, j’ai mal lu votre premier post: je pensais que vous aviez créer un module externe (ce qui sersit le plus propre pour pouvoir faire les mises à jour) et que la fonction $this->delete était issu de votre cru.
Bonsoir, @Thatoo j’ai envie de faire une suggestion: au lieu de supprimer les entrées, il vaut vraiment mieux les anonymiser ! Je m’explique: le modèle de base de données de dolibarr n’est pas super rigoureux et pas mal de clés étrangères dans des tables (les liens entre les tables) ne sont pas contraintes au niveau du moteur de la base de données.
Vous risquez de supprimer des lignes d’une table qui est nécessaire sur une autre table.
Un exemple serait une adhésion, payée il y a 4 ans: un lien existe entre l’adhésion et l’adhérent, je supprime l’adhérent mais pas l’adhésion, boum un lien cassé.
Je ne sais pas si c’est valable sur ce cas précis (adhérent/facture), certaines relations sont contraintes au niveau de la bdd mais pas toujours … anonymiser les données (xxxxxx au lieu du prénom) permet de se prémunir du disque d’une base de donnée trouée.
A terme, la bdd va prendre une place énorme de manière inutile. Je gère une grosse associations (plusieurs centaines de membres annuels).
Certains des membres « résiliés » sont morts depuis cinq ans. D’autres n’ont jamais donné de nouvelles depuis 15 ans. On a aussi toute une série d’anciens membres qui ne peuvent plus adhérer parce qu’ils ne répondent plus au critères dentrée (age, santé, etc.). Dans certains cas, le simple fait d’être adhérent est une donnée sensible (syndicaliste, partit politiques, etc.)
Les premières versions de dolibarr généraient moins de documents, mais le nombre de fichiers et d’entrée dans la base contenant des données sensibles (nom, prénoms, adresse, date de naissance, email, etc.) devient conséquent.
Si l’on ajoute les libellés des opérations bancaires dans la compta…
Bref, je pense qu’il faut trouver un moyen de purger la base ET les fichiers. Pour des raisons légales, nous devons conserver les documents comptables au moins 10 ans, mais pour des raisons légales, il ne faudrait pas conserver les données des employés plus de 5 ans (si j’ai bien compris).
La question juridique dépasse quelques peu mes compétences, mais, si j’ai bien compris, il faudrait faire une différence entre archivage intermédiaire et archivage définitif.
@daraelmin a mon avis il y a un GROS dossier sur le plan RGPD et Dolibarr, il me semblerait judicieux de monter un groupe de travail composé d’utilisateurs de domaines différents (associatifs, tpe, indépendants, pme, etc…) ET d’experts du domaine juridique.
Dans la dernière version j’ai commencé à implémenter un anonymiseur de données mais je ne me suis pas encore penché sur les documents stockés dans dolibarr.
À mon avis il faudrait un truc comme un rasoir à plusieurs lames : 1er coup pour les X années sur X type de données (liste à faire et durée à clarifier), un 2° coup de lame X années plus tard pour X type de données (idem) et peut-être un 3° coup ?
Oui, ce serait bien ce rasoir à trois lames, mais il faudrait également pouvoir crypter le dossier documents pour éviter le vol de données. qqch comme ce que fais Nectcloud.
A ce propos je suis impatient de voir comment la règlementation RGPD sera prise en compte sur la future plateforme de transmission des factures électroniques (dans l’hypothèse où c’est pris en compte).
Niveau légal si mes souvenirs sont bons, il est possible d’anonymiser les factures faites à un particulier tout en restant dans les clous par rapport aux exigences de la legislation fiscale qui impose une conservation des factures de 10 ans.
Pour les factures faites à un professionnel assujeti à la TVA le juriste que j’avais eu en formation RGPD estimait que sans jurisprudence ça restait « flou ».
Plus spécifiquement pour la question posée à l’origine du fil de discussion, une purge annuelle ou semestrielle me semble suffisante pour respecter la règlementation RGPD. Il suffit de le préciser au moment de l’adhésion, et de laisser la possibilité à tout adhérent de demander une suppression anticipée de ses données personnelles.
D’après mon comptable, il faut conserver les factures originales sur un support déconnecté (pdf ou papier) pour respecter le rgpd et les obligations fiscales.
Tout ce débat ne répond pas à la question : comment faire pour ne pas bousiller les liens et garantir les mises à jour ?
@erics souligne que certaines contraintes sont absentes dans Dolibarr… et quid des modules supp ? des extrafields ?
La base est difficilement cryptable, mais le dossier documents devrait pouvoir l’être.
Le fait de conserver des données sur un support déconnecté, ou en version papier ne change absolument rien vis à vis de la réglementation RGPD. On pense souvent à tort que cela ne concerne que les données numériques, mais la loi ne fait aucune différence entre les données numériques et les données « papier ».
