Équipes et utilisateurs

Une équipe est une responsabilité, pas un dossier. Elle a ses propres catégories, ses propres délais et ses propres membres. Un client en voit exactement une. Tout le reste revient à savoir qui possède quel compte et ce que ce compte a le droit de faire.

1

Créer et configurer des équipes

Les équipes se trouvent sous « Settings → Teams ». La liste est à gauche, les réglages de l'équipe sur laquelle tu as cliqué sont à droite. Le nombre derrière le nom est le nombre de ses membres.

Une nouvelle équipe reçoit son nom dans le champ « Team name ». En dessous, « Copy categories from » permet de choisir une équipe existante, pour que la nouvelle équipe démarre avec les mêmes catégories principales et sous-catégories. « Create team » la crée.

La première équipe est celle que tes clients voient. Chaque équipe suivante est une équipe spécialisée derrière elle. Demander à une personne qui signale de choisir elle-même le bon département est trop lui demander : elle dépose auprès de la première équipe, et c'est transmis à partir de là.

Tu peux changer cela à tout moment. La carte « Customer permissions » décide, par équipe, ce que les clients peuvent y faire. Elle a deux interrupteurs : « Can create new tickets and see their own tickets » et « Can see their own tickets of this team in the dashboard and in reports ». Dès que l'un d'eux est activé, les clients voient l'équipe. Ce n'est qu'avec les deux désactivés que l'équipe n'apparaît pas du tout pour un client.

La carte « Agent Permissions » s'applique aux agents de cette équipe. Elle a trois interrupteurs : gérer les tickets, gérer les catégories et voir les rapports de cette équipe. Sans le premier, un agent ne peut ni créer, ni modifier, ni commenter des tickets dans cette équipe, ni envoyer de pièces jointes. Sans le deuxième, l'entrée des catégories de l'équipe disparaît de sa barre latérale. Sans le troisième, les rapports laissent cette équipe de côté. Chaque changement est consigné dans l'« Audit log » de l'équipe.

La carte « Agents » contient les membres. Malgré le titre, les clients de l'équipe s'y trouvent également. Le sélecteur au-dessus et « Add Agent » ajoutent quelqu'un, « Remove » le retire. Celui qui est ajouté ou retiré doit se déconnecter et se reconnecter une fois.

« Default e-mail language » est la langue dans laquelle cette équipe écrit. Elle s'applique quand une règle de messagerie choisit « Team default language ».

L'interrupteur « Active » met une équipe hors service. Elle disparaît de la barre latérale et de tous les sélecteurs. Elle n'est pas supprimée pour autant.

« Delete » ne supprime une équipe que si aucun ticket n'est encore ouvert. Sinon, le système nomme la raison et ne fait rien.

La carte « Audit log » consigne chaque changement de l'équipe, avec le nom et l'heure.

Basic fonctionne avec une seule équipe. Professional n'a pas de limite.

La page « Teams » avec la liste des deux équipes à gauche et les réglages du Helpdesk à droite.
Les cadres rouges entourent les deux équipes. Cliquer sur l'une change ce qui s'affiche à droite. Le nombre au bord est le nombre de membres.Ouvrir l'image en taille réelle
Le champ « Team name » avec un nom saisi, en dessous « Copy categories from » et le bouton « Create team ».
Saisis le nom, reprends éventuellement les catégories d'une équipe existante, puis « Create team ».Ouvrir l'image en taille réelle
Les cartes « Customer permissions » et « Agent Permissions » avec leurs interrupteurs.
Les cadres rouges entourent les deux titres. Ces interrupteurs ne s'appliquent qu'à cette seule équipe.Ouvrir l'image en taille réelle
La carte « Agents » avec le sélecteur, le bouton « Add Agent » et les membres en dessous.
Le cadre rouge entoure « Add Agent ». La pastille à côté de chaque nom est le rôle, et la carte contient aussi les clients de l'équipe.Ouvrir l'image en taille réelle
La carte « Audit log » avec ses entrées, chacune avec la modification, le nom et l'heure.
Le cadre rouge entoure le titre. Chaque ligne nomme le changement, qui l'a fait et quand.Ouvrir l'image en taille réelle
2

Créer des administrateurs et des agents

Les comptes se trouvent sous « User management ». La liste montre le nom et le nom de connexion, l'adresse e-mail, l'équipe avec le département en dessous, et le rôle.

« New user » ouvre le formulaire. Le prénom, le nom, le nom de connexion et l'adresse e-mail sont obligatoires. À cela s'ajoute un mot de passe. Avec Professional, tu peux cocher à la place la case « Send login details by e-mail ».

Avec cette case, tu ne définis aucun mot de passe. Le nouvel utilisateur reçoit un message avec son nom de connexion et un lien à durée limitée, et définit lui-même son mot de passe. Le système n'envoie jamais de mots de passe.

Le rôle décide de tout le reste. « Admin » et « Agent » sont tous deux du personnel et comptent dans le même quota. Un administrateur peut faire plus au départ. Presque chaque autorisation individuelle peut être modifiée ; les exceptions figurent sur la carte « Les rôles et le concept d'autorisations ». Seul un administrateur peut donner ou retirer le rôle « Admin ». Cela vaut aussi pour son propre compte. « Edit user » ne change que l'équipe affichée dans le formulaire. Les équipes auxquelles la personne a été ajoutée avec « Add Agent » restent telles quelles.

Basic est livré avec deux places de personnel. La répartition dépend de toi : un administrateur et un agent, ou deux administrateurs. Les clients ne comptent pas, ils sont illimités dans les deux éditions.

Quand quelqu'un part, clique sur le symbole d'archive dans sa ligne. Le compte est verrouillé, la personne ne peut donc plus se connecter.

Un compte verrouillé passe dans la vue « Archived » et y porte la pastille « locked ». Il n'est plus visible dans la vue « Active ».

Un compte verrouillé n'occupe plus de place de personnel et n'apparaît dans aucun sélecteur « Assign to ». Les tickets déjà attribués gardent leur agent et le nom de leur agent.

Dans la vue « Archived », le même bouton s'appelle « Restore » et libère de nouveau le compte. Dans Basic, cela demande encore une place libre.

Le symbole de la clé réinitialise un mot de passe. Le bouclier barré réinitialise la connexion à deux facteurs. Le nouveau mot de passe est alors affiché une seule fois à l'écran. Il n'est envoyé nulle part.

Réinitialiser le mot de passe ou la connexion à deux facteurs ne lève que le court verrouillage après des tentatives ratées. Un compte archivé reste verrouillé. Il ne reçoit ni invitation ni courrier de réinitialisation, et seul « Restore » le fait revenir.

L’archivage peut être annulé à tout moment. Si quelqu’un est parti pour de bon, supprime aussi le compte avec le symbole de corbeille « Delete account ». Le délai jusqu’à l’anonymisation automatique ne court qu’à partir de la suppression.

Plus à ce sujet dans la carte : Anonymiser des personnes

La page « User management » avec tous les comptes, leur rôle et les actions de chaque ligne.
Les cadres rouges entourent « New user » et le passage entre comptes ouverts et comptes verrouillés. Le bouton montre laquelle des deux vues est ouverte.Ouvrir l'image en taille réelle
La boîte de dialogue « Create new user » avec les noms, le nom d'utilisateur et l'e-mail remplis, et les sélecteurs d'équipe, de département, de poste, de site et de rôle.
Les cadres rouges entourent le rôle et l'invitation. Le rôle est le seul sélecteur qui doit être rempli.Ouvrir l'image en taille réelle
La même boîte de dialogue avec la case cochée : le champ du mot de passe est désactivé et indique que l'utilisateur le définit par le lien.
Avec la case cochée, l'astérisque du champ de mot de passe disparaît. Le champ lui-même indique qui définit le mot de passe.Ouvrir l'image en taille réelle
La vue « Archived » avec un compte verrouillé, la pastille « locked » et l'icône de restauration en fin de ligne.
Les cadres rouges entourent la pastille et le chemin du retour. Les deux n'existent que dans cette vue.Ouvrir l'image en taille réelle
3

