Projet

Général

Profil

Development #24430

Supprimer les utilisateurs quand ils ne sont plus liés à aucune demande

Ajouté par Benjamin Dauvergne il y a 7 mois. Mis à jour il y a 3 jours.

Statut:
Solution proposée
Priorité:
Normal
Assigné à:
Début:
11 juin 2018
Echéance:
% réalisé:

0%

Patch proposed:
Oui

Description

Actuellement je limite volontairement la suppression des comptes en ligne car le deprovisionning va supprimer les comptes coté w.c.s. perdant possiblement des informations importantes pour le traitement des demandes (si la demande n'a pas de champ identifiant le demandeur car réservée aux utilisateurs identifiées).

L'idée ici serait sur une demande de deprovisionning venant d'a2 de simplement supprimer le NameID et de ne pas supprimer l'utilisateur.

Dans un deuxième temps un processus CRON viendrait lister tous les utilisateurs sans NameID et selon des critères à déterminer les supprimeraient si nécessaire disons par exemple. « l'utilisateur n'est lié à qu'à des formulaires en statut terminal dont la dernière action remonte à plus de 90 jours ».

Cette réflexions font suite aux demandes de Nanterre sur le ticket #24156.

On pourrait aussi parler du de-provisionning au niveau des connecteurs passerelle (cas des liaisons avec les logiciels métiers "famille") mais je vais ouvrir un autre ticket, même si ça reste lié car tant qu'un workflow aura besoin de cette liaison pour accomplir des appels il faudrait:
1. que son appairage reste conservé,
2. que w.c.s. conserve quelque part le NameID si c'est le seul moyen de faire référence à l'utilisateur lors des appels à passerelle.

Le 1 indique qu'il faudrait non pas supprimer le NameID mais indiqué sur l'utilisateur qu'ils est obsolète (et donc viser plutôt un flag, "utilisateur supprimé" posé sur l'objet User).
Le 2 milite pour que w.c.s. balance aussi son propre message de de-provisionning à destination de passerelle cette fois ci.

0002-user-add-a-deleted-flag-24430.patch Voir (4,05 ko) Benjamin Dauvergne, 04 oct. 2018 23:42

0003-users-add-cronjob-to-delete-users-24430.patch Voir (5,82 ko) Benjamin Dauvergne, 04 oct. 2018 23:42

0004-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (946 octets) Benjamin Dauvergne, 04 oct. 2018 23:42

0001-fix-deprecation-warning-in-ElementTree.patch Voir (1,09 ko) Benjamin Dauvergne, 04 oct. 2018 23:42

0002-user-add-a-deleted-flag-24430.patch Voir (4,05 ko) Benjamin Dauvergne, 04 oct. 2018 23:44

0003-users-add-cronjob-to-delete-users-24430.patch Voir (3,95 ko) Benjamin Dauvergne, 04 oct. 2018 23:44

0004-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (946 octets) Benjamin Dauvergne, 04 oct. 2018 23:44

0001-fix-deprecation-warning-in-ElementTree.patch Voir (7,29 ko) Benjamin Dauvergne, 04 oct. 2018 23:44

0001-users-add-deletion-status-to-display_name-24430.patch Voir (1,07 ko) Benjamin Dauvergne, 04 oct. 2018 23:50

0005-users-add-deletion-status-to-display_name-24430.patch Voir (1,07 ko) Benjamin Dauvergne, 05 oct. 2018 10:32

0002-user-add-a-deleted-flag-24430.patch Voir (4,05 ko) Benjamin Dauvergne, 05 oct. 2018 10:32

0003-users-add-cronjob-to-delete-users-24430.patch Voir (4,15 ko) Benjamin Dauvergne, 05 oct. 2018 10:32

0004-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (3,87 ko) Benjamin Dauvergne, 05 oct. 2018 10:32

0001-fix-deprecation-warning-in-ElementTree.patch Voir (7,29 ko) Benjamin Dauvergne, 05 oct. 2018 10:32

