Paramétrage de RT

Avec l'installation, qui s'est heureusement simplifiée depuis la version 2, le paramétrage de RT reste la partie la plus importante de la mise en œuvre. Nous allons d'abord voir les différents objets de RT, la façon dont ils sont liés entre eux (du point de vue applicatif, et non technique comme dans le schéma de la base de données), les droits d'accès à ces objets, et ce que ça peut autoriser ou interdire.

Ensuite, les différentes tâches d'administration, comme la création des files, des utilisateurs, et la configuration des objets annexes comme les champs personnalisés sera passée en revue.

Les objets de RT

La file

Au commencement est la file. Et particulièrement la file general qui est même la première et indestructible file. Une file est un conteneur à tickets, un ticket représentant une demande et toutes les informations nécessaires ou relevées pendant son traitement.

Une file peut avoir pour but de regrouper les demandes destinées à une équipe particulière (les administrateurs système par exemple), les demandes émanant d'un client particulier (son point d'entrée unique), ou servir de pseudo-liste de diffusion ou boîte aux lettres d'équipe, comme une file dont l'adresse est abonnée aux listes de sécurité. Les attributs d'une file sont ses deux adresses de messagerie, des priorités initiale et finale, ainsi que l'échéance normale de résolution d'un ticket.

Le ticket

Le ticket est la représentation d'une demande ou d'un incident qui devra être résolu, et dont il faut garder trace.

Un ticket dans RT se voit attribuer un acteur et un seul (qui est Nobody au départ) ou propriétaire, qui a pour charge de mener à bien la résolution de cette demande. C'est cet acteur qui va pouvoir en modifier l'état ou statut (nouveau, ouvert, bloqué, résolu, rejeté, effacé).

L'état nouveau est l'état par défaut d'un ticket venant d'être créé : personne ne l'a pris (le propriétaire change) ni n'a commencé à travailler dessus (passage à l'état ouvert). On peut passer un ticket à l'état bloqué pour signifier qu'il est en attente de quelque chose, l'effacer s'il avère que l'anti-spam n'a pas fait son travail, en cas d'activation des demandes par mail ou le rejeter si le demandeur n'a pas fait son travail en amont (RTFM). On peut enfin résoudre une demande (passage à l'état résolu) afin de le faire disparaître de la base des tickets actifs.

Il a aussi un ou plusieurs demandeurs, des personnes en copie, un niveau de priorité et un ensemble de dates (création, butoir, résolution effective). Des observateurs peuvent être définis pour un ticket, ou plus généralement sur une file (toute une équipe) voire globalement. Ces observateurs peuvent être au même niveau que le demandeur, ou au même niveau que les acteurs : un demandeur ou une personne en Cc: ne verront que les correspondances, l'acteur ou ses pairs verront les correspondances et les commentaires sur le ticket. C'est là qu'interviennent les deux adresses de messagerie d'une file : il y a une adresse pour les correspondances (seule utilisable par les demandeurs), une autre pour les commentaires.

Des champs temporels peuvent être définis comme le temps passé (rempli manuellement), le temps estimé de résolution, l'échéance prévue pour la résolution, le temps restant avant cette échéance, ainsi que des priorités, allant de 0 à 99. La sémantique associée à ces priorités devra être définie avant de commencer à utiliser RT, de façon à ce que tout le monde se mette d'accord sur la priorité « très urgent »... Ça évitera de voir des tickets de priorité 20 traîner car un acteur s'est mis 20 comme limite, alors que ses voisins de bureau qui le remplacent pendant ses vacances mettent la barre de l'urgence à 50...

De même qu'avec bugzilla il est possible de noter les doublons de bogues (notion très orientée développement), il est possible avec RT de définir des relations entre tickets. Rapidement, disons qu'il est possible de fusionner des tickets (les doublons de bugzilla) avec tout leur historique, de faire des tickets dépendant d'autres tickets (gestion de projets, des tickets jalons ne pouvant être fermés sans que les sous-tickets soient fermés), ou des relations simples (l'équivalent de notre verbe « confer » bien français).