Clients : les comptes des personnes qui signalent

Les clients sont illimités dans Basic comme dans Professional. Ils n'occupent aucune place de personnel.

Un compte client naît de trois façons. Tu le crées toi-même sous « User management » ; avec Professional, tu peux en même temps inviter la personne par courrier électronique. La deuxième voie est l'inscription libre. La troisième est la première connexion par SSO ou par un annuaire, qui crée le compte toute seule.

L'interrupteur correspondant se trouve sous « Settings → Security » dans la carte « Self-registration ». Il est désactivé au départ. Une fois activé, un lien « Register » apparaît sur la page de connexion.

Celui qui s'inscrit lui-même reçoit toujours le rôle « Customer ». Aucun autre rôle ne peut être attribué par cette voie.

Avec Professional, un client issu de l'inscription libre reçoit un deuxième e-mail après celui de bienvenue. Avec le lien qu'il contient, il confirme son adresse. Jusque-là, son compte porte la mention « not confirmed » dans la liste.

Tu peux aussi confirmer une adresse toi-même. Dans Basic, c'est la seule voie, car Basic n'envoie aucun courrier électronique. La ligne du compte affiche alors un bouton avec une icône d'enveloppe : « Mark email as confirmed ». Ne le fais que si tu sais que l'adresse appartient à la personne.

Pour un helpdesk interne, mieux vaut ne pas toucher à cet interrupteur. Sinon, quiconque connaît l'adresse crée un compte.

Un client ne voit que ses propres dossiers. Ce sont les tickets qu'il a créés lui-même. S'y ajoutent les tickets qu'un agent ou un e-mail a créés pour son adresse confirmée. Un ticket qu'un autre client crée avec son adresse lui reste caché. Si deux comptes ont la même adresse, les deux voient ces tickets.

Si son adresse n'est pas encore confirmée, un avis apparaît au-dessus de sa liste de tickets. Avec « Send confirmation email », il redemande le lien. L'avis n'apparaît que si le système peut envoyer du courrier électronique.

Sa barre latérale est courte : ses tickets, un nouveau ticket, la base de connaissances. Il ne voit jamais aucun paramètre. Si l'interrupteur de l'équipe « Can see their own tickets of this team in the dashboard and in reports » est activé, sa barre latérale contient aussi le tableau de bord et les rapports.

Ce qu'il a le droit de faire dans une équipe se règle sur l'équipe. Ce n'est qu'avec les deux interrupteurs clients désactivés que cette équipe n'existe pas pour lui.

La carte « Self-registration » avec l'interrupteur et la remarque en dessous.
Le cadre rouge entoure l'interrupteur. Le texte à côté dit ce qu'il fait et ce qui se passe sans envoi de courrier électronique.Ouvrir l'image en taille réelle
Le même système, connecté en tant que cliente : une barre latérale courte et une liste de tickets qui ne contient que ses propres dossiers.
La colonne « User » contient le même nom à chaque ligne. Une cliente ne voit rien qui ne soit à elle, et les paramètres manquent dans la barre latérale.Ouvrir l'image en taille réelle
4

Export des données d’une personne

Avant de commencer : Tu as besoin de l’autorisation « Data export (data subject request) ». Par défaut, seuls les administrateurs l’ont.

Une personne peut te demander quelles données tu conserves sur elle. L’export de données les rassemble toutes dans un fichier ZIP.

Tu le lances sous « User management ». Chaque ligne a un symbole de fichier avec une flèche et l’indication « Export personal data ». Il ouvre l’export de ce compte.

Certaines personnes n’ont pas de compte. Elles t’ont seulement écrit, ou un agent a créé un ticket avec leur adresse. Pour elles, il y a « Export by e-mail address » en haut de la page. Saisis-y l’adresse et clique sur « Search ». La recherche fonctionne avec un compte ou une adresse, jamais avec un nom.

Une recherche par adresse trouve moins qu’une recherche par le compte. Elle ne trouve que les endroits où l’adresse elle-même est enregistrée, par exemple comme demandeur d’un ticket ou comme expéditeur d’un e-mail. Une recherche par le compte trouve en plus tout ce qui est rattaché au compte. Si l’adresse appartient à un compte, la boîte de dialogue le dit et propose « Use this account ». Ensuite, elle affiche le nom de la personne et l’adresse e-mail du compte.

Avant que tu ne télécharges quoi que ce soit, la boîte de dialogue montre ce qu’elle a trouvé, compté par domaine. Les domaines sont par exemple les tickets, les entrées de temps, les enquêtes de satisfaction et le journal de sécurité. Si elle ne trouve rien, elle affiche « No data found for this person. » et ne propose aucun téléchargement. Si l’adresse appartient à un compte et n’a pas de résultats propres, la boîte de dialogue n’affiche aucun résultat et ne propose aucun téléchargement. Elle affiche l’encadré avec « Use this account ». Les administrateurs voient en plus la zone « Anonymize » en dessous. La carte « Anonymiser des personnes » l’explique.

« Download » crée le fichier ZIP. Il contient un fichier JSON par domaine, pour que les données soient lisibles par une machine. Les fichiers de toutes les pièces jointes trouvées l’accompagnent. « overview.html » présente le contenu principal sous une forme lisible. Chaque ticket y indique pourquoi il est inclus (« Why this ticket is included »). « README.txt » s’adresse à la personne et explique ce que contient le fichier.

Un ticket qui concerne la personne est repris en entier. Cela comprend les commentaires et les modifications d’autres personnes. Les notes internes sont également incluses et marquées comme internes. Si la personne a répondu par e-mail au ticket de quelqu’un d’autre, ce ticket porte la marque « Replied by e-mail to someone else’s ticket ». Un ticket sur lequel la personne a fait la dernière modification est également repris. Sa ligne « Why this ticket is included » indique alors « Last person to change the ticket ».

Vérifie donc l’export avant de le transmettre. Masque les données d’autres personnes là où c’est nécessaire. La boîte de dialogue te le rappelle. Le « README.txt » ne contient pas cette remarque, car il est destiné à la personne.

Les tickets déplacés dans une archive ne sont pas parcourus. Vérifie tes archives séparément. La boîte de dialogue te le rappelle aussi.

Les mots de passe et les clés de la connexion à deux facteurs ne font pas partie de l’export.

Chaque téléchargement est enregistré : qui l’a lancé, pour quelle personne et quand. L’enregistrement ne contient rien du contenu de l’export. La recherche qui précède n’est pas enregistrée.

Un agent qui reçoit l’autorisation a aussi besoin de « Users: manage accounts ». Sans elle, il n’atteint pas la page « User management ». L’autorisation ne peut jamais être donnée au rôle « Customer ».

La zone « Survey consents and unsubscribes » contient chaque consentement et chaque désabonnement pour l'enquête de satisfaction, avec la date, le canal et le ticket. « overview.html » montre l'historique complet dans une section à part. Si la personne a été anonymisée après un désabonnement, l'export par son adresse trouve le désabonnement restant. La colonne « E-mail address » indique alors « Anonymized (address removed) ».

Plus à ce sujet dans la carte : Anonymiser des personnes

