Sindup:Procedure de downgrade
De Hegyd Doc.
(→Suppression des utilisateurs) |
(→Effets de la suppression d'un utilisateur) |
||
| Ligne 33 : | Ligne 33 : | ||
===Effets de la suppression d'un utilisateur=== | ===Effets de la suppression d'un utilisateur=== | ||
S'il s'agit d'un utilisateur "réel", son compte est flagué en supprimé ( utsDelete à la date de la suppression ). | S'il s'agit d'un utilisateur "réel", son compte est flagué en supprimé ( utsDelete à la date de la suppression ). | ||
| + | Cette seule action a pour effet de bloquer tous ses traitement automatisés et l’empêche de se connecter à l'application. | ||
| + | |||
| + | S'il s'agit d'un collaborateur ou d'un destinataire d'alerte, on supprime pour l'ensemble des adresses email concernées : | ||
| + | * les invitations à rejoindre un dossier en attente de réponse | ||
| + | * les liens entre les alertes des utilisateurs du compte en downgrade et les emails supprimés | ||
Version du 7 septembre 2011 à 13:10
Sommaire |
Procédure de downgrade
Introduction
Cela peut arriver dans différents cas de figures :
- il est arrivé à la fin de sa période d'engagement : l'ensemble de ses crédit est expiré, il ne dispose que des crédits des utilisateurs gratuits
- sa période d'engagement n'est pas révolue, mais il a eu accès à des crédits gratuits expirants avant la fin de son engagement
Dans tout les cas, dès lorsqu'on détecte un client en dépassement, on l'enregistre dans la table clientOverQuota.
Conséquences :
- aucun utilisateur ne peut se connecter à l'application. Les simple utilisateur arrivent sur un message d'erreur. L'administrateur arrive sur la procédure de downgrade.
- les alertes mail sont ignorées (on continue à les traiter mais l'envoi est intérrompu dès qu'on detecte que le client est en dépassement de quota).
Les autres procédures d'alimentation automatique ne sont pas affectées par le fait que le client soit en dépassement de quota.
Suppression des utilisateurs
Cette page liste l'ensemble des "utilisateurs" du compte client.
Elle est divisée en 3 parties :
- les utilisateurs "réels" : correspond à des vrai comptes utilisateurs rattachés au compte client.
- les "collaborateurs" : correspond à des utilisateurs non-clients (ni sur le compte en downgrade, ni sur un autre compte) qui ont accès aux dossiers de veilles partagés
- les "destinataires d'alertes" : correspond à des utilisateurs non clients ou des adresses de non-utilisateurs qui sont en copie d'alertes.
Note 1 : Si un utilisateur non client est à la fois collaborateur d'un dossier de veille et destinataire d'une alerte, il n’apparaîtra quand dans le bloc "collaborateurs" (plus important)
Note 2 : Les "collaborateurs" et "destinataires d'alertes" sont affichés tout utilisateurs confondus. Si le compte en downgrade a deux utilisateur (A et B) qui ont chacun ajouté un utilisateur non client "C" soit en alerte, soit en dossier, alors chacun de ses utilisateur possède son propre contact "C". Malgré tout, "C" ne compte que pour un crédit utilisateur (on se base sur l'adresse email, et non pas sur le nombre de contacts). Il n'apparait donc qu'une seule fois dans le listing.
Effets de la suppression d'un utilisateur
S'il s'agit d'un utilisateur "réel", son compte est flagué en supprimé ( utsDelete à la date de la suppression ). Cette seule action a pour effet de bloquer tous ses traitement automatisés et l’empêche de se connecter à l'application.
S'il s'agit d'un collaborateur ou d'un destinataire d'alerte, on supprime pour l'ensemble des adresses email concernées :
- les invitations à rejoindre un dossier en attente de réponse
- les liens entre les alertes des utilisateurs du compte en downgrade et les emails supprimés
