Version 2

Les structures principales étaient :

• des services
• dans chaque service, des catégories
• dans chaque catégorie, des modèles de tickets

Version 3

• les modèles de ticket n'existent plus ; chaque catégorie est en soi un modèle de ticket (avec un sujet et un message pré-défini)
• une catégorie peut avoir des sous-catégories, sur plusieurs niveaux

Les propriétés d'une catégorie peuvent être héritées de la catégorie parente, ou à défaut du service. Il en est de même pour les membres des catégories (pas besoin de définir les membres si ce sont les mêmes pour tout un arbre de catégories).

Version 2

Les tickets appartenaient à des services, mais pas forcément à des catégories (dans ce cas, ils étaient dits " orphelins ").

Version 3

Les tickets sont tous rangés dans une catégorie.

Version 2

La virtualisation concernaient :

• Les tickets orphelins d'une service, qui pouvaient être redirigés vers une catégorie
• les catégories, dont les tickets pouvaient être redirigés vers une autre catégorie

La redirection d'une catégorie se faisait forcément vers une catégorie réelle

Version 3

• Les services eux-même peuvent être virtualisés : un service peut être virtuel, c'est-à-dire n'être qu'une façade pour un autre service (son service cible, réel).
• Le chainage des redirection est possible (détection des boucles).

  Astuce
  La virtualisation des services permet de ne pas avoir à redéfinir les catégories des services de façade chaque fois que les catégories des services cible changent.

Version 2

L'invitation à suivre un ticket pour un utilisateur consistait en l'envoi d'un simple courrier invitant à consulter le ticket. Selon la visibilité du ticket, l'utilisateur invité n'était pas toujour autorisé à le consulter.

Version 3

L'invitation à suivre un ticket pour un utilisateur consiste à donner le rôle d'invité par rapport au ticket à l'utilisateur et à lui envoyer un courrier invitant à consulter le ticket. Muni de ce rôle, l'utilisateur invité obtient les mêmes permissions de visualisation que le propriétaire du ticket.

Version 2

Les tickets clos restaient ad vitam eternam dans la base de données. La conséquence étaient la loudeur des données dans la base et la baisse de performance de l'affichage du tableau de bord.

Version 3

Les tickets peuvent être archivés un certain temps après qu'ils aient été clos (cf 03 Administration). La base de données est d'autant allégée et l'affichage du tableau de bord plus rapide.

Les tickets archivés ne peuvent plus être ré-ouverts, mais sont quand même accessible dans la base de connaissances (via l'interface de recherche).

Version 2

Les tickets pouvaient être reportés, sans date fixée pour leur traitement.

Version 3

Lors du report d'un ticket, le gestionnaire peut préciser une date à laquelle le ticket sera automatiquement rappelé par une tâche asynchrone (cf 03 Administration).