Sindup:Procedure de downgrade
De Hegyd Doc.
(→Introduction) |
(→Introduction) |
||
| Ligne 29 : | Ligne 29 : | ||
'''A ce stade, aucune donnée n'est supprimée, ou flaguée supprimée.''' | '''A ce stade, aucune donnée n'est supprimée, ou flaguée supprimée.''' | ||
| + | |||
| + | Voir l'algorithme d'ajustement du statut client en fonction des crédits [[Sindup:Ajustement_statut_client]] | ||
= Etapes du downgrade = | = Etapes du downgrade = | ||
Version du 26 septembre 2011 à 15:20
Sommaire |
Procédure de downgrade
Introduction
Le downgrade est un assistant auquel accedent les clients qui consomment plus de crédits qu'ils n'en disposent.
Le but est d'amener le client à renouveller/upgrader sa commande, ou à supprimer des données pour revenir dans les limites de son quota.
Détection des comptes en dépassement
La détection des comptes en dépassement se fait via un script qui vérifie chaque nuit l'ensemble des comptes clients non supprimés.
Deux cas de figures peuvent conduire un compte à être en dépassement de quota :
- le client 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
- la période d'engagement du client n'est pas révolue, mais il a eu accès à des crédits gratuits expirants avant la fin de son engagement.
Conséquences d'un compte en dépassement
- 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.
Détection des comptes expirés
De la même manière que l'on vérifie les clients en dépassement de quota, on vérifie chaque nuit les clients expirés.
Un client n'ayant plus aucun crédit valide pendant 60 jours (fin de commande, fin de période de démonstration,...), est en client expiré.
Conséquences d'un compte en dépassement
- 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).
- l'ensemble des procédure d'alimentation automatique (filterLive, alimentation via filtres, pages d'avis, recherches réseaux sociaux) sont interrompues.
A ce stade, aucune donnée n'est supprimée, ou flaguée supprimée.
Voir l'algorithme d'ajustement du statut client en fonction des crédits Sindup:Ajustement_statut_client
Etapes du downgrade
Chaque crédit quantifiable à son propre écran de downgrade (si le client est en dépassement pour ce type de crédit). Il peut y avoir au maximum 9 écrans :
- suppression des utilisateurs
- suppression des dossiers intelligents
- suppression des filtres alimentant les dossiers
- suppression des alertes
- suppression des flux réseaux sociaux
- suppression des pages d'avis
- suppression des flux privés
- suppression des sites sous surveillance HTML
- suppression des sites catalogues
Etape de 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).
L'ensemble des elements dependants directement de l'utilisateur et pouvant être flagués avec un utsDelete le sont également. (Ex : dossiers de veilles, alertes, sites etc.).
Voir Sindup:Suppressions en cascade
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
- les liens entre les alertes des utilisateurs du compte en downgrade et les emails supprimés
Etape de suppression des dossiers intelligents
Cette page liste l'ensemble des "dossiers intelligents" du compte client.
Les dossiers sont affichés par utilisateur. Le nom du dossier correspond à son chemin complet dans l'arborescence.
La sélection d'un dossier parent sélectionne l'ensemble des dossiers enfants.
Effets de la suppression d'un dossier intelligent
Les dossiers selectionnés sont flagués en supprimé (utsDelete à la date de la suppression). Si le dossier contient des sous-dossiers, l'ensemble des sous dossiers est flagué en supprimé également.