0004-users-add-deletion-status-to-display_name-24430.patch Voir (1,07 ko) Benjamin Dauvergne, 14 oct. 2018 19:15

0002-users-add-cronjob-to-delete-users-24430.patch Voir (4,15 ko) Benjamin Dauvergne, 14 oct. 2018 19:15

0001-user-add-a-deleted-flag-24430.patch Voir (4,05 ko) Benjamin Dauvergne, 14 oct. 2018 19:15

0003-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (3,87 ko) Benjamin Dauvergne, 14 oct. 2018 19:15

0005-users-add-deletion-status-to-display_name-24430.patch Voir (1,07 ko) Benjamin Dauvergne, 17 déc. 2018 12:53

0004-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (3,87 ko) Benjamin Dauvergne, 17 déc. 2018 12:53

0002-users-add-cronjob-to-delete-users-24430.patch Voir (4,15 ko) Benjamin Dauvergne, 17 déc. 2018 12:53

0001-user-add-a-deleted-flag-24430.patch Voir (4,05 ko) Benjamin Dauvergne, 17 déc. 2018 12:53

0003-d-placement-impl-mentation-clean_deleted_users-fixup.patch Voir (4,45 ko) Benjamin Dauvergne, 17 déc. 2018 12:53

0005-users-add-deletion-status-to-display_name-24430.patch Voir (1,07 ko) Benjamin Dauvergne, 17 déc. 2018 13:37

0006-adaptation-test_hobo_notify-suite-d-placement-clean_.patch Voir (1,24 ko) Benjamin Dauvergne, 17 déc. 2018 13:37

0004-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (3,87 ko) Benjamin Dauvergne, 17 déc. 2018 13:37

0002-users-add-cronjob-to-delete-users-24430.patch Voir (4,15 ko) Benjamin Dauvergne, 17 déc. 2018 13:37

0001-user-add-a-deleted-flag-24430.patch Voir (4,05 ko) Benjamin Dauvergne, 17 déc. 2018 13:37

0003-d-placement-impl-mentation-clean_deleted_users-fixup.patch Voir (4,45 ko) Benjamin Dauvergne, 17 déc. 2018 13:37

0003-users-add-cronjob-to-delete-users-24430.patch Voir (4,15 ko) Benjamin Dauvergne, 17 déc. 2018 14:34

0005-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (3,87 ko) Benjamin Dauvergne, 17 déc. 2018 14:34

0001-user-add-a-deleted-flag-24430.patch Voir (4,05 ko) Benjamin Dauvergne, 17 déc. 2018 14:34

0004-d-placement-impl-mentation-clean_deleted_users-fixup.patch Voir (4,45 ko) Benjamin Dauvergne, 17 déc. 2018 14:34

0007-adaptation-test_hobo_notify-suite-d-placement-clean_.patch Voir (1,24 ko) Benjamin Dauvergne, 17 déc. 2018 14:34

0006-users-add-deletion-status-to-display_name-24430.patch Voir (1,07 ko) Benjamin Dauvergne, 17 déc. 2018 14:34

0002-corrige-migration-ajout-colonne-deleted-to-fixup.patch Voir (853 octets) Benjamin Dauvergne, 17 déc. 2018 14:34

0005-users-add-deletion-status-to-display_name-24430.patch Voir (1,07 ko) Benjamin Dauvergne, 19 déc. 2018 16:20

0003-users-add-cronjob-to-delete-users-24430.patch Voir (6,31 ko) Benjamin Dauvergne, 19 déc. 2018 16:20

0004-hobo_notify-deprovision-by-setting-the-deleted-flag-.patch Voir (3,87 ko) Benjamin Dauvergne, 19 déc. 2018 16:20

0001-user-add-a-deleted-flag-24430.patch Voir (5,21 ko) Benjamin Dauvergne, 19 déc. 2018 16:20

0002-corrige-migration-ajout-colonne-deleted-to-fixup.patch Voir (853 octets) Benjamin Dauvergne, 19 déc. 2018 16:20


Demandes liées