La page « User management » avec le bouton « Export by e-mail address » en haut et le symbole de fichier avec une flèche dans chaque ligne.
Les cadres rouges entourent « Export by e-mail address » et le symbole dans la ligne de Julia Becker. Les deux ouvrent la même boîte de dialogue.Ouvrir l'image en taille réelle
La boîte de dialogue « Export personal data » pour Julia Becker avec son adresse e-mail sous le nom, la liste des résultats par domaine, les deux remarques sur la vérification et les archives, la zone « Anonymize » et le bouton « Download ».
Les cadres rouges entourent la liste des résultats et « Download ». La liste ne nomme que les domaines où quelque chose a été trouvé.Ouvrir l'image en taille réelle
La même boîte de dialogue après une recherche par adresse : elle nomme le compte auquel l’adresse appartient et propose « Use this account ».
Le cadre rouge entoure « Use this account ». Avec la seule adresse, la recherche ne trouve rien ici. C’est pourquoi la boîte de dialogue n’affiche aucun résultat ni « Download ». L’export du compte trouve les tickets de Julia Becker. Seuls les administrateurs voient la zone « Anonymize » en dessous.Ouvrir l'image en taille réelle
5

Anonymiser des personnes

Avant de commencer : Seul un administrateur peut anonymiser une personne. Une anonymisation ne peut pas être annulée.

Certaines données ne doivent pas rester pour toujours. Quand quelqu’un quitte ton entreprise ou qu’une personne demande l’effacement de ses données, tu l’anonymises. Le nom et l’adresse e-mail sont alors remplacés par une valeur de substitution comme « Anonymized user 3 ». Les tickets restent. Les rapports, les délais, les saisies de temps et les chiffres de satisfaction continuent de compter.

Chaque personne reçoit son propre numéro. Deux entrées avec le même numéro viennent de la même personne. L’adresse e-mail devient « anonymized-3@anonymized.invalid ». Aucun e-mail ne peut être remis à une telle adresse, c’est pourquoi le système l’ignore lors de l’envoi. La valeur de substitution est enregistrée en anglais et reste en anglais dans toutes les langues.

Il y a deux voies. La voie automatique anonymise les comptes supprimés après un nombre de mois défini. La voie immédiate anonymise une seule personne tout de suite, par exemple après une demande d’effacement.

La voie automatique se trouve sous « Settings → Security », dans la carte « Data protection ». L’interrupteur « Anonymize deleted users automatically » est désactivé par défaut. À côté de « after », tu saisis le nombre de mois. De 1 à 120 sont autorisés, la valeur par défaut est 36. « Save » enregistre un nombre modifié.

Le délai court à partir du jour où un compte a été supprimé. Le système vérifie toutes les dix minutes si une exécution est due. Elle a lieu une fois par jour, lors de la première vérification après 03:00 dans le fuseau horaire défini sous « Settings → General Settings ». Chaque compte supprimé dont le délai est écoulé est anonymisé lors de cette exécution.

Quand tu actives l’interrupteur, une fenêtre s’ouvre d’abord. Elle liste les utilisateurs supprimés que la prochaine exécution anonymisera, chacun avec le jour de sa suppression. Tape ANONYMIZE dans le champ et clique sur « Confirm ». C’est seulement alors que l’interrupteur est activé. S’il est déjà plus de 03:00 dans ce fuseau horaire, la première exécution suit dans une dizaine de minutes.

La même fenêtre apparaît quand tu raccourcis le nombre de mois alors que l’interrupteur est activé. La désactivation ne demande aucune confirmation.

Le délai ne commence que lorsqu’un compte est supprimé. L’archivage ne suffit pas. Un compte archivé est seulement verrouillé et peut revenir à tout moment, par exemple après un congé parental. Pour supprimer un compte, clique sur le symbole de corbeille « Delete account » dans sa ligne sous « User management ».

Avant que quoi que ce soit ne se passe, une fenêtre indique ce qui suit. Si l’anonymisation automatique est activée, elle indique le nombre de mois. Un compte supprimé apparaît dans la vue « Archived » avec le badge « Deleted ». Le symbole « Restore account » le fait revenir. Pour les administrateurs et les agents, Basic a besoin pour cela d’une place libre. Si le compte est à nouveau supprimé plus tard, le délai recommence.

Ton propre compte n’a pas de symbole de corbeille. Seul un administrateur peut supprimer ou archiver un compte administrateur. Le dernier administrateur actif ne peut être ni supprimé ni archivé.

Quand quelqu’un est parti pour de bon, supprime donc le compte au lieu de seulement l’archiver. Un compte archivé depuis plus d’un an affiche un symbole de calendrier dans sa ligne. Son info-bulle te rappelle de supprimer le compte.

La voie immédiate se trouve dans la boîte de dialogue de l’export de données, dans la zone « Anonymize » sous les résultats. Tu ouvres la boîte de dialogue depuis la ligne d’un compte, ou avec « Export by e-mail address » pour une personne sans compte.

Si l’adresse appartient à un compte, clique d’abord sur « Use this account ». C’est seulement ainsi que le compte lui-même est anonymisé. Une exécution par l’adresse seule remplace l’adresse là où elle est enregistrée et laisse le compte tel quel.

Tape ANONYMIZE dans le champ et clique sur « Anonymize ». Un compte actif est d’abord supprimé, puis anonymisé. Ton propre compte ne peut pas être anonymisé. Le dernier administrateur actif non plus.

Ensuite, la ligne porte le badge « Anonymized ». Un tel compte ne peut plus être modifié, restauré ni réactivé. Seul l’export de données reste. Tu peux relancer l’anonymisation. Le numéro reste le même, et les données restaurées depuis sont prises en compte aussi.

La case « Also clear the content of tickets this person requested » va plus loin. Le nombre entre parenthèses est le nombre de ces tickets. Leurs textes sont vidés et leurs pièces jointes supprimées. Les tickets d’autres personnes dans lesquels la personne a seulement répondu sont seulement anonymisés.

Vérifie d’abord tes obligations de conservation. En Allemagne, par exemple, les lettres commerciales doivent être conservées six ans. La boîte de dialogue te le rappelle. La voie automatique ne fait qu’anonymiser. Elle ne vide jamais de contenu.

Si un fichier n’a pas pu être supprimé du serveur, la boîte de dialogue indique combien. L’exécution compte quand même comme terminée. Le système ne réessaie pas de lui-même.

Chaque exécution est enregistrée avec son heure, le numéro de la valeur de substitution et ce qui a été modifié. Pour la voie immédiate, l’enregistrement indique aussi qui l’a lancée. Il ne contient ni le nom ni l’adresse e-mail de la personne.

Anonymiser nécessite l’autorisation « Anonymize people ». Par défaut, seuls les administrateurs l’ont. Seul un administrateur peut l’utiliser. Elle ne peut jamais être donnée au rôle « Customer ». La boîte de dialogue de l’export de données nécessite en plus « Data export (data subject request) ».

Plus à ce sujet dans la carte : Export des données d’une personne, Délais de conservation

