Retrouvez cet article dans : Linux Magazine 81

Maintenant que nous avons réussi à installer notre serveur RT, voyons comment nous allons commencer à le paramétrer, et donc les principes régissant l’administration de RT.

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 é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).

• AdminQueue (GérerFile)
  L’utilisateur possédant ce droit sur une file peut administrer la file en question.
• AssignCustomFields (AttribuerChampsPersonnalisés)
  Permet d’attribuer des champs personnalisés à une file.
• CommentOnTicket (CommenterTicket)
  Permet à un utilisateur de déposer des commentaires sur un ticket. Cela peut permettre à un superviseur de faire des suggestions tout en étant sûr que celles-ci ne se retrouveront pas chez le client.
• CreateTicket (CréerTicket)
  Ce droit est plus que souvent attribué à tout le monde (Everyone), afin d’avoir le moins d’intermédiaires possibles entre l’émetteur d’une demande et celui qui l’enregistre. Concrètement, si les utilisateurs non privilégiés n’ont pas ce droit, la fonction de création de ticket par mail ne fonctionnera pas.
• DeleteTicket (SupprimerTicket)
  Auto-décrit. À noter que les tickets ne sont pas détruits mais marqués comme tels, ce qui les fait disparaître de toutes les recherches. Ce droit, si vous avez la possibilité de faire créer des tickets par mail depuis internet vous évitera d’être noyé sous les spams.
• ModifyACL (ModifierACL)
  Auto-décrit.
• ModifyQueueWatchers (ModifierObservateurs)
  Idem
• ModifyScrips (ModifierScrips)
  Permet la modification des scrips RT. Ce droit ne doit être confié qu’à un administrateur RT chevronné, sous peine de trou de sécurité avec tout ce que cela implique.
• ModifyTemplate (ModifierModèle)
  La modification des modèles de correspondance doit aussi n’être confié qu’aux administrateurs RT.
• ModifyTicket (ModifierTicket)
  Permet aux intervenants, de même qu’aux demandeurs d’enrichir le ticket.
• OwnTicket (PrendreTicket)
  Ce droit de posséder un ticket permet, au contraire du précédent, de différencier les intervenants ayant leur mot à dire, de ceux qui traiteront véritablement le ticket.
• ReplyToTicket (RépondreTicket)
  Idem CommentOnTicket, pour les réponses. Ce droit ne devrait être donné qu’aux intervenants, de façon à éviter les discours incohérents envers les demandeurs.
• SeeQueue (VoirFile)
  Voir une file. Ce droit a des implications qui vont relativement loin. En effet, voir une file, c’est aussi pouvoir y déplacer un ticket. Comme par exemple une demande système qui fait des allers-retours avec la file bases de données.
• ShowACL (AfficherACL)
  Autorise la vision sur les permissions sur les objets RT.
• ShowOutgoingEmail (AfficherEmail Sortant)
  No comment.
• ShowScrips (AfficherScrips)
  Réservé aux administrateurs RT.
• ShowTemplate (AfficherModèle)
  Idem. Ce droit ainsi que le précédent permettent de voir l’essentiel du paramétrage du comportement de RT.
• ShowTicket (AfficherTicket)
  La vue sur un ticket implique que l’on voit aussi les tickets sur la page d’accueil, entre autres. Ce qui peut polluer par exemple la vision de l’administrateur système s’il n’y voit que des demandes pour les fonctionnels SAP. Ce droit permet uniquement de voir les échanges publics. Le droit suivant le complète.
• ShowTicketComments (AfficherCommentairesTickets)
  Ce droit a son importance si l’on considère que le commentaire est réservé aux intervenants. On ne le donnera évidemment pas aux demandeurs, mais pas non plus aux intervenants d’autres files pouvant voir les tickets de la file considérée.
• StealTicket (VolerTicket)
  Voler un ticket n’est pas mal. C’est le travail qui se transmet. Dans les faits, c’est même le seul moyen d’assurer la continuité d’activité sur l’absence d’un des intervenants (maladie, congés, etc.).
• TakeTicket (PrendreTicket)
  Ce droit va souvent de pair avec celui de posséder un ticket. Cependant, les tickets peuvent être assignés par un superviseur, auquel cas le droit de prendre un ticket n’est pas nécessaire, le droit de le posséder l’étant.
• Watch (Observer)
  Le droit d’observer est la base d’un fonctionnement symbiotique d’une équipe. Observer une file permet de ressentir l’activité d’une équipe. Ce droit précis n’est pas à confondre avec le suivant, car il ne concerne que la partie visible des transactions sur un ticket, les demandes et les réponses, les commentaires n’étant pas vus.
• WatchAsAdminCc (ObserverComme AdminCC)
  Similaire au droit précédent, il permet aux personnes le possédant d’être destinataires des demandes, réponses, mais aussi commentaires sur les tickets d’une file.

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 :

• AdminAllPersonalGroups (AdminAllPersonalGroups) :
  Gestion de tous les groupes personnels, y compris ceux appartenant à d’autres.
• AdminOwnPersonalGroups (GérerGroupesPersonnelsPropres)
  Gestion de vos groupes personnels.
• AdminUsers (GérerUtilisateurs)
  Pas besoin d’en dire plus.
• AssignCustomFields (FixerChampsPersonnalisés)
  AssignCustomFields autorise l’utilisateur qui le possède à assigner des champs personnalisés de façon globale.
• DelegateRights (DéléguerDroits)
  Le fait de donner le droit DelegateRights à un utilisateur lui permettra à son tour d’attribuer des droits à d’autres. Ce droit est à manier avec précaution, comme peut l’être le droit GRANT de SQL. Il peut avoir une implication en termes de sécurité. Déjà que les ACL de RT sont difficiles à maîtriser, n’allez pas vous créer de problèmes dès le départ en donnant ce droit.
