SupAnn 2018 account life cycle

Hello,

one of the first demand is to manage the life cycle of an account in SupAnn. the documentation is here https://services.renater.fr/documentation/supann/supann2018/recommandations2018/personnes/alimentation

to be discussed

assigned to @MCMic

mentioned in issue #5906 (closed)

mentioned in issue argonaut/argonaut#5744

Il y a grossomodo 4 points sur lesquels FD peut implémenter la norme:

• Permettre d’éditer les deux nouveaux champs supannRessourceEtat et supannRessourceEtatDate
• Vérifier l’état contenu dans ces champs pour permettre ou non la connexion à FD
• Mettre une valeur dans ces champs lors du verrouillage/déverrouillage d’un utilisateur dans FD
• Prévenir/repousser les dates d’expirations de supannRessourceEtatDate au travers de user-reminder

La norme définit deux champs:

• supannRessourceEtat: indique l’état et éventuellement le sous-état du compte de l’utilisateur, ou de son compte mail, ou d’autres ressources spécifiques à l’établissement. Exemples: {COMPTE}A, {COMPTE}S:SupannVerrouTechnique, {MAIL}I
• supannRessourceEtatDate: même chose avec des dates de début et fin facultatives. Exemples: {COMPTE}A:::, {COMPTE}A:SupannSursis:20170912:20171212, {MAIL}A:::20180101

La norme indique qu’on peut dupliquer les valeurs dans supannRessourceEtat pour avoir la valeur avec et sans sous-état, je suis plutôt contre a priori.

Ce qui n’est pas clair:

• Doit-on dupliquer l’information entre supannRessourceEtat et supannRessourceEtatDate?
• Que faire si les deux sont remplis et incohérents?
• Quand un état a une date de fin, dans quel état passe-t-on après? Comment savoir?
• Est-ce qu’il faut purger les états passés?

Je pense que pour supannRessourceEtatDate il faudrait une interface utilisateur spécifique avec des contraintes assez fortes sur le contenu du champ.

L’idée est de forcer à ce qu’il y ai toujours un état actif, donc il ne serait possible de mettre une date de fin à un état que si on met un autre état qui démarre à cette date.

La valeur du champs serait donc une suite d’états avec une date de passage à chaque fois.

- Doit-on dupliquer l’information entre supannRessourceEtat et supannRessourceEtatDate?

non je pense pas ça va être dur a gérer, je suis pour qu'on utilise supannRessourceEtatDate

- Que faire si les deux sont remplis et incohérents?

Aucune idee a ce jour, je ne comprend pas pourquoi il y a deux champs :/

- Quand un état a une date de fin, dans quel état passe-t-on après? Comment savoir?

je pense que quand sa date de validité est passe il doit passer en SupannExpire flag I

mais ça doit être fait par user reminder ce changement d’état automatique

- Est-ce qu’il faut purger les états passés?

il ne peut exister qu'un etat par type de resource ex:

{COMPTE}
{MAIL}

je pense que cette gestion du cycle de vie devrait etre dans un onglet a part pour des questions de gestion, les gens amene a gere ca ne seront surement pas les meme que ceux qui vont gerer supann et supann est deja super charge comme onglet

added 15m of time spent at 2019-02-26

je pense que quand sa date de validité est passe il doit passer en SupannExpire flag I

Pour moi c’est pas évident du tout et les cas sont très diverses c’est pour ça que je préfèrerai forcer une suite d’états cohérent pour éviter ce cas de figure.

mais ça doit être fait par user reminder ce changement d’état automatique

C’est pas le rôle de user-reminder de faire des changements d’état (sauf quand l’utilisateur clique sur le lien).

• Est-ce qu’il faut purger les états passés?

il ne peut exister qu'un etat par type de resource ex:

{COMPTE} {MAIL}

Je ne comprends pas pourquoi tu dis ça, tu as lu ça où? Pour moi il ne peut y avoir qu’un seul état actif mais il peut y avoir plusieurs états avec des dates différentes sinon ça sert à rien de mettre des dates.

je pense que cette gestion du cycle de vie devrait etre dans un onglet a part pour des questions de gestion, les gens amene a gere ca ne seront surement pas les meme que ceux qui vont gerer supann et supann est deja super charge comme onglet

Oui ça me parait bien dans un onglet séparé.

Pour clarifier ma proposition #5907 (comment 61851) , ça donnerait au champ des valeurs comme:

{COMPTE}I:SupannPreCree::2019-03-01
{COMPTE}A:SupannAnticipe:2019-03-01:2019-03-15
{COMPTE}A::2019-03-15:2019-06-01
{COMPTE}A:SupannSursis:2019-06-01:2019-06-31
{COMPTE}I:SupannExpire:2019-06-31:2019-07-15
{COMPTE}I:SupannSupprCompte:2019-07-15:

bonjour @MCMic,

ce que je veux dire c'est qu'on ne peut avoir qu'un seul état par label a un instant donne exemple.

{COMPTE}I:SupannPreCree::2019-03-01
{MAIL}I:SupannPreCree::2019-03-01

le {COMPTE} et le {MAIL} sont indépendants, cela signifie que dans certains état, leur état et date peuvent être différents. la raison en est que souvent le compte est désactive avant la mailbox. ou qu'on a suspendu la mailbox pour des soucis de sécurité mais pas le compte ou l'inverse ...

{COMPTE}I:SupannExpire:2019-06-31:2019-07-15
{MAIL}A::2019-03-15:2019-08-01

added 10m of time spent at 2019-02-28

added 2h of time spent at 2019-02-28

Après consultation du groupe SupAnn:

• Une seule valeur par étiquette est autorisée dans les champs supannRessourceEtat et supannRessourceEtatDate
• Dans supannRessourceEtatDate la date de début doit être passée et la date de fin à venir, sinon la valeur est invalide (ce champ n’est pas prévu pour stocker un historique ou une valeur prévisionnelle)
• Les dates éventuellement présentes dans le champ concerne bien l’état courant indiqué dans le champ, pas le compte lui-même (la date de fin indique la fin de l’état courant, pas nécessairement la fin de validité du compte)

Donc en première étape on ajoutera un onglet qui permet de mettre des valeurs dans supannRessourceEtatDate, en vérifiant qu’elle soit valide (une seule valeur par étiquette, date de début passée, date de fin futur).

Le champ supannRessourceEtat sera silencieusement rempli avec le même état.

En deuxième étape, il faudra voir comment faire interagir cette notion d’état avec notre fonctionnalité de verrouillage, notre dashboard utilisateurs, notre login par formulaire…

Il nous faudra probablement implémenter un démon/script de maintient des valeurs d’état, à nous de voir sa complexité en fonction des besoins client.

added 2h of time spent at 2019-03-04

hello @MCMic,

les deux étiquettes de base a géré sont {COMPTE} et {MAIL}, les étiquettes devraient pouvoir être configures dans le backend de configuration de FusionDirectory sur un tab SupAnn.

added 1h 30m of time spent at 2019-03-04

mentioned in commit a59e49c2

mentioned in commit 1745e82c