Dernière chose primordiale, l'historique du ticket, qu'il n'est normalement pas possible de modifier dans RT. Cet historique est constitué des messages échangés entre demandeurs et acteurs, des commentaires des acteurs (successifs), et des notifications des actions prises par RT, soit dans son fonctionnement normal, soit par le biais d'un scrip, comme les changements de priorité, d'acteurs, etc.

Des champs personnalisés

On peut aussi associer à un ticket des champs personnalisés qui permettent d'ajouter des sémantiques personnalisées à ceux-ci. Ces champs personnalisés sont définis au niveau global, et associés aux tickets soit à ce même niveau global, soit file par file.

Cela peut représenter des champs de formulaire avec des données qu'on aimerait obligatoires (on ne peut pas encore obliger un acteur à renseigner un champ, mais ça va venir dans les prochaines versions), le nom du client, le poste de facturation ou que sais-je encore. Je laisse votre imagination faire ses preuves sur le sujet :-). Créer des champs personnalisés

Mais comme tout objet de RT, les champs personnalisés sont soumis à des contrôles d'accès. Il faut que les utilisateurs et/ou les groupes concernés disposent du droit « FixerChampsPersonnalisés ».

Ensuite, la création de champs personnalisés se fait par le menu « Configuration » / « Champs Personnalisés » / « Nouveau champ personnalisé ». Il est possible ensuite de laisser fixer des valeurs à choisir ou au contraire de laisser le champ libre aux utilisateurs pour saisir des mots dans les champs personnalisés, mais l'exploitation n'en sera que plus difficile.

Il faut ensuite attribuer le champ personnalisé à une file, par le menu « Configuration » / « Files » / (Choisir la file) / « Champs personnalisés du ticket » / (Cocher dans la liste les « Champs personnalisés non sélectionnés ») / Valider.

Ou, si vous préférez, attribuer ce champ personnalisé à toutes les files, passez par le menu « Configuration » / « Global » / « Champs Personnalisés » / « Ticket » / (Cocher dans la liste les « Champs personnalisés non sélectionnés ») / Valider.

Des modèles

Les modèles sont un contenu générique pour les notifications. Ces modèles sont associés aux scrips, et peuvent inclure un minimum de code perl de façon à intégrer des variables ou résultats de méthodes de RT dans l'instanciation du modèle. Vous trouverez des exemples intéressants dans les modèles par défaut de RT que je vous laisse découvrir (Configuration -> Global -> Modèles).

Des scrips

Les scrips (sans « t ») sont un ensemble de conditions d'exécution et des actions associées qui peuvent être assimilées aux déclencheurs (triggers) que l'on trouve dans les SGBD. Les conditions et actions peuvent être prédéfinies ou personnalisées, auquel cas elles sont écrites en Perl et s'exécuteront directement dans RT par le biais d'un eval.

Une petite dizaine de scrips sont livrés dans l'installation standard de RT de façon à assurer son comportement par défaut de façon globale : envoyer une notification de prise en compte à la réception d'une demande, notifier les observateurs sur les commentaires et les correspondances, notifier au demandeur que sa demande a été résolue, même si l'acteur n'a pas envoyé explicitement de message, etc.

Des utilisateurs...

Les utilisateurs sont eux identifiés comme dans les gestionnaires de listes de diffusion : par leur adresse de messagerie. Cela permet une chose très pratique : éviter la saisie des personnes. En effet, chaque personne envoyant une demande à RT est enregistrée dans la base des utilisateurs si elle n'y est pas encore. Même les futurs acteurs du support peuvent ainsi avoir l'essentiel de leurs coordonnées saisies automatiquement, juste en envoyant un mail à RT. Il suffira ensuite de donner à ces utilisateurs le droit d'avoir des droits (i.e. de devenir un acteur du support) et un mot de passe.

