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.
Installation
Déploiement portlet, servlet ou quick-start
Grâce à esup-commons, en renseignant le fichier /build.properties (cf 00 Installation).
Quick-start plus léger
Le déploiement en quick-start n'embarque plus uPortal comme en version 2 mais seulement un Tomcat.
Un seul fichier de configuration
Toutes les propriétés sont réunies dans le fichier de configuration /properties/config.properties (cf 01 Configuration).
L'édition des fichiers Spring et le développement de classes Java n'est nécessaire que pour les personnalisations avancées (cf 02 Personnalisation).
Personnalisation plus facile
Grâce à l'injection de données de Spring.
Changement dans les objets métiers
Catégories
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).
Plus de tickets orphelins
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.
La procédure de migration crée une catégorie dans chaque service pour ranger les tickets orphelins.
Virtualisation
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).
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é
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.
Archivage des tickets
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).
Report des tickets à une date donnée
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).
extraction info sur les utilisateurs
changements dans l'interface
recherche index
Vue d'ensemble
Gestion des contenus