La carte « Data protection » avec l’interrupteur désactivé, le champ des mois, « Save » et le lien « Download list of anonymizations ».
Les cadres rouges sont sur l’interrupteur et sur le nombre de mois. L’interrupteur est désactivé, comme après chaque mise à jour.Ouvrir l'image en taille réelle
La fenêtre « Who will be anonymized » avec un utilisateur supprimé et la date de suppression, en dessous le champ avec ANONYMIZE et le bouton « Confirm ».
Les cadres rouges sont sur la liste et sur « Confirm ». Oliver Grant a été supprimé il y a plus de 36 mois. La première exécution l’anonymiserait.Ouvrir l'image en taille réelle
La fenêtre « Delete account » pour Amir Khan. Le texte indique ce qui suit et les 36 mois jusqu’à l’anonymisation.
Le cadre rouge est sur « Delete account ». L’anonymisation automatique est activée ici. C’est pourquoi la fenêtre indique le nombre de mois.Ouvrir l'image en taille réelle
La vue « Archived » avec le compte supprimé d’Oliver Grant, le badge « Deleted » et le symbole pour le restaurer.
Les cadres rouges sont sur le badge « Deleted » et sur « Restore account ». Jusqu’à l’anonymisation, le compte peut être récupéré.Ouvrir l'image en taille réelle
La boîte de dialogue « Export personal data » pour Tomas Novak. Sous les résultats se trouve la zone « Anonymize » avec la case cochée, ANONYMIZE saisi et le bouton « Anonymize ».
Les cadres rouges sont sur la case et sur « Anonymize ». Tomas Novak a demandé quatre tickets. Leur contenu serait vidé aussi.Ouvrir l'image en taille réelle
La zone « Anonymize » après l’exécution : en haut « Already anonymized as Anonymized user 2 », en bas le message « Done ».
Le cadre rouge est sur le message avec le numéro de la valeur de substitution. La zone permet une nouvelle exécution.Ouvrir l'image en taille réelle
La vue « Archived » avec des comptes anonymisés. Chaque ligne porte un nom de substitution, l’adresse de substitution et le badge « Anonymized ».
Le cadre rouge est sur le badge « Anonymized ». Un compte anonymisé n’a plus aucune action, sauf l’export de données.Ouvrir l'image en taille réelle

Le compte

Les tableaux suivants nomment chaque endroit où le système enregistre une personne, et ce que l’anonymisation y fait. Tu peux t’en servir pour décrire comment ton entreprise efface les données personnelles.

DonnéesCe qui se passe
Prénom et nom« Anonymized user » et le numéro
Adresse e-mail et identifiant de connexionl’adresse de substitution
Numéro de téléphoneretiré
Service, poste et siteretiré
Langue, affichage clair ou sombre, disponibilitéremis à la valeur par défaut
Mot de passe et liste des mots de passe précédentssupprimé
Clés de la connexion à deux facteurs et le lien avec un compte chez un fournisseur de connexion (SSO)supprimé
Événements de connexion dans le journal de sécuritésupprimés. Les actions d’administration de la personne dans le journal de sécurité sont conservées. Son nom y est remplacé par l’espace réservé.
Photo de profilsupprimé
Rôle et appartenance aux équipesretirés. La liste des utilisateurs affiche ensuite le rôle « Customer ».
Choix personnel des colonnes de la liste des ticketsretiré
Un chronomètre de la saisie du temps en courssupprimé
Le compte lui-mêmereste, supprimé et verrouillé pour de bon. Les tickets, les commentaires et les saisies de temps continuent de pointer vers lui. C’est pourquoi les rapports continuent de compter.
Indicateurs oui/non pour l’adresse e-mail confirmée, le téléphone confirmé et la connexion à deux facteurs, le réglage oui/non de la liste des tickets, le compteur d’échecs de connexion, la date du dernier changement de mot de passe et celle de la désactivationrestent. Ils ne contiennent aucune valeur de la personne, seulement oui ou non, des nombres et des dates. L’adresse, le numéro, le mot de passe et les clés eux-mêmes sont remplacés ou supprimés.
La mention, sur un ticket, de qui l’a modifié en derniersupprimée. Le ticket ne nomme alors plus personne comme dernière personne à l’avoir modifié.

Copies du nom

À certains endroits, le système enregistre le nom une seconde fois. Ainsi, une entrée montre encore qui l’a faite après une modification. Ces copies sont remplacées aussi.

EndroitCe qui se passe
Qui a fait une modification dans l’historique du ticketnom de substitution
Nom sur les saisies de tempsnom de substitution
Qui a modifié un article de la base de connaissancesnom de substitution
Entrées dans le « Audit log » d’une équipe, y compris « Added user … » et « Removed user … »nom de substitution
Nom du demandeur sur les tickets que la personne a demandésnom de substitution. Le numéro de téléphone du demandeur est retiré.
Anciennes et nouvelles valeurs dans l’historique du ticket : nom, adresse et téléphone du demandeur, observateurs, attributionvaleur de substitution ou retiré. Cela vaut dans les tickets de la personne et dans les tickets dont elle était auparavant la demandeuse.

Adresses e-mail

Partout où une adresse de la personne est enregistrée comme champ à part entière, elle devient l’adresse de substitution. Les majuscules et minuscules n’ont pas d’importance.

EndroitCe qui se passe
Adresse du demandeur sur les ticketsadresse de substitution
Destinataire des enquêtes de satisfactionadresse de substitution
Adresse d’un approbateur, sur les approbations et dans les demandes avec tâchesadresse de substitution
Expéditeur des e-mails entrantsadresse de substitution
Adresse de destinataire fixe dans les modèles de réponseadresse de substitution
Note interne indiquant qu’une règle de messagerie a déjà traité un e-mailadresse de substitution
Adresse dans l’enregistrement des exports de données précédentsadresse de substitution. L’enregistrement lui-même reste comme preuve. Un export de données ultérieur pour cette adresse n’enregistre lui aussi que la valeur de substitution.
Suggestions pour les informations sur le demandeur lors de la création d’un ticketsupprimées si elles portent l’adresse
Entrée sur la liste de blocage des e-mailsreste. Sinon, le spam de cette adresse passerait de nouveau après la suppression.
Consentements et désabonnements pour l'enquête de satisfactionsupprimés. Si la dernière entrée était un désabonnement, elle reste sous la forme d'une entrée sans adresse. La liste « Survey consents and unsubscribes » l'affiche comme « anonymized ». Tant que la personne ne redonne pas son consentement ou ne se réabonne pas, aucune enquête n'est envoyée à l'adresse. Si la clé d'anonymisation n'est plus lisible ou a été écartée, cette entrée n'a plus d'effet.

Adresses dans le texte

Dans les textes, l’anonymisation ne remplace que les adresses e-mail de la personne. Cela se fait dans les tickets qui concernent la personne. Ce sont les mêmes tickets que ceux que trouve l’export de données.

TexteCe qui se passe
Description du ticketadresses remplacées
Commentaires, y compris le texte des e-mails entrantsadresses remplacées
Objet des e-mails entrantsadresses remplacées
Notes sur les saisies de tempsadresses remplacées
Commentaire dans une enquête de satisfactionadresses remplacées
Anciennes et nouvelles valeurs dans l’historique du ticketadresses remplacées
Titre et texte des articles de la base de connaissances, y compris dans leur historiqueadresses remplacées, dans tous les articles

Vider le contenu des tickets demandés

Avec la case « Also clear the content of tickets this person requested », ces tickets perdent leur contenu. Ce dont les rapports et les délais ont besoin reste.

Partie du ticketCe qui se passe
Numéro, dates, statut, équipe, catégorie, priorité, attribution et délaisrestent
Titredevient « Content removed »
Descriptionvidé
Tous les commentaires, y compris les réponses des agentstexte vidé. Le commentaire lui-même reste, pour que la première réponse et les délais restent justes.
Objet des e-mails entrantsvidé
Valeurs des champs personnaliséssupprimé
Note de relance et lieuvidé
Historique du ticketLe type de chaque modification reste. Les valeurs sont vidées, sauf pour le statut, la priorité, la catégorie, la sous-catégorie, le canal, l’équipe, l’escalade et l’attribution. Les rapports en ont besoin.
Enquête de satisfactionLa note reste, le commentaire est vidé.
Saisies de tempsLes minutes saisies restent, la note est vidée.
Pièces jointessupprimées, l’entrée et le fichier