...regroupés...

Les utilisateurs peuvent bien évidemment être regroupés par groupes, des groupes pouvant inclure d'autres groupes. Cela permet de simplifier d'autant la gestion des droits, idéalement les utilisateurs ne devant avoir aucun droit sauf celui d'être dans un ou plusieurs groupes qui lui aura des droits.

...ayant des rôles

Dernier point permettant de catégoriser des utilisateurs de RT : les rôles. Ceux-ci sont au nombre de quatre : Cc, Intervenant, Demandeur, et AdminCc.

Un Demandeur est une personne qui a créé un ticket, et qui a mis éventuellement mis en copie d'autres personnes, qui se voient attribuer le rôle Cc (du même Cc: -- carbon copy ou copie conforme -- que celui de nos messageries). Demandeur et Cc ne verront que les réponses faites sur un ticket.

Un Intervenant est donc un utilisateur privilégié qui a pris un ticket pour le traiter. Les personnes en AdminCc sont d'autres intervenants (ou non, mais c'est souvent le cas) qui sont en copie de tous les messages concernant le ticket, commentaires comme réponses.

Des droits associés

Les droits sont donc attribués à un utilisateur ou un groupe d'utilisateurs donnés.

Ils portent de façon globale, sur une file donnée, ou un groupe, bref sur les objets de RT.

Cependant, la gestion des droits dans RT n'est pas aisée. En effet, le nombre de droits différents sur les objets est très important. Il est facile de s'y perdre, d'autant que ces droits ne sont pas toujours très bien documentés. Essayons d'y voir plus clair et d'en faire une revue de détail.

Droits sur les files et leurs tickets

