esup-helpdesk




La liste d'utilisateurs n'est pas rendue car vous ne possédez pas les droits d'accès nécessaires pour afficher les profils utilisateur.

Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

Catégories

Section
Column
width50%

 

Version 2

Les structures principales étaient :

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

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

Plus de tickets orphelins orphelins

Section
Column
width50%

 

Version 2

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

Column
width50%

 

Version 3

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

Astuce

La procédure de migration crée une catégorie dans chaque service pour ranger les tickets orphelins.

Virtualisation

Section
Column
width50%

 

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

 
Column
width50%

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.

Ajout du rôle d'invité

Section
Column
width50%

 

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.

 
Column
width50%

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.

Archivage des tickets

Section
Column
width50%

 

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.

Column
width50%

 

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

Report des tickets à une date donnée

Section
Column
width50%

 

Version 2

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

 
Column
width50%

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

...