Limites

Les noms dans le texte libre restent, par exemple « Cordialement, Max » à la fin d’un e-mail. Les numéros de téléphone dans le texte libre restent aussi. Aucun des deux ne peut être reconnu de façon fiable. Pour les tickets d’un client, il y a la case qui vide le contenu.

Si un autre compte porte le même prénom et le même nom, le nom de la personne n’est pas remplacé dans l’historique du ticket ni comme nom du demandeur. Sinon, les entrées de l’autre personne seraient touchées aussi. L’adresse et le téléphone sont quand même remplacés. La vérification compare le prénom et le nom. L’historique des attributions enregistre l’identifiant de connexion. Un homonyme qui n’y figure qu’avec son identifiant de connexion n’est donc pas détecté.

Les très anciennes entrées de l’historique du ticket qui ne pointent pas encore vers le compte ne portent que le nom. Elles ne sont pas reconnues.

Un ticket qu’un agent a saisi par téléphone sans l’adresse e-mail du demandeur n’est pas reconnu. Le nom et le numéro de téléphone du demandeur y restent.

Les adresses dans les réglages ne sont pas modifiées, par exemple dans les règles de messagerie et les règles d’automatisation. Si l’adresse de la personne y figure, modifie-la toi-même.

Si la personne écrit de nouveau après l’exécution, une nouvelle exécution par son adresse couvre aussi les nouveaux e-mails. Tu la lances avec « Export by e-mail address ». Le numéro reste le même. Une nouvelle exécution sur le compte anonymisé ne trouve pas les nouveaux e-mails. Le compte ne connaît plus l’ancienne adresse.

Le système s’occupe lui-même des archives. Quand tu restaures une archive, chaque personne anonymisée auparavant est de nouveau anonymisée dans les tickets restaurés. Le message après la restauration indique combien. Une adresse qui n’apparaît dans ces tickets que dans le texte libre n’y est pas reconnue. Les fichiers d’archive sont en outre mis à jour par l’exécution nocturne qui suit une anonymisation. La carte « Délais de conservation » l’explique.

Pour une sauvegarde, c’est différent. Une sauvegarde faite avant une exécution contient encore les anciennes données. Lors de la restauration, « Ticket System Backup & Restore » s’en charge. L’application demande si toutes les personnes anonymisées dans l’état du jour doivent l’être à nouveau. « Yes » est présélectionné. Le système de tickets le fait alors lors de l’exécution nocturne à 03:00, dans le fuseau horaire défini. Cela vaut aussi quand l’interrupteur est désactivé. Jusque-là, leurs noms sont de nouveau visibles. La carte « Data protection » affiche une remarque avec leur nombre. La sauvegarde ramène aussi l’état de l’interrupteur de l’époque. Vérifie donc l’interrupteur après la restauration.

Si tu restaures une sauvegarde d’une autre manière, si tu réponds « No » ou si tu utilises « --no-reapply » en ligne de commande, cela n’a pas lieu. La voie automatique retrouve alors les comptes supprimés, tant que l’interrupteur est activé. Les exécutions que tu as lancées à la main doivent être répétées. Le lien « Download list of anonymizations » dans la carte « Data protection » t’y aide. Télécharge la liste avant la restauration. Ensuite, elle ne contient plus les exécutions faites après la sauvegarde. La liste a une ligne par personne anonymisée, avec les colonnes « Date », « Number », « Account ID », « E-mail hash » et « Content cleared ». « Date » est le moment de la première exécution en UTC. « Account ID » n’est rempli que si un compte a été anonymisé. « E-mail hash » est une empreinte de l’adresse qui ne peut pas être inversée. « Content cleared » indique si le contenu des tickets demandés par la personne a été vidé. Après chaque exécution, télécharge toi-même la liste et conserve-la en dehors du système. Une sauvegarde faite avant une exécution ne contient pas cette exécution.

Texte pour ta politique de confidentialité

En tant qu’exploitant, tu dois dire aux personnes combien de temps tu conserves leurs données. Tu peux reprendre ce texte dans ta propre politique de confidentialité.

Texte type

Après votre départ, votre nom et votre adresse e-mail dans le système de tickets sont remplacés par une valeur de substitution au bout de [36] mois. Les tickets et les chiffres sont conservés sans aucun lien avec vous. À votre demande, nous pouvons aussi anonymiser vos données plus tôt, sauf si une obligation de conservation s’y oppose. Les données des contacts externes avec lesquels il n’y a plus eu de contact depuis [36] mois sont anonymisées de la même manière. Les événements de connexion du journal de sécurité sont supprimés au bout de [90] jours. Les entrées relatives aux actions d’administration sont supprimées au bout de [12] mois.

Adapte les nombres à tes propres réglages. Supprime chaque phrase dont l’interrupteur est désactivé. Fais vérifier le texte par ton propre conseiller en protection des données. Ce manuel n’est pas un conseil juridique.

Demandes d’effacement et personnes qui reviennent

Supprimer et anonymiser sont deux choses différentes. « Delete account » ne fait que masquer un compte. « Restore account » le ramène. Jusque-là, son adresse e-mail reste réservée à ce compte. Tu traites donc une demande d’effacement avec « Anonymize » dans la boîte de dialogue de l’export de données. Cela ne peut pas être annulé. Le nom et l’adresse sont remplacés par « Anonymized user » et le numéro. Le lien vers le compte chez un fournisseur d’authentification unique est supprimé.

Chaque adresse e-mail appartient à un seul compte. Si tu crées un compte avec une adresse qu’un autre compte possède déjà, le système refuse. Le message est « This e-mail address already belongs to another account. » Il en va de même quand tu modifies l’adresse d’un compte. Si l’adresse appartient à un compte supprimé, le message est « This e-mail address belongs to a deleted account. Restore that account instead. » Restaure alors l’ancien compte au lieu d’en créer un nouveau. Les comptes anonymisés ne comptent pas. Ils ne portent plus que l’adresse de substitution.

Un compte supprimé ne peut pas être restauré si un autre compte actif possède entre-temps la même adresse. Le message est alors « This e-mail address already belongs to another account. » Modifie d’abord l’adresse de l’autre compte.

Il peut exister, depuis l’époque d’avant cette règle, des comptes qui partagent une adresse. La gestion des utilisateurs les signale par la remarque « This e-mail address belongs to more than one account. Change it so that each account has its own address. » Donne à chacun de ces comptes sa propre adresse. Jusque-là, la connexion avec cette adresse à la place du nom d’utilisateur ne fonctionne pas. L’e-mail de réinitialisation du mot de passe n’est pas envoyé non plus.

Si une personne revient après une demande d’effacement, elle obtient un nouveau compte. C’est le cas par exemple quand elle se reconnecte via Google ou Microsoft avec la même adresse. Pour cela, « Automatically create accounts on first sign-in » doit être activé. Le compte anonymisé ne porte plus son adresse et ne gêne pas le nouveau compte.

Les anciennes anonymisations n’affectent jamais les nouveaux tickets de cette personne. Cela vaut aussi après la restauration d’une sauvegarde ou d’une archive. Quand une anonymisation est appliquée de nouveau, elle ne couvre que les données créées avant son moment.