Les droits sont ici listés sous leur nom originel anglais, et leur traduction française dans la dernière version de RT (3.4.4 à l'heure où ces lignes sont écrites).

Droits sur champs personnalisés

Les droits sur les champs personnalisés sont explicites, citons rapidement :

• AdminCustomField (GérerChampPersonnalisé)

• ModifyCustomField (ModifierChampPersonnalisé)

• SeeCustomField (VoirChampPersonnalisé)

Droits sur Groupes

Idem pour les groupes d'utilisateurs :

• AdminGroup (GérerGroupes) ;

• AdminGroupMembership (GérerAppartenanceGroupes) ;

• SeeGroup (VoirGroupe) ;

• ModifyOwnMembership (ModifierPropresAppartenances).

Droits sur les recherches sauvées

Existent les droits suivants :

• CreateSavedSearch (CréerRechercheSauvée) ;

• EditSavedSearches (ModifierRecherchesSaugardées) ;

• LoadSavedSearch (ChargerRechercheSauvée) ;

• ShowSavedSearches (AfficherRecherchesSauvées).

Droits globaux

Ces droits globaux, ou plutôt attribués globalement, et de portée globale, sont constitués de la totalité des droits déjà cités, associés à ceux, spécifiques, qui suivent :

Les premiers droits

Après l'installation de RT, il va convenir d'attribuer une première série de droits afin de le rendre utilisable. Cette liste n'a pour but que de vous mettre le pied à l'étrier, et pourra être adaptée selon vos besoins plus pointus.

D'abord, nous partirons du principe que tout le monde a le droit de créer un ticket dans toutes les files que nous créerons. Une autre possibilité est d'avoir une première file qui réceptionne les mails, une armée d'intervenants de premier niveau qui les distribue dans les autres files (deuxième niveau), ces autres files n'étant pas accessibles de l'extérieur. Un autre problème est le spam pour les files visibles depuis Internet.

En l'absence de droits, vous recevrez un message qui vous dira en substance :

 RT could not load a valid user, and RT's configuration does not allow
 for the creation of a new user for your email.

Autorisons donc n'importe qui à créer un ticket du point de vue global. Cette opération est identique sur une file. Aller dans le menu Configuration > Global > Droits de groupe, et donner le droit CréerTicket à Tout le monde.

Un mail tel que echo coucou | mail -s'je veux un ticket' support vous créera votre premier ticket.

De plus, Tout le monde doit aussi pouvoir répondre aux réponses à leurs demandes. D'où le droit RépondreTicket à leur accorder.

Ensuite, les comptes Privilégiés se voient accorder le droit ModifierDonnéesPerso, pour des raisons évidentes. Ce droit peut être étendu à Tout le monde si vous mettez en œuvre le self-service. Toujours dans le cas du self-service, donnez le droit aux demandeur de voir leurs tickets via AfficherTicket sur le rôle Demandeur.

Saupoudrez des droits concernant les recherches sauvées de façon à rendre l'utilisation de RT moins fastidieuse.

La suite des droits viendra avec ceux donnés aux groupes intervenant sur une file ou une autre.

Création d'une file

La création d'une file doit être écrite de façon procédurale. Ce mécanisme doit être reproductible, car la création risque fort d'être reproduite, et surtout normalisée, ne serait-ce que quant à la gestion des droits sur la file.

La procédure qui suit permet donc de créer rapidement une file avec ses utilisateurs. Elle suit une organisation qui vous ne sera exposée que la prochaine fois pour des raisons de place. Mais avant de poursuivre, rappelons d'abord l'essentiel pour une file RT :

• une file est accessible soit par l'interface web par les intervenants, soit par mail ;

• les intervenants peuvent ou non recevoir les messages sur création/modification d'un ticket (les opérations ou transactions sur les tickets) ;

• seuls ces intervenants peuvent par défaut voir la file et prendre des actions sur les tickets.

Cela va nous mener à trois tâches distinctes :

• la création des utilisateurs ;

• la création du groupe de personnes étant prévenues par mail des événements sur les tickets de la file ;

• la création du groupe de personnes pouvant voir et intervenir sur les tickets.

Création des utilisateurs

Rappelons d'abord que les utilisateurs sont identifiés par leur adresse de messagerie. Cela signifie que si les personnes ont déjà créé un ticket ou ont été en copie sur la création d'un ticket, elles sont déjà enregistrées avec leur adresse mail pour identifiant.

Il suffit de les retrouver (recherche sur l'identifiant) puis de leur donner le droit d'avoir des droits dans RT (Let this user be granted rights).

Dans le cas où un utilisateur n'a pas le droit d'avoir des droits, et s'il a un mot de passe, alors il ne pourra avoir accès qu'au self-service, si celui-ci est activé (ce qui sera vu plus loin).

Changer le mot de passe, et éventuellement vider la case commentaires pour enlever le texte Autocreated when added as a .....

En l'absence d'un utilisateur pré-existant, il suffit de le créer (menu Configuration > Users > New User). L'écran est suffisamment simple pour ne pas le détailler ici.

Une astuce : usez et abusez de la file General (celle créée par défaut), à laquelle vous aurez bien sûr donné une adresse de messagerie. Demandez ensuite à vos utilisateurs intervenants d'envoyer un mail à l'adresse de cette file. Vos utilisateurs seront ainsi pré-créés, il suffira juste de les activer pour qu'ils aient accès à RT. Si en plus vous utilisez la génération automatique de mot de passe, le gros du travail est déjà fait :-).

Création des groupes d'utilisateurs

De façon à permettre à plusieurs personnes d'avoir des vues différentes sur la file, nous allons créer deux groupes, grFile et grFileWatchers :

Création de la file

La création de la file est très simple, il suffit de spécifier les paramètres suivants :

• le nom de la file ;

• sa description : ce champ sera utilisé lors des émissions de messages par RT lui-même, comme sur la notification d'enregistrement d'un ticket au demandeur ;

• l'adresse de réponse, généralement le nom de la file : file@domaine.fr soit supervision@rt.example.com pour notre exemple ;

• l'adresse de commentaire, généralement le nom de la file suffixé par « -comment » : file-comment@domaine.fr soit supervision-comment@rt.example.com ;

• la priorité de départ d'un ticket à sa création (0 par défaut) ;

• la priorité à l'échéance d'un ticket (par exemple 20) ;

• le temps « normal » de résolution d'un ticket, qui permet de calculer les échéances.

On retrouve le tout sur l'écran suivant :

Écran de création/modification d'une file

Une file sans utilisateur ne sert pas à grand chose. On assigne ou on retire les utilisateurs ou groupes par l'écran qui suit, via une recherche par nom. Remarquez que ces utilisateurs seront soit en Cc, soit en AdminCc. La gestion des droits se fera après.

Écran de création/modification d'une file

Ne pas oublier de donner les bons droits tels que définis plus haut sur la file nouvellement créée (l'œuf et la poule), sans quoi la file se remplira sans jamais pouvoir être vidée.

Intégration avec la messagerie

Définition des adresses de la file

Les adresses se définissent dans le fichier /etc/aliases de Postfix de la façon suivante :

 supervision:         "|/opt/rt3/bin/rt-mailgate --queue 'Supervision' --action correspond --url http://localhost/rt/"
 supervision-comment: "|/opt/rt3/bin/rt-mailgate --queue 'Supervision' --action comment    --url http://localhost/rt/"

Le script /opt/rt3/bin/rt-mailgate prend en paramètre la file (--queue, telle que définie par son nom dans RT), l'action correspondante à l'adresse (correspondance ou commentaire), et la façon de communiquer avec RT (l'URL).

Ne pas oublier de lancer la commande suivante pour dire à Postfix pour relire les nouveaux alias :

  # newaliases

Petit apparté : Jean (Forget) me souffle au CVS (la version moderne de l'oreille ;)) que d'après ses vagues souvenirs de lycée, « alias » est un mot latin invariable. Donc, que l'on adopte le pluriel d'origine ou le pluriel français des mots en « s », « x » ou « z », le pluriel de « alias » est « alias ».

Dont acte. Mais la commande est anglophone...

Ré-écriture d'adresses

Il n'est pas rare de rencontrer un serveur appartenant à un domaine DNS interne différent de celui qui sera utilisé pour la messagerie de RT.

Prenons ainsi notre serveur Linux hébergeant RT, qui a pour nom de domaine DNS par défaut (dans son /etc/resolv.conf) exemple.fr, mais doit gérer les mails du domaine rt.example.com qui lui seront adressés par le fédérateur de messagerie de l'entité.

Le problème est donc de séparer les mails internes (exemple.fr) des mails externes (rt.example.com), et surtout de renvoyer les mails à l'extérieur avec une adresse qui sera elle-même visible de l'extérieur, tout en conservant une adresse source interne depuis le serveur RT pour les mails administratifs ou système.

Il faut donc trouver un moyen d'écrire les adresses correctement pour l'envoi aux fédérateurs de messagerie. Pour ce faire, nous allons utiliser la gestion des adresses canoniques de Postfix. La forme de réécriture utilisée sera la plus simple : user@domain address.

Nous allons donc récupérer toutes les parties gauches d'adresses renvoyant sur RT pour les ajouter à la carte d'adresses canoniques. Le petit script met en œuvre la correspondance entre adresses RT (à gauche du « : » dans /etc/aliases et le domaine rt.example.com associé :

 # cat /usr/local/bin/rtpostfix
 #!/bin/bash
 
 CanMap=/etc/postfix/canonical-rt
 # Vidage de la carte
 > $CanMap
 
 # recherche de rt-mailgate, puis de la partie avant le : (-F:)
 perl -lanF: -e 'print "$F[0] $F[0]\@rt.example.com" if /rt-mailgate/' \
     /etc/postfix/aliases
 
 # « compilation » de la carte en séquentiel indexé
 postmap $CanMap
 # Recharger la configuration de postfix
 /etc/init.d/postfix reload
 # Reconstruction des aliases
 newaliases

Postfix est rechargé en fin de script, les nouvelles adresses sont donc prises en compte immédiatement pour la réécriture. La nouvelle configuration de la traduction d'adresses canoniques est prise en compte dans Postfix avant l'activation de la redirection des nouvelles adresses vers RT.

Donc une fois le fichier aliases modifié après la création d'une nouvelle file, il suffit de lancer le script rtpostfix en lieu et place de newaliases, qui sera appelé en fin de script.

N'oubliez pas cependant d'avoir ajouté la ligne qui suit à votre main.cf :

 canonical_maps = hash:/etc/postfix/rt-canonical

Elle vous permet la prise en compte de la carte de réécriture. Il n'est besoin de la spécifier que la première fois, et de l'y laisser.

Configuration fonctionnelle

La configuration fonctionnelle de RT est essentiellement basée sur un mécanisme spécifique à RT : les scrips. En effet, RT sait faire quelques petites choses par défaut, à savoir trier des messages et les agréger en tickets pour les ranger dans des files, mais guère plus. En fait, le gros du travail de RT, comme réagir en spammant une équipe entière sur la réception d'un nouveau ticket est bien du ressort des scrips, associés pour la communication avec les utilisateurs avec les modèles. Vous pouvez le vérifier en allant voir dans la configuration de RT la liste des scrips existant juste après une nouvelle installation.

Une autre partie importante de la configuration fonctionnelle est la présentation de l'information à l'intervenant qui prend et résout les tickets.

Enfin, un point qui relève tant de la configuration que de la dynamique de l'application est l'automatisation possible pour assurer des tâches par lot sur les tickets. Nous en verrons un exemple avec l'automatisation sélective de l'escalade des priorités des tickets.

Scrips

Une image vaut un certain nombre de mots, donc voyons tout d'abord de quoi il retourne :

Écran de modification d'un scrip

Un scrip est un morceau de code, qui sera exécuté par la magie de l'eval de perl. Ce code est stocké dans la base de données de RT. L'avantage est donc de pouvoir influer sur le comportement de RT sans pour autant quitter l'interface graphique. Cela apporte aussi les inconvénients de ces avantages : difficulté de d'épépinage (la version Academy-approved de débogage), fréquents allers-retours avec le code des modules, indisponibilité d'avoir directement une aide sur l'API, impossible de traduire à l'avance les chaînes du système de traduction bref, que du bonheur :-).

Cela dit, le code à écrire est souvent relativement simple, s'agissant souvent d'un changement d'état du ticket concerné et d'une communication adéquate avec un modèle approprié.

Reprenons l'exemple ci-dessus de Nicolas, exemple qui est disponible sur le wiki. Le besoin initial est de ne plus voir un ticket résolu non attribué. L'idée est de voir directement dans le ticket sans en consulter l'historique la personne l'ayant clôturé. Le principe est donc d'attribuer le ticket à la personne qui l'aura fermé.

 # Qui est l'acteur de la condition déclenchante du scrip ?
 my $Actor = $self->TransactionObj->Creator;

 # ne rien faire sinon retourner si c'est le système lui-même
 return 1 if $Actor == $RT::SystemUser->id;

 # idem si le ticket est déjà attribué
 return 1 unless $self->TicketObj->Owner == $RT::Nobody->id;

 # essai de changement de propriétaire
 $RT::Logger->info(
     "Auto assign ticket #" . $self->TicketObj->id . " to user #" . $Actor );
 my ( $status, $msg ) = $self->TicketObj->SetOwner($Actor);
 unless ($status) {
     $RT::Logger->warning("Impossible d'attribuer le ticket à $Actor: $msg");
     return undef;
 }
 return 1;

Nous fermerons là la partie sur les scrips, sachant que cela dépasse le cadre de cet article déjà chargé

Modèles

Le modèle est le moyen de communication par mail utilisé entre RT et les différents récipiendaires de mails. Ils sont stockés en base de données, et peuvent inclure du code Perl pour afficher dans le message les informations que vous désirez communiquer. Voici un exemple de modèle issu d'un RT fraîchement installé :

 RT-Attach-Message: yes
 {$Transaction->CreatedAsString}: Request {$Ticket->id} was acted upon.
   Transaction: {$Transaction->Description}
         Queue: {$Ticket->QueueObj->Name}
       Subject: {$Transaction->Subject || $Ticket->Subject || "(No subject given)"}
         Owner: {$Ticket->OwnerObj->Name}
    Requestors: {$Ticket->RequestorAddresses}
        Status: {$Ticket->Status}
   Ticket <URL: {$RT::WebURL}Ticket/Display.html?id={$Ticket->id} >
 
 {$Transaction->Content()}

Vous noterez que le code Perl entre accolades sera remplacé par l'information représentée par la variable. L'accessibilité de ces modèles en rend la traduction et la personnalisation très aisée.

Personnalisation (Mason)

RT est basé sur Mason[1], un serveur d'application pour Perl. Mason[2] mélange à la façon de PHP code HTML et code Perl. L'autre particularité de Mason est de permettre le découpage des pages HTML en entités atomiques, comme le bandeau du haut de page, le menu à gauche, et toutes les boîtes contenant des informations différentes comme par exemple sur la page d'accueil (Recherche rapide, création rapide de ticket, listes de tickets propres et non pris, etc.).

Toute l'interface de RT est ainsi construite morceau par morceau, et si cela doit être un enfer à gérer pour le concepteur graphique qui conçoit ses CSS, c'est un bonheur pour nous. D'autant plus que RT a un mécanisme de surcharge des pages par le jeu de deux arborescences : share/html (Vendor) et local/html (Local). Un troisième niveau existe, Overlay, mais dépasse le cadre de l'article.

Sachez simplement et rapidement qu'il vous suffit de recopier de l'arborescence Vendor juste le composant que vous voulez modifier dans celle Local, de modifier ce composant recopié, et de relancer le serveur HTTP pour que ce soit pris en compte. Un jeu d'enfant pour les modifications rapides de la page d'accueil par exemple.

Pour plus d'informations sur le sujet, reportez-vous à la page afférente[3] sur le Wiki de RT.

Le self-service

Le self-service est une partie de RT qui donne aux demandeurs un accès à une vue limitée de l'interface web de RT. Cette vue leur permet de suivre leurs demandes présentes et passées. Ils peuvent aussi ouvrir de nouveaux tickets, et consulter leurs tickets fermés.

Si vous avez une installation de RT qui fonctionne, vous pourrez accéder au self-service dans le répertoire /SelfService/. Par exemple :

La suite au prochain épisode

Nous l'avons déjà vu sommairement avec SPIP, un outil ne fait pas tout. Et il va tout autant avec RT qu'avec SPIP. Et même plus, puisque un tel outil sans suivi, gestion, bref, pas « managé » devrions-nous dire, ne vaut que le prix mis dans son installation, c'est à dire pas grand chose. En fait, déjà trop cher.

Le prochain et dernier article sur RT vous présentera donc l'art difficile de l'organisation autour de son utilisation. Pour les lecteurs plus techniciens, il y aura tout de même de vrais morceaux de technique dedans, avec notamment les extensions de RT ou son installation multi-instances.

Liens et livres

Les auteurs

• Nicolas Chuche - <nchuche@barna.be>

  Nicolas Chuche est ingénieur système au ministère de l'Équipement et utilisateur de systèmes GNU/Linux et Unix depuis une dizaine d'années.

• Jérôme Fenal - <jfenal@free.fr>

  Jérôme Fenal est utilisateur de GNU/Linux depuis 1994, de divers Unix ou Unix-like depuis un peu plus longtemps.

Merci aux Mongueurs de toute la Francophonie qui ont assuré la relecture de cet article.