Historique de la page
The division of the establishment into departments is:
- Flexible enough to take into account any existing support structures;
- Discrete enough to respect the natural independence of departments;
- Communicative enough to allow tickets to pass from one department to another one.
To make esup-helpdesk adaptable to any organization, all methods for dividing establishments into departments are authorized. For example, some institutions chose to divide by entity and others by campus.
The complexity of the organization can be masked to users thanks to visibility rules, based on the users' profile and network localization.
Department properties
The interface below shows the department properties:
Users allowed to update the department properties are granted managers.
See: 02 Managers
Enabling departments
Until the corresponding checkbox is not checked, the department is not enabled, i.e. it is visible by the administrators and department managers only.
Astuce | ||
---|---|---|
| ||
Administrators usually enable departments once they are fully configured. |
Virtualization
A department is real by default, i.e. it can hold tickets. It may also be virtual, i.e. redirected to another department, called its real department. In this case, all the tickets created in the virtual department are automatically put into the real department.
One can for instance decide that some parts of the establishment will be represented by virtual departments, each one redirected to a proximity cell (in charge of a whole campus for instance). Several virtual departments can be redirected to a single real one.
Ticket expiration
The expiration time is set for all the tickets of a department (whatever the category).
When this value is left empty, the default value set at application-level is used (see Configuring ticket expiration and archiving).
Filter
This property can be used to limit the visibility of departments to users (see
Le découpage en service proposé par esup-helpdesk est :
- étanche pour assurer l'indépendance des services
- communiquant pour assurer le support au niveau de l'établissement
- configurable pour s'adapter :
- à un support déjà existant
- aux différences de fonctionnement des services
Il s'adapte à la structure complexe des établissements :
- découpage quelconque (par composante administrative, par campus, ...)
- vision adaptative du support
- Masquage de la complexité aux utilisateurs
- En fonction de leur profil et leur localisation
Propriétés des services
L'interface de mise à jour ci-dessous montre les différentes propriétés des services.
Les utilisateurs habilités à modifier les services sont les gestionnaires habilités.
Voir : 02 Les gestionnaires
Activation d'un service
Tant que la case correspondante d'un service n'est pas cochée, le service n'est pas actif, c'est-à-dire qu'il n'est visible que par les administrateurs et les gestionnaires du service.
Astuce | ||
---|---|---|
| ||
Cela peut permettre de configurer le service et de ne le rendre visible que lorsqu'il est bien configuré. |
Virtualisation
Un service est par défaut réel, c'est-à-dire qu'il peut recevoir des tickets. Il peut aussi être virtuel, c'est-à-dire redirigé vers un autre service, appellé son service réel ; dans ce cas, tous les tickets déposés dans le service virtuel sont automatiquement redirigés vers le service réel correspondant.
On pourra par exemple décider que chaque UFR est représentée par un service virtuel, celui-ci étant redirigé vers le service d'une cellule de proximité par campus (plusieurs services d'UFR redirigés vers une même cellule de proximité).
Nombre de jours avant expiration des tickets non approuvés
Le temps d'expiration des tickets est valable pour tous les tickets du service (quelque soit la catégorie du service).
Si cette valeur est laissée vide, la durée par défaut définie au niveau de l'application (cf Configuring ticket expiration and archiving) est utilisée.
Filtre
Cette propriété peut être utilisée pour restreindre la visibilité des services aux utilisateurs (cf Customizing the visibility of the departments by the users).
Visibilité des tickets par défaut
Cette valeur est utilisée pour définir la visibilité par défaut d'une catégorie, lorsque la visibilité par défaut de la catégorie est " par défaut ".
Priorité des tickets par défaut
Cette valeur est utilisée pour définir la priorité par défaut d'une catégorie, lorsque la visibilité par défaut de la catégorie est " par défaut ".
Default ticket visibility
This value sets the default visibility of the tickets, when the visibility set at category-level is 'by default'.
Default ticket priority
This value sets the priority for the tickets, when the value set at category-level is 'by default'. When this value is left empty, the default value set at application-level is used (see Si cette valeur est laissée vide, la valeur utilisée est celle définie au niveau de l'application (cf Configuring the default ticket priority).
Sujet des tickets par défaut
Cette valeur sera utilisée lors de l'ajout de tickets dans des catégories qui utilisent le sujet de ticket par défaut.
Message des tickets par défaut
Cette valeur sera utilisée lors de l'ajout de tickets dans des catégories qui utilisent le message de ticket par défaut.
Assignation automatique
Cette valeur est utlisée pour assigner les tickets de manière automatique à leur création, pour les catégories qui utilisent l'algorithme par défaut.
Default ticket subject
This value sets the subject of new ticket when the value set at category-level is left empty.
Default ticket message
This value sets the message of new ticket when the value set at category-level is left empty.
Automatic assignment
This value sets the default assignment algorithm, used when the algorithm set at category-level is 'by default'. When this value is left empty, the value set at application-level is used (see Si cette valeur est laissée vide, la valeur utilisée est celle définie au niveau de l'application (cf Configuring the automatic ticket assignment).
Inventory URL
...
Cette valeur est utilisée pour afficher des liens depuis les machines des tickets vers une application d'inventaire.
This value is used to build links from ticket machines to an inventory application. When this value is left empty, the value set at application-level is used (see Si cette valeur est laissée vide, la valeur utilisée est celle définie au niveau de l'application (cf Links to an external inventory application).
Mise en oeuvre d'une vision adaptative
Restriction des services visibles par les utilisateurs
Implementing a customized vision of the helpdesk
By default, all the enabled departments are visible by all the users. Deployers can limit the departments that users see when:
- when adding a ticket
- on the control panel
- when browsing the FAQ
See Par défaut, tous les utilisateurs voient tous les services. On peut, grâce à une personnalisation (cf Customizing the visibility of the departments by the users), restreindre les services visibles par les utilisateurs.
Les règles de restriction permettent de cibler les services en fontion :
- du profil des utilisateurs (attributs et/ou groupes LDAP et/ou portail)
- de leur localisation
De cette manière, esup-helpdesk permet de masquer la complexité des établissements en ne montrant aux utilisateurs que les services qu'ils sont sensés connaître, par exemple :
- un service technique correspondant à leur UFR d'attachement et un service de scolarité correspondant à leur campus
- un service dédié aux utilisateurs externes et un autre pour les utilisateurs locaux
- un service par campus et par profil étudiant/personnel
- ...
Couplée à la virtualisation, la restriction de la visibilité des services permet de donner aux utilisateurs une impression de proximité en leur présentant seulement les services virtuels qu'ils sont sensés voir, ceux-ci étant redirigés vers des services réels correspondants aux équipes de personnels techniques et/ou administratifs chargés de traiter les demandes.
.
Visibility rules are based on:
- the users' profile (LDAP and/or portal attributes)
- the user's (network) localization
This way, esup-helpdesk masks the complexity of the helpdesk by showing them only the departments they are interested in, for instance:
- the technical department of their campus and the scolarity department for school problems
- a department dedicated to external users
- a department for the students in a specific traning
- ...
...
Mixed with virtualization, limiting the visibility to interesting departments achieves an adaptative vision of the helpdesk. Deployers can for instance present to users the virtual departments that they have interest in, and redirect those virtual departments to real departments that corresponds to the teams in charge of their problems. This gives the users a strong feeling of proximity.