Lié à Publik - Development #26907: Cycle de vie des comptes Nouveau 02 oct. 2018

Historique

#1 Mis à jour par Brice Mallet il y a 7 mois

  • Tracker changé de Bug à Development

Cette réflexions font suite aux demandes de Nanterre sur le ticket #24156.

Et plus globalement je dirais au respect du RGPD, il faut pour voir réellement supprimer les comptes (demande de la DPO de Fontenay, dès à présent)

disons par exemple. « l'utilisateur n'est lié à qu'à des formulaires en statut terminal dont la dernière action remonte à plus de 90 jours ».

Encore plus simple : « l'utilisateur n'est lié à aucun formulaire », ce qui devrait être le cas avec des "vieux" comptes et des actions d'anonymisation correctement paramétré et si n'est pas le cas, cela nous donne un argument de plus pour encourager à paramétrer correctement des délais d'anonymisation au plus court.

#2 Mis à jour par Benjamin Dauvergne il y a 4 mois

#3 Mis à jour par Benjamin Dauvergne il y a 4 mois

  • Assigné à mis à Benjamin Dauvergne

#4 Mis à jour par Benjamin Dauvergne il y a 4 mois

Le premier patch est purement gratuit, juste des warnings irritants.

#5 Mis à jour par Benjamin Dauvergne il y a 4 mois

Le coup est parti trop vite.

Donc premier patch gratuit.

Deuxième patch ajout d'une nouvelle colonne booléenne "deleted".

Troisième patch cronjob de nettoyage des utilisateurs à supprimer.

Quatrième patch changement dans hobo_notify pour poser ce flag plutôt que de supprimer les utilisateurs.

À voir si j'en rajoute une couche pour afficher un petit disclaimer "(supprimé)" un peu partout dans les IHMs, via je ne sais quel point de coupure.

#6 Mis à jour par Benjamin Dauvergne il y a 4 mois

Voilà pour discussion.

#7 Mis à jour par Benjamin Dauvergne il y a 4 mois

Voilà, avec des tests en plus pour valider que tout roule avec hobo_notify et
les messages de deprovisionning (qui n'étaient pas testés).

#9 Mis à jour par Benjamin Dauvergne il y a 3 mois

Ce patch ne traite pas le cas des agents apparaissant dans l'historique (cas pas traité actuellement non plus, donc il n'y a pas de régression).

#10 Mis à jour par Benjamin Dauvergne il y a environ un mois

Patch s'appliquant toujours sur master.

#11 Mis à jour par Frédéric Péters il y a environ un mois

Discussion par ailleurs sur le fait de créer des utilisateurs dans w.c.s. et pas dans authentic…

#12 Mis à jour par Benjamin Dauvergne il y a environ un mois

Frédéric Péters a écrit :

Discussion par ailleurs sur le fait de créer des utilisateurs dans w.c.s. et pas dans authentic…

Ce ticket est intéressant sans cette discussion; en gros je ne vois pas le fait de finir cette discussion comme étant bloquant pour intégrer ce patch.

Ce que fait ce patch c'est de combiner nos obligations légales qu'on ignore pour l'instant avec les besoins fonctionnels de w.c.s., i.e. le fait que les formdata qui perdent l'utilisateur associés produisent une perte de fonctionnalité importante, au niveau du traitement du formdef lui même mais aussi au niveau du traitement global de différentes demandes de l'usager (sans parler des workflows qui nécessitent la présence des variables form_user_name_identifiers_0 pour ne serait-ce que fonctionner).

#13 Mis à jour par Frédéric Péters il y a environ un mois

Ce ticket est intéressant sans cette discussion; en gros je ne vois pas le fait de finir cette discussion comme étant bloquant pour intégrer ce patch.

C'est parce que je me mets à imaginer des critères supplémentaires à prendre en compte, pour éviter des suppressions malheureuses. (genre quelqu'un au guichet, on commence la saisie backoffice de sa demande, on la garde en brouillon pour la reprendre le lendemain parce qu'il y a quelques documents à scanner à inclure dedans, paf le lendemain le compte n'est plus là).

