Projet

Général

Profil

Development #60463

poser une valeur par défaut pour clean_unused_accounts_alert/clean_unused_accounts_deletion

Ajouté par Frédéric Péters il y a plus de 2 ans. Mis à jour il y a environ 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
10 janvier 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Parce que c'est important de supprimer les comptes inutilisés et que ça ne devrait pas passer par une configuration manuelle à chaque déploiement.


Fichiers

Révisions associées

Révision c557ec4d (diff)
Ajouté par Paul Marillonnet il y a environ 2 ans

a2_rbac: provide default values for unused account thresholds (#60463)

Historique

#2

Mis à jour par Paul Marillonnet il y a plus de 2 ans

Jenkins en rade, ne trouve pas de connexion à la base, sans doute dû à la migration bullseye annoncée ce matin.
Le patch passe les tests en local, mais sans doute à faire tourner dans Jenkins quand il sera de nouveau debout, histoire de.

En attendant, on peut discuter des valeurs par défaut :
· suppression au bout d’un an d’inactivité,
· réception d’une alerte trente jours avant.

Je sais que certain·e·s CPF ont recours à des valeurs bien plus élevées, sans doute quelque chose à voir avec elles/eux.

#3

Mis à jour par Frédéric Péters il y a plus de 2 ans

Perso je serais plutôt pour intégrer ça comme valeur par défaut au niveau du champ, plutôt que via du paramétrage supplémentaire; en tout cas que le paramétrage soit visible/lisible, plutôt qu'avoir à se dire "pas de paramétrage ça veut dire que ça prend une valeur par défaut allons voir dans les settings.json et les variables SETTING et le code pour trouver quelle valeur peut bien s'appliquer".

#5

Mis à jour par Valentin Deniaud il y a environ 2 ans

Ça serait bien d'éviter la nouvelle migration en allant ajouter ce paramètre default dans la migration qui a ajouté les champs (et ça ferait un patch plus rassurant, là on pourrait avoir peur que la migration aille ajouter des valeurs aux champs qui n'en ont pas).

#6

Mis à jour par Benjamin Dauvergne il y a environ 2 ans

  • Statut changé de Solution proposée à En cours
#7

Mis à jour par Paul Marillonnet il y a environ 2 ans

Oui, en effet, c’est mieux en plaçant cela dans la migration existante.

#8

Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a environ 2 ans

J'arrive tard, mais je n'ai pas fait attention à ce ticket, je recopie ce que je viens de dire à Paul dans un autre ticket :

1 an d'inactivité c'est bien trop court, imagine : j'achète mon abonnement de stationnement en novembre 2021 et puis je le renouvelle qu'en décembre 2022, entre temps je n'ai pas fait d'autres démarches mais mon compte aura été supprimé.
La CNIL recommande 3 ans pour les services privés, je recommande ce délai.

#9

Mis à jour par Paul Marillonnet il y a environ 2 ans

Anaïs Ecuvillon a écrit :

J'arrive tard, mais je n'ai pas fait attention à ce ticket, je recopie ce que je viens de dire à Paul dans un autre ticket :

1 an d'inactivité c'est bien trop court, imagine : j'achète mon abonnement de stationnement en novembre 2021 et puis je le renouvelle qu'en décembre 2022, entre temps je n'ai pas fait d'autres démarches mais mon compte aura été supprimé.

C’est une valeur par défaut à la création de la collectivité, et qui peut être changée à tout moment. En l’état il n’y a pas de valeur par défaut et si on laisse le champ vide alors il n’y a pas de suppression du tout.
On peut imaginer mettre un an par défaut, et pour les collectivités dont les démarches sont spécifiquement de périodicité annuelle augmenter cette valeur.

La CNIL recommande 3 ans pour les services privés, je recommande ce délai.

Si on estime que mettre un délai par défaut plus restreint peut se faire sans nuire aux usagers, alors c’est encore mieux :)

#10

Mis à jour par Benjamin Dauvergne il y a environ 2 ans

  • Statut changé de Solution proposée à En cours

3 ans c'est effectivement bien long quoi qu'en pense la CNIL, 1 an ça limite les usages habituels d'une année sur l'autre dans tous les cas, je dirai 1 an et demi et de toute façon les gens reçoivent une alerte avant, ce n'est pas non plus automatique.

#11

Mis à jour par Benjamin Dauvergne il y a environ 2 ans

Benjamin Dauvergne a écrit :

3 ans c'est effectivement bien long quoi qu'en pense la CNIL, 1 an ça limite les usages habituels d'une année sur l'autre dans tous les cas, je dirai 1 an et demi et de toute façon les gens reçoivent une alerte avant, ce n'est pas non plus automatique.

Je serai pour le passer au prochain cycle et l'annoncer clairement en avance parce que ça va balancer des tonnes de mail partout, je n'ai pas l'impression que beaucoup de site aient déjà une configuration sur ce point. Ça va aussi supprimer des comptes agents manuels qui ne se connectent jamais mais créés uniquement pour qu'ils reçoivent des mails (aucune idée si cela existe ou si j'invente un faux problème); la bonne solution étant de mettre les agents dans une OU dédiée de toute façon.

#13

Mis à jour par Mikaël Ates il y a environ 2 ans

Sur base d'un projet, je penche pour 2 ans.

#16

Mis à jour par Valentin Deniaud il y a environ 2 ans

Benjamin Dauvergne a écrit :

Je serai pour le passer au prochain cycle et l'annoncer clairement en avance parce que ça va balancer des tonnes de mail partout, je n'ai pas l'impression que beaucoup de site aient déjà une configuration sur ce point.

Le patch n'a pas d'incidence sur les déploiements existants.

#19

Mis à jour par Benjamin Dauvergne il y a environ 2 ans

  • Statut changé de Solution proposée à Solution validée
  • Assigné à mis à Paul Marillonnet

Suite aux remarques de Mike, Fred et Valentin, je valide, on reste sur deux ans et on annonce rien, on pourra éventuellement forcer ça plus tard en l'annonçant là où il n'y a rien.

#20

Mis à jour par Paul Marillonnet il y a environ 2 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit c557ec4db8a854f22f71cdadd79fa7e7f43ca15b
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Mon Jan 10 17:32:19 2022 +0100

    a2_rbac: provide default values for unused account thresholds (#60463)
#21

Mis à jour par Transition automatique il y a environ 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#22

Mis à jour par Transition automatique il y a presque 2 ans

Automatic expiration

Formats disponibles : Atom PDF