Si l’ancien compte a seulement été supprimé et non anonymisé, le système refuse la première connexion par SSO avec cette adresse. Ce que voit la personne dépend du fournisseur. Si le fournisseur confirme l’adresse, le message est « An account with this e-mail address was deleted. Ask an administrator to restore it. » S’il ne la confirme pas, le message est « Your e-mail address is not verified with the provider. » Ainsi, le système ne révèle pas s’il existe un compte supprimé pour une adresse.

En tant qu’administrateur, tu as alors deux possibilités. Si tu restaures l’ancien compte avec « Restore account », la personne continue d’y travailler avec son historique. La connexion par SSO fonctionne si le compte était déjà lié à ce fournisseur ou si le fournisseur confirme l’adresse. Si la demande d’effacement reste valable, anonymise l’ancien compte. Ensuite l’adresse est libre, et la connexion crée un nouveau compte.

L’auto-inscription répond dans ce cas de façon neutre : « Registration could not be completed. If you already have an account, use the password reset on the sign-in page. » Elle ne révèle pas s’il existe un compte pour l’adresse.

6

Délais de conservation

Avant de commencer : Seul un administrateur peut modifier ces réglages. Une anonymisation ne peut pas être annulée.

Le système ne garde les données personnelles qu’aussi longtemps que nécessaire. Une personne est anonymisée quand elle part ou quand elle le demande. Partir signifie un compte supprimé, ou un contact externe qui n’a plus eu de contact depuis longtemps. Tu traites une demande dans la boîte de dialogue de l’export de données avec « Anonymize ».

Les tickets eux-mêmes n’ont pas de délai. Leur contenu garde son utilité, par exemple comme historique client. Les rapports et les saisies de temps continuent de compter.

Tous les délais se trouvent sous « Settings → Security », dans la carte « Data protection ». Elle a trois blocs : « Deleted accounts », « External contacts » et « Security log retention ». Chaque bloc a un interrupteur, un délai et « Save ». Le bloc « Security log retention » a deux interrupteurs et deux délais. En dessous se trouve « Archives ». Après une restauration, « Restore from a backup » s’ajoute dès que la prochaine exécution de 03:00 a eu lieu. D’ici là, la carte affiche la remarque « … will be applied again tonight at 03:00. » La carte « Anonymiser des personnes » explique le premier bloc. Elle contient aussi le texte type pour ta politique de confidentialité. Sous la description de la carte « Data protection » se trouve le lien « Data protection guide for operators ». Le guide contient des modèles pour le registre des activités de traitement, les mesures techniques et organisationnelles et une politique de conservation et de suppression.

Sous chaque bloc se trouve une ligne « Last run ». Elle indique la date et l’heure de la dernière exécution nocturne et combien de personnes ou d’entrées elle a traitées. « 0 done » signifie qu’il n’y avait rien à faire. « Not run yet » apparaît tant que la tâche n’a pas de résultat. Si un interrupteur est désactivé, sa tâche ne s’exécute pas.

Si la ligne est orange, la tâche n’a pas tout terminé. Avec « skipped », elle indique combien de personnes, d’entrées ou de fichiers ont été ignorés. Pour « Archives », ce sont des fichiers verrouillés ou endommagés. Avec « failed », toute la tâche a échoué. La phrase qui suit dit quoi faire. Si elle indique « Details are in the server log. », lis le journal du serveur. Sous Linux, la commande « sudo podman logs container-backend-1 » l’affiche. Si elle mentionne la clé d’anonymisation, suis la section « Quand la clé est illisible » plus bas. La prochaine exécution nocturne réessaie ce qui a été ignoré.

Plus à ce sujet dans la carte : Anonymiser des personnes, Tout récupérer

La carte « Data protection » avec les blocs « Deleted accounts », « External contacts » et « Security log retention », en dessous « Archives » et « Restore from a backup », chacun avec sa ligne « Last run ».
Les cadres rouges sont sur les lignes « Last run ». Ici, les quatre interrupteurs sont activés. Par défaut, seuls les deux interrupteurs du bloc « Security log retention » sont activés.Ouvrir l'image en taille réelle
Le bloc « External contacts » avec l’interrupteur « Anonymize external contacts automatically » et le champ « Months without contact ».
Les cadres rouges sont sur l’interrupteur et sur le nombre de mois. Le texte en dessous indique ce qui compte comme contact.Ouvrir l'image en taille réelle
La fenêtre « Who will be anonymized » avec la phrase « Nobody is due yet with this time limit. », ANONYMIZE saisi et « Confirm ».
Les cadres rouges sont sur le champ et sur « Confirm ». Ici, le délai a été raccourci à 24 mois, et personne ne serait concerné. Sinon, le nombre et les premières personnes avec leur dernier contact apparaissent ici.Ouvrir l'image en taille réelle
La carte « Recent sign-in attempts » avec la phrase « Entries are deleted after 90 days (Settings → Security). » et trois connexions.
Le cadre rouge est sur la phrase sur le délai. Si la suppression est désactivée, elle indique « Entries are kept until you delete them. »Ouvrir l'image en taille réelle
Deux remarques en haut de la carte : le nombre d’adresses qui ne sont plus reconnues, et des anonymisations qui n’ont pas pu être reprises.
Le cadre rouge est sur la remarque concernant la reprise. Ce qu’il faut faire figure dans la section « Restaurer une sauvegarde ».Ouvrir l'image en taille réelle
L’avertissement « The anonymization key cannot be read » avec le lien « How to restore the key » et le bouton « Discard old key ».
Les cadres rouges sont sur le lien vers ce manuel et sur « Discard old key ». Tant que l’avertissement est affiché, la carte n’affiche aucune remarque sur des anonymisations en attente.Ouvrir l'image en taille réelle
La fenêtre « Discard old key » avec DISCARD saisi dans le champ « Confirmation word ».
Les cadres rouges sont sur le champ et sur « Discard old key ». Le bouton ne peut être cliqué qu’avec le mot.Ouvrir l'image en taille réelle

Contacts externes

Les contacts externes sont des personnes sans compte de collaborateur. Ce sont les demandeurs sans compte et les comptes clients. Pour le système, ils ne partent jamais. C’est pourquoi ce bloc compte le temps écoulé depuis le dernier contact.

Le dernier contact est le plus récent de ces moments : la dernière modification d’un ticket demandé par la personne, un e-mail de sa part, son propre commentaire, une réponse à une enquête de satisfaction, une approbation qui lui a été envoyée et une suggestion pour les informations sur le demandeur. Pour un compte client, le jour de sa création compte aussi. Un nouveau compte jamais utilisé n’est donc pas concerné tout de suite. Les comptes qui existaient avant la mise à jour vers la version 1.7.0 comptent comme créés le jour de la mise à jour.

Les comptes de collaborateurs et leurs adresses ne sont jamais concernés. Cela vaut aussi pour une adresse partagée comme info@ si elle appartient à un compte de collaborateur. Quiconque a un ticket pas encore fermé est ignoré jusqu’à sa fermeture. Les comptes supprimés relèvent du bloc « Deleted accounts ».

L’interrupteur « Anonymize external contacts automatically » est désactivé par défaut. À côté de « Months without contact », tu saisis le nombre de mois. De 1 à 120 sont autorisés, la valeur par défaut est 36.

Quand tu actives l’interrupteur, la fenêtre « Who will be anonymized » s’ouvre d’abord. Elle indique combien de personnes sont concernées et montre les premières avec leur dernier contact. Tape ANONYMIZE dans le champ et clique sur « Confirm ». La même fenêtre apparaît quand tu raccourcis le nombre alors que l’interrupteur est activé et que tu cliques sur « Save ».