#14 Mis à jour par Benjamin Dauvergne il y a environ un mois

Je laisse 90 jours, c'est dit dans la description, ça devrait aller.

#15 Mis à jour par Frédéric Péters il y a environ un mois

Je laisse 90 jours, c'est dit dans la description, ça devrait aller.

« l'utilisateur n'est lié à qu'à des formulaires en statut terminal dont la dernière action remonte à plus de 90 jours ».

Mais dans 0002-users-add-cronjob-to-delete-users je ne vois pas apparaitre cette notion de "dernière action remonte à plus de 90 jours". Et de là je comprends "« utilisateur n'est (lié qu'à des formulaires en statut terminal) ET (dont la dernière action remonte à plus de 90 jours) ». Et si w.c.s. s'occupe du premier terme (formulaires en statut terminal), ce serait "autre chose" qui assurerait que le message de déprovisionning n'arriverait pas avant 90 jours.

Et aussi, 0002 ne fait pas "formulaires en statut terminal" mais "pas de formulaire du tout", cf la redéfinition du critère en premier commentaire, « l'utilisateur n'est lié à aucun formulaire ».

~~

Bref, tout un historique à s/me remettre en tête.

#16 Mis à jour par Benjamin Dauvergne il y a environ un mois

Frédéric Péters a écrit :

Je laisse 90 jours, c'est dit dans la description, ça devrait aller.

Oui c'est vrai finalement j'ai choisi de partir sur pas de formulaire du tout, je l'avais oublié, ce qui est mieux parce que :
1. ça ne met pas de durée particulière en dur qu'il faudrait venir configuré, ces questions restent au niveau du paramétrage des workflows,
2. ça évite de se poser la question de ce qui est terminal ou pas,
3. ça oblige à traiter le problème du nettoyage des brouillons (en vrai je n'y pensais pas du tout mais ta remarque me permet d'y penser) si ce n'est pas déjà le cas.

#17 Mis à jour par Frédéric Péters il y a environ un mois

Je vais faire tourner ça en local un peu.

Sur la forme, je ne trouve pas "users: add cronjob to delete users (#24430)" terrible, c'est dommage d'avoir ainsi du code devant faire la distinction sql/pickle. Peut-être plutôt, taper une méthode neutre, genre dans la classe Publisher, enregistrée via register_cronjobs, qui, elle, pourra faire appel à publisher.user_class et appeler du code situé dans la bonne classe (code qui pourrait juste être un get_active_ids, il me semble).

#18 Mis à jour par Benjamin Dauvergne il y a environ un mois

J'ai intégré tes remarques, par contre plutôt qu'un get_active_ids() je génère directement la liste des ids à détruire, l'idée étant que le comportement à faire pour la destruction reste dans publisher seul la logique pour déterminer les comptes inactifs reste dans users.py et sql.py.

#20 Mis à jour par Frédéric Péters il y a environ un mois

postgresql 10.5 et :

File "/home/fred/src/eo/wcs/wcs/sql.py", line 339, in f
    return func(*args, **kwargs)
File "/home/fred/src/eo/wcs/wcs/sql.py", line 592, in do_user_table
    cur.execute('ALTER TABLE %s ADD COLUMN deleted DEFAULT(FALSE)' % table_name)
psycopg2.ProgrammingError: syntax error at or near "DEFAULT" 
LINE 1: ALTER TABLE users ADD COLUMN deleted DEFAULT(FALSE)
                                             ^

#22 Mis à jour par Frédéric Péters il y a environ un mois

Migration corrigée. Est-ce qu'il y aurait un test pour tester les migrations ?

cf tests/test_sql.py, il y a des test_migration_XX_blah qui donnent une idée.

#23 Mis à jour par Benjamin Dauvergne il y a environ un mois

  • Statut changé de Solution proposée à Nouveau

Ok je vais regarder ça.

#30 Mis à jour par Frédéric Péters il y a environ un mois

Tant que la démarche n'a pas été anonymisée le compte restera.