• ModifyOwnMembership (ModifierPropresAppartenances)
  Permet d’entrer ou sortir de groupes.
• ModifySelf (ModifierDonnéesPerso)
  ModifySelf permet entre autres à un utilisateur de modifier son mot de passe et ses informations personnelles.
• ShowConfigTab (VoirOngletConfiguration)
  ShowConfigTab indique que l’utilisateur a le droit de voir l’onglet Configuration de RT.
• SuperUser (SuperUtilisateur)
  Avons-nous besoin de présenter ce droit ?

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 demandeurs 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 ne vous 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 :

• grFile
  Les gens autorisés à prendre des actions sur les tickets de la file.

• grFileWatchers
  (Souvent d’un nombre moindre), les gens recevant les échanges sur la file.

Pour une file Supervision, cela donne les groupes Supervision et SupervisionWatchers.
Les droits seront attribués (la file devra être créée auparavant) comme suit :

• File Supervision > Watchers / Observateurs > Groupe : SupervisionWatchers
• File Supervision > Group Rights / Droits de groupe > Groupe :

Tous les droits sauf FixerChampsPersonnalisé, ModifierACL, ModifierScrips et ModifierModèle pour le groupe Supervision.
À noter que les gens du groupe SupervisionWatchers n’ont aucun autre droit que celui de recevoir des mails. Ils seront néanmoins inscrits en tant qu’utilisateurs de la file.
Attention, il y a un léger problème d’œuf et de poule ici : quelques allers-retours entre groupes et file seront nécessaires entre la création des groupes, de la file, et ensuite l’assignation des droits sur la file au groupe.

Adjoindre à chacun des groupes les utilisateurs nécessaires :

• Dans le groupe grFile : tous les intervenants sur la file, y compris (par exemple) le patron éventuel de l’équipe ;
• Dans le groupe grFileWatchers : uniquement les personnes déjà dans le groupe grFile devant recevoir les notifications.

Le fait pour tous de recevoir les messages sur toutes les transactions de tous les tickets de la file permet à tout un chacun de savoir ce sur quoi travaillent les autres, et éventuellement de pallier l’absence de l’un ou de l’autre en reprenant ses tickets en cours.

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 sur la figure 1.

Fig. 1 : É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 (figure 2).
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.

Fig. 2 : Écran de création/modification d’une file

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 aparté : 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... =head2 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.

Scripts

Une image vaut un certain nombre de mots, donc voyons tout d’abord de quoi il retourne (figure 3) :

Fig. 3 : Écran de modification d’un scrip

Un script 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 :
http://exemple.com/rt/SelfService/
Pour cela il faut, en tant qu’administrateur RT (root), donner les droits à « Non privilégié » :

• Pour chaque file à laquelle vous souhaitez laisser un accès par le self-service, vous devrez donner accès aux utilisateurs « Non privilégiés ». Cet accès est accordé par un utilisateur ayant suffisamment de privilèges pour cela. Il faut passer par le menu Configuration > Files > (choisir la file) > Droits de groupe.
• Dans la liste des droits à accorder au groupe système « Non privilégié », sélectionnez VoirFile.
• Pour les files publiques (où tout le monde peut créer un ticket), les droits de création de ticket seront attribués à tout le monde.
• Le droit AfficherTicket vient des droits globaux sur le rôle Demandeur.
• Le droit CréerTicket vient soit des droits globaux, soit des droits sur la file considérée, qui doit être conjugué avec le droit VoirFile pour pouvoir sélectionner la file où créer le ticket.

Il faut ensuite attribuer un mot de passe à l’utilisateur auquel on souhaite donner l’accès au self-service. Pour cela, il vous faudra passer par la procédure habituelle et envoyer le mot de passe à l’utilisateur.
Mais le mieux reste de laisser cette partie à RT, et de lui faire générer automatiquement les mots de passe puis les envoyer aux utilisateurs.
La documentation en ligne propose un modèle de réponse automatique [4], envoyé lors de la création d’un ticket. Ce scrip assigne un mot de passe prononçable aux utilisateurs qui n’en ont pas encore et l’envoie par mail. Si ces utilisateurs ont déjà ouvert des tickets préalablement, ils pourront aussi les consulter dans l’interface web.
Bien entendu, vous pouvez le traduire et l’adapter à vos besoins avant de le mettre en production chez vous, en fournissant un lien vers le self-service dans la réponse. Le self-service n’est pas accessible directement (par un lien depuis l’interface) pour les acteurs du support, alors que les personnes non privilégiées sont directement redirigées dessus à leur connexion. Néanmoins, il est très simple de modifier le menu pour ajouter l’accès au SelfService aux intervenants.

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, puisqu’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 multiinstance.

Liens:

• [1] Les manuels de Mason (introduction, manuel du développeur, de l’administrateur, manuel de dérivation des classes), etc. http://www.masonhq.com/docs/manual/
• [2] Dave Rolsky & Ken Williams, Embedding Perl in HTML with Mason, O’Reilly. http://www.oreilly.com/catalog/perlhtmlmason/ et http://www.masonbook.com/.
• [3] Cleanly Customize RT, Personnalisation propre de RT, Wiki RT. http://wiki.bestpractical.com/index.cgi?CleanlyCustomizeRT
• [4] Autogenerated Password, Génération automatique de mot de passe, Wiki RT. http://wiki.bestpractical.com/index.cgi?AutogeneratedPassword