Cela s’applique lors de la prochaine exécution nocturne. Chaque personne concernée est anonymisée comme avec « Anonymize ». Son contenu n’est jamais vidé. Il reste la valeur de substitution, les tickets et les chiffres. Les noms et les numéros de téléphone dans le texte libre restent. La carte « Anonymiser des personnes » en indique les limites.

Journal de sécurité

Le journal de sécurité enregistre les événements de connexion et les actions d’administration. Les événements de connexion contiennent aussi l’adresse IP et l’identification du navigateur. Ce qui est enregistré exactement, la carte « Le journal de sécurité » l’explique.

La carte « Recent sign-in attempts » sous « Settings → SSO Settings » montre les 100 derniers événements de connexion via SSO et l’annuaire. Toute personne autorisée à ouvrir cette page peut la voir. Par défaut, ce sont uniquement les administrateurs. La phrase sous le titre de la carte indique le délai, par exemple « Entries are deleted after 90 days (Settings → Security). »

Par défaut, les événements de connexion sont supprimés au bout de 90 jours et les actions d’administration au bout de 12 mois. Dans le bloc « Security log retention », tu règles de 7 à 365 jours à côté de « Days » et de 1 à 120 mois à côté de « Months ». Les interrupteurs « Delete old sign-in events » et « Delete old administrator actions » désactivent la suppression. Les entrées restent alors. Aucun mot de confirmation n’est nécessaire, car seules des entrées sont supprimées, pas des personnes.

La connexion avec nom d’utilisateur et mot de passe figure elle aussi dans le journal de sécurité. Une tentative échouée est enregistrée avec son adresse IP et son navigateur. Une connexion réussie n’est enregistrée que pour les administrateurs et après des tentatives échouées.

Archives

Un fichier d’archive contient aussi des personnes anonymisées seulement plus tard. L’exécution nocturne qui suit une anonymisation met donc à jour chaque fichier d’archive dans lequel la personne apparaît. Les noms et adresses y sont remplacés par les mêmes valeurs de substitution que dans la base de données. Si le contenu a été vidé, les pièces jointes de ces tickets manquent aussi dans l’archive.

Jusqu’à la nuit suivante, la personne figure donc encore en clair dans les archives. Les archives n’ont pas d’interrupteur. Un fichier d’archive verrouillé à ce moment reste inchangé, par exemple parce qu’il est en cours de téléchargement ou de restauration. Il en va de même pour un fichier endommagé. La prochaine exécution nocturne réessaie.

Heure et fuseau horaire

Toutes ces tâches s’exécutent une fois par jour à 03:00. C’est le fuseau horaire sous « Settings → General Settings », dans la carte « Time Zone », qui s’applique. L’horloge du serveur ne joue aucun rôle. Beaucoup de serveurs tournent en UTC. Là, 03:00 serait une autre heure pour toi.

Le système vérifie toutes les dix minutes si l’exécution est due. La première vérification après 03:00 la lance. Si le serveur était éteint à 03:00, l’exécution suit à la première vérification après le démarrage.

Après la mise à jour vers la version 1.7.0, la première exécution a lieu peu après la mise à jour, au plus tard à 03:00 la nuit suivante. Cette exécution supprime les entrées du journal des connexions de plus de 90 jours.

Si tu changes le fuseau horaire, le nouveau s’applique dès la prochaine vérification. L’exécution a lieu au plus une fois par jour calendaire. Après un changement vers l’ouest, elle peut sauter ce jour-là. Elle suit alors le lendemain.

L’application « Ticket System Backup & Restore » planifie ses sauvegardes dans le même fuseau horaire. Elle lit le fuseau dans le système de tickets quand le planning est appliqué. L’onglet « Schedule » et « schedule --show » affichent l’heure avec le fuseau, par exemple « 02:00 (Europe/Berlin) ». Si la base de données n’est pas joignable à ce moment, le fuseau précédent reste. S’il n’y en a pas encore, l’horloge de l’ordinateur s’applique et l’affichage indique « (host clock) ».

Le système d’exploitation ne connaît que sa propre horloge. L’application convertit donc l’heure. Selon le fuseau horaire du serveur, elle inscrit une ou deux entrées par planning. Ainsi, la sauvegarde tourne à la bonne heure en été comme en hiver. Au démarrage, elle vérifie si une sauvegarde est vraiment due. Sinon, elle se termine sans sauvegarde, et le journal indique « No backup is due at this time in … ».

Si tu changes le fuseau horaire dans le système de tickets, la prochaine sauvegarde planifiée tourne quand même. Ensuite, l’application inscrit de nouveau le planning. Le journal affiche alors un avertissement qui commence par « The time zone in the ticket system changed ». Si le planning n’a pas pu être inscrit de nouveau, il indique « The schedule could not be updated. » Ouvre alors l’application et clique sur « Apply schedule ».

Quand la clé est illisible

Le système retient les adresses e-mail anonymisées sous forme d’empreinte. Il lui faut pour cela une clé. Le trousseau de clés du serveur protège cette clé. Le trousseau se compose des fichiers key-*.xml dans le dossier des clés. S’ils manquent ou ne correspondent pas, la carte affiche l’avertissement « The anonymization key cannot be read ».

Les mots de passe enregistrés pour la messagerie et le SSO ne fonctionnent alors plus non plus. Ils dépendent du même trousseau. Les exécutions nocturnes pour les comptes supprimés et le journal de sécurité continuent. Les personnes connues seulement par leur adresse sont ignorées. « Anonymize » refuse une exécution par la seule adresse.

Voici comment récupérer le trousseau. Prends une sauvegarde d’avant le problème. Elle contient le dossier des clés sous forme de fichier séparé. Sous Linux, les sauvegardes se trouvent dans « /opt/smitey/backups ». Copie-en une dans un dossier vide et place-toi dans ce dossier. Les commandes ci-dessous écrivent la sauvegarde sous forme de fichiers ordinaires et en extraient les fichiers key-*.xml. Ensuite, elles copient les fichiers dans le dossier des clés et redémarrent le serveur du système de tickets. Les autres fichiers du dossier des clés restent tels quels. Après le redémarrage, l’avertissement a disparu. Supprime ensuite le dossier « plain ». Il contient des mots de passe et des données personnelles. Une sauvegarde plus ancienne se terminant par « .zip » n’est pas chiffrée. Pour elle, la première commande est « sudo unzip -o <fichier> volumes/dataprotection_keys.tar && sudo tar -xf volumes/dataprotection_keys.tar ».

Sous Windows, les sauvegardes se trouvent dans « C:\Program Files\SMITEY\backups ». Copie-en une dans un dossier vide. Ouvre-y PowerShell en tant qu’administrateur. Saisis la commande de l’encadré « Windows : Écrire la sauvegarde sous forme de fichiers non chiffrés et en extraire les fichiers de clés ». Remplace-y <fichier>.smbk par le nom complet du fichier de la sauvegarde. Copie ensuite chaque fichier key-*.xml avec « podman cp <fichier> container-backend-1:/app/DataProtection-Keys/ ». Saisis les commandes pour le propriétaire et le redémarrage sans « sudo ». Supprime ensuite le dossier « plain ».

Écrire la sauvegarde sous forme de fichiers non chiffrés et en extraire les fichiers de clés

sudo /opt/smitey/Backup/TicketSystemBackup decrypt ticketsystem-backup-*.smbk --out plain && sudo tar -xf plain/volumes/dataprotection_keys.tar

Le dossier contient exactement une sauvegarde. Ensuite, les fichiers key-*.xml s’y trouvent. Le sous-dossier « plain » contient toute la sauvegarde non chiffrée.

Copier les fichiers dans le dossier des clés

for f in key-*.xml; do sudo podman cp "$f" container-backend-1:/app/DataProtection-Keys/; done