Oui dans w.c.s. mais pas dans a2 et donc plus de lien avec jsondatastore si c'est basé sur le NameID; je ne vois vraiment pas de solution à part de mettre l'expiration des comptes à 2 ans pour tout le monde, puis 3 ans quand on trouvera un truc à faire tous les 2 ans...

Mais côté a2 il y aura eu email à l'usager, une fois, deux fois (?), pour lui dire de venir cliquer s'il ne voulait pas que le compte soit supprimé. Non ?

#31 Mis à jour par Benjamin Dauvergne il y a environ un mois

Frédéric Péters a écrit :

Mais côté a2 il y aura eu email à l'usager, une fois, deux fois (?), pour lui dire de venir cliquer s'il ne voulait pas que le compte soit supprimé. Non ?

Oui tout à fait, si c'est jugé suffisant on est bon, sauf que si les gens oublie et bien adieu les données.

#32 Mis à jour par Stéphane Laget il y a environ un mois

Peut-on envisager de gérer cela avec des attributs sur des rôles ?
Sinon, pour ce type de cas très particulier, on peut aussi envisager ne pas fermer une demande (qui reste donc "active") pendant longtemps.

#33 Mis à jour par Benjamin Dauvergne il y a environ un mois

Stéphane Laget a écrit :

Peut-on envisager de gérer cela avec des attributs sur des rôles ?

On a pas d'attribut sur les rôles, on aura un attribut sur l'OU mais c'est la même pour tous les usagers. On authentifie des usagers pas des associations; l'usager n'aura qu'à retrouver son association dans l'annuaire des associations (s'il n'a pas cliquer dans les mails de relance) et retrouvera ses données (qui sont publiques de toute façon); c'est pour cela que j'indiquais je ne sais plus quand qu'il fallait séparer dans le jsondatastore, les associations (en utilisant leur RNA comme clé dans le jsondatastore) et la liste des associations d'un utilisateur (qui utilise le NameID comme clé).

Sinon, pour ce type de cas très particulier, on peut aussi envisager ne pas fermer une demande (qui reste donc "active") pendant longtemps.

Oui, ça n'aura aucun effet, on parle des utilisateurs là pas des demandes. On doit supprimer les utilisateurs en ligne même si les demandes ne sont pas fermées.

À Grenoble on pourra peut-être mettre 2 ans d'expiration mais à Lyon ce sera 6 mois au niveau de GLC, rien de plus, donc aucune donnée liée à l'utilisateur ne pourra survivre plus longtemps (sauf à la stocker par rapport à un autre identifiant plus pérenne: identifiant métier, email, etc..).

#34 Mis à jour par Stéphane Laget il y a environ un mois

Benjamin Dauvergne a écrit :

Sinon, pour ce type de cas très particulier, on peut aussi envisager ne pas fermer une demande (qui reste donc "active") pendant longtemps.

Oui, ça n'aura aucun effet, on parle des utilisateurs là pas des demandes. On doit supprimer les utilisateurs en ligne même si les demandes ne sont pas fermées.

Je ne comprends pas.
Le sujet du ticket c'est "Supprimer les utilisateurs quand ils n'ont plus de liens avec un compte et plus de formulaires dans un statut non terminal"
Si un utilisateur a toujours des demandes en cours (non terminées, non anonymisées), on ne doit pas supprimer le compte !
Peut-être à Lyon si ça les amuse, mais ce fonctionnement ne peut pas être généralisé sur toutes les instances, cela n'a pas de sens.

À Grenoble on pourra peut-être mettre 2 ans d'expiration mais à Lyon ce sera 6 mois au niveau de GLC, rien de plus, donc aucune donnée liée à l'utilisateur ne pourra survivre plus longtemps (sauf à la stocker par rapport à un autre identifiant plus pérenne: identifiant métier, email, etc..).

Effectivement ce délai d'expiration doit clairement être un paramètre pour chaque instance.

#35 Mis à jour par Frédéric Péters il y a environ un mois

  • Sujet changé de Supprimer les utilisateurs quand ils n'ont plus de liens avec un compte et plus de formulaires dans un statut non terminal à Supprimer les utilisateurs quand ils ne sont plus liés à aucune demande

Le sujet du ticket c'est "Supprimer les utilisateurs quand ils n'ont plus de liens avec un compte et plus de formulaires dans un statut non terminal"

Oui mais dans le premier commentaire c'est changé ainsi :

Encore plus simple : « l'utilisateur n'est lié à aucun formulaire », ce qui devrait être le cas avec des "vieux" comptes et des actions d'anonymisation correctement paramétré et si n'est pas le cas, cela nous donne un argument de plus pour encourager à paramétrer correctement des délais d'anonymisation au plus court.

Je viens de modifier le sujet.

#36 Mis à jour par Pierre Cros il y a environ un mois

Donc si mon compte est lié à une demande non anonymisée, il ne risque pas d'être effacé (même si j'ai raté les demandes de confirmation - idéalement je ne devrais même pas en recevoir, mon compte étant lié à une demande) ?
C'est la seule chose qui intéresse Stef je pense (en tout cas ça marche pour les cas d'usage asso, pour lesquels l'anonymisation n'est pas nécessaire).

Pour les demandes de citoyens, on pousse effectivement pour que l'anonymisation soit faite comme il faut, ça permet la suppression des comptes inutilisés. Le fait de conserver des comptes citoyens inusités en dehors du contexte asso me semble acceptable, en tout cas tant qu'on a pas de vraie gestion des comptes personnes morales.

#37 Mis à jour par Frédéric Péters il y a environ un mois

Donc si mon compte est lié à une demande non anonymisée, il ne risque pas d'être effacé (même si j'ai raté les demandes de confirmation - idéalement je ne devrais même pas en recevoir, mon compte étant lié à une demande) ?

Ce ticket concerne w.c.s.; l'utilisateur dans w.c.s. ne sera pas supprimé; mais côté authentic, il pourra l'être, ce qu'écrit Benjamin :

On doit supprimer les utilisateurs en ligne même si les demandes ne sont pas fermées.

S'il y a des mécaniques à définir pour empêcher ça, elles doivent être discutées, mais idéalement pas dans ce ticket w.c.s. Je vais faire un message sur la liste pour reprendre tout ça.

#38 Mis à jour par Benjamin Dauvergne il y a environ un mois

Stéphane Laget a écrit :

Benjamin Dauvergne a écrit :

Sinon, pour ce type de cas très particulier, on peut aussi envisager ne pas fermer une demande (qui reste donc "active") pendant longtemps.

Oui, ça n'aura aucun effet, on parle des utilisateurs là pas des demandes. On doit supprimer les utilisateurs en ligne même si les demandes ne sont pas fermées.

Je ne comprends pas.
Le sujet du ticket c'est "Supprimer les utilisateurs quand ils n'ont plus de liens avec un compte et plus de formulaires dans un statut non terminal"
Si un utilisateur a toujours des demandes en cours (non terminées, non anonymisées), on ne doit pas supprimer le compte !
Peut-être à Lyon si ça les amuse, mais ce fonctionnement ne peut pas être généralisé sur toutes les instances, cela n'a pas de sens.

C'est sans fin en terme de dev, si l'IdP doit interroger toutes les applications de la plate-forme pour savoir si oui ou non elle considère que ce compte est inactif et depuis quand, il faut mettre une barrière quelque part. Dire on conserve les comptes 2 ans sans inactivité me paraissait bien suffisant; si au bout de 2 ans sans inactivité il y a des demandes ouvertes, et bien elles pourront toujours être traitée mais la personne ne pourra plus venir les voir en ligne (et encore, il y a le code de suivi).

#39 Mis à jour par Frédéric Péters il y a environ un mois

(discussion sur la liste)

#40 Mis à jour par Benjamin Dauvergne il y a 3 jours

Avant de merger vérifier numéro de migration avec #22651.

Formats disponibles : Atom PDF