Les fichiers existants portant un autre nom restent dans le dossier des clés.

Donner aux fichiers le bon propriétaire

sudo podman exec -u root container-backend-1 chown -R 1654:1654 /app/DataProtection-Keys

Le système de tickets tourne dans le conteneur sous son propre utilisateur. Les fichiers doivent lui appartenir.

Redémarrer le serveur du système de tickets

sudo podman restart container-backend-1

Après le redémarrage, le système relit le trousseau de clés.

Windows : Écrire la sauvegarde sous forme de fichiers non chiffrés et en extraire les fichiers de clés

& "C:\Program Files\SMITEY\Backup\TicketSystemBackup.exe" decrypt <file>.smbk --out plain | Out-Host; tar -xf plain\volumes\dataprotection_keys.tar

Dans PowerShell en tant qu’administrateur, dans le dossier de la sauvegarde. Remplace <file>.smbk par le nom complet du fichier de la sauvegarde. Ensuite, les fichiers key-*.xml s’y trouvent.

Le dernier recours : « Discard old key »

Si tu n’as aucune sauvegarde avec les fichiers de clés, il reste « Discard old key ». Seul un administrateur voit le bouton. Tape DISCARD dans le champ « Confirmation word » et clique sur « Discard old key ». Le système crée alors une nouvelle clé.

Les anonymisations par compte continuent d’agir. Les personnes anonymisées uniquement par leur adresse ne sont ensuite plus reconnues dans les sauvegardes et les archives. La carte indique leur nombre. Une sauvegarde plus ancienne peut donc rendre ces personnes de nouveau visibles. Les mots de passe enregistrés pour la messagerie et le SSO restent illisibles. Saisis-les de nouveau.

Restaurer une sauvegarde

Lors de la restauration, « Ticket System Backup & Restore » demande si toutes les personnes anonymisées aujourd’hui doivent l’être à nouveau. « Yes » est présélectionné. Le système de tickets le fait lors de la prochaine exécution nocturne à 03:00 dans son fuseau horaire. D’ici là, la carte affiche « … will be applied again tonight at 03:00. »

La sauvegarde ramène aussi les interrupteurs et les délais de l’époque. Vérifie donc la carte « Data protection » après la restauration.

S’il y a eu des avertissements lors de la reprise, la ligne d’état de l’application indique leur nombre, par exemple « 2 warning(s) while carrying over anonymizations. See the Log tab. » En ligne de commande, la même chose figure dans la dernière ligne et renvoie à « backup.log ». C’est là qu’est indiqué ce qui n’a pas fonctionné. Si les anonymisations n’ont pas pu être reprises, refais à la main les exécutions faites après cette sauvegarde. La liste téléchargée avant la restauration t’y aide.

Le système de tickets lit le fichier de reprise de l’application à son prochain démarrage. S’il ne peut pas le lire, la carte affiche « A carry-over file from the backup app could not be read ». Le fichier reste sur le serveur et est relu au prochain démarrage. Restaure alors la sauvegarde encore une fois avec la version actuelle de l’application.

Si la clé de la sauvegarde ne correspond pas, les anonymisations par adresse ne peuvent pas être reprises. La carte affiche alors « … could not be carried over from before the restore ». Si tu connais ces personnes, anonymise-les de nouveau avec « Export by e-mail address ».

La ligne « Last run » sous « Restore from a backup » montre combien d’anonymisations l’exécution a de nouveau appliquées.

7

Les rôles et le concept d'autorisations

Il y a trois rôles : « Admin », « Agent » et « Customer ». Aucun autre ne peut être créé. Ce qui est libre en revanche, c'est presque chaque autorisation individuelle ; les exceptions sont listées plus bas.

Tu trouves ces trois rôles sous « Settings → General Settings » dans l'onglet « Role ». Ils ne peuvent pas être renommés.

Ce qu'un rôle a le droit de faire se trouve ailleurs : sous « Settings → Security » dans la carte « Permission concept ».

Chaque ligne est une fonction, chaque colonne un rôle. Une coche l'autorise. Sous le nom figure la clé interne ; tu n'en as pas besoin pour travailler avec la page.

La liste est longue. Elle va de la gestion des utilisateurs à l'accès aux différentes pages de paramètres, jusqu'au suivi du temps.

La colonne « Agent Team » est le cas particulier. Elle ne devient utilisable qu'une fois la coche « Agent » posée sur la même ligne. Choisis-y une équipe et l'autorisation ne vaut que pour les agents de cette équipe.

Aucune autorisation ne peut être retirée au rôle « Admin ». La coche est de retour après l'enregistrement. Ainsi, personne ne peut se fermer la porte de son propre système. Seul un administrateur peut modifier le tableau. Cela vaut pour chaque réglage de la page « Security ». Toute autre personne autorisée à ouvrir la page la voit en lecture seule. Six autorisations ne peuvent jamais être données au rôle « Customer » : « Users: manage accounts », « Data export (data subject request) », « Anonymize people », « Security log », « Settings: Security » et « Settings: Single sign-on ».

Avec « Save », le changement s'applique immédiatement. Les personnes concernées s'en aperçoivent au clic suivant.

La carte « Permission concept » avec le tableau : une ligne par fonction, des colonnes pour l'administrateur, l'agent, l'équipe d'agents et le client.
Le cadre rouge entoure la ligne d'en-tête. Le sélecteur de la colonne « Agent Team » n'est utilisable que là où la coche « Agent » est posée.Ouvrir l'image en taille réelle
L'onglet « Role » avec les trois rôles, chacun marqué « Mandatory ».
Le cadre rouge entoure la remarque. Les trois rôles sont marqués « Mandatory ». Aucun d'eux ne peut être supprimé.Ouvrir l'image en taille réelle
8

Département, poste et site

Trois listes décrivent la personne et non le ticket : le département, le poste et le site.

Elles se créent sous « Settings → General Settings » dans la carte « Drop-down lists ». La manipulation est la même pour les trois.

Elles s'attribuent sur le compte. Dans le formulaire sous « User management », les champs s'appellent « Department », « Position » et « Location ».

Dans la liste des utilisateurs, le département figure sous l'équipe. Le poste et le site sont visibles dans le formulaire du compte.

Le site a un second usage. Il y a un champ « Location » sur le ticket, et il puise dans la même liste.

Chacune des trois listes a une entrée que tu ne peux pas supprimer. Elle s'appelle « None selected or available » et porte la pastille « Mandatory ».

Si tu supprimes une autre entrée, toutes les personnes qui la portaient passent à cet emplacement de remplacement. Personne ne reste ainsi rattaché à quelque chose qui a disparu.

Tu ne traduis pas ici, mais en une seule fois sur la page de traduction. Le nom anglais est l'ancre à laquelle les traductions se rattachent.

La boîte de dialogue « Edit user » avec les champs de département, de poste et de site remplis.
Les cadres rouges entourent les trois champs. Ils sont à côté de l'équipe mais veulent dire autre chose : l'équipe dit qui traite les tickets, le département dit où la personne travaille.Ouvrir l'image en taille réelle
La liste des utilisateurs avec la colonne « Team » qui contient le département sous le nom de l'équipe.
Le cadre rouge entoure la colonne. L'équipe est en haut, le département en dessous. Celui qui n'est dans aucune équipe a un tiret à cet endroit.Ouvrir l'image en taille réelle

Les captures d'écran proviennent de la version 1.3.1. Rien n'a changé sur les écrans montrés jusqu'à la version 1.13.3. La seule chose qui a un autre aspect est le numéro de version en bas de la barre latérale.