Gestion des gabarits dans GLPI

Introduction

Pour certains types d'objets dans GLPI, il est possible de créer de nouveaux objets (ordinateurs par exemple) en utilisant des modèles prédéfinis. Un modèle définit un modèle de création dans lequel certains champs sont soit déjà fixes, soit calculés à l'aide d'une fonction, par exemple dans le cas d'un ordinateur, une fonction qui calculerait le numéro d'inventaire.

La gestion des modèles est accessible via le bouton Modèles situé dans la barre de menu.

Actifs

Pour les actifs, le modèle définit un objet standard par défaut dans lequel certains champs sont pré-remplis et peuvent être réutilisés ultérieurement pour créer de nouveaux objets. Cela permet de simplifier considérablement l'ajout d'un grand nombre d'objets qui sont presque identiques.

À titre d'exemple, afin de préparer l'inventaire de 20 imprimantes identiques dans lesquelles seuls le numéro de série et le numéro d'inventaire diffèrent :

• tout d'abord, un modèle correspondant à ce modèle d'imprimante serait créé

• dans ce modèle, tous les champs qui ne changeront pas sont remplis (fabricant, modèle...)

• les 20 imprimantes seront alors créées à partir de ce modèle

Lors de la création d'une nouvelle imprimante à partir de ce modèle, le numéro de série et le numéro d'inventaire sont les seuls champs à saisir ; les autres champs sont déjà définis.

Vous pouvez créer rétroactivement un modèle à partir d'un actif en utilisant l'action "Créer un modèle" depuis le menu "Actions" dans le formulaire d'un actif.

Incrément

Un mécanisme de remplissage et d'incrémentation automatique est fourni pour certains champs qui peuvent être identifiés par le . Ces champs (nom, numéro d'inventaire...) sont alors automatiquement complétés lors de la création de l'objet. Pour utiliser ce mécanisme, le champ correspondant dans le modèle doit contenir une chaîne de caractères suivant une syntaxe décrite ci-dessous.

La chaîne de caractères du champ :

• doit commencer par le caractère < et doit se terminer par le caractère >.

• peut contenir les caractères spéciaux suivants qui sont remplacés automatiquement :

  • \g recherche du numéro dans tous les champs identiques basés sur le même format ;

  • # : est remplacé par un compteur ayant autant de chiffres qu'il y a de caractères # consécutifs ;

  • \Y : est remplacé par l'année sur 4 chiffres ;

  • \y : est remplacé par l'année sur 2 chiffres ;

  • \m : est remplacé par le mois ;

  • \d : est remplacé par le jour.

Par exemple, lors de la création d'une imprimante, il est possible dans le modèle d'imprimante d'utiliser ce mécanisme pour générer automatiquement les numéros d'inventaire.

Supposons que nous voulions un numéro d'inventaire sous la forme : ANNÉE+MOIS+JOUR+structure de code fixe égale à 555 + code opération fixe égale à 1234 + COMPTEUR SUR 2 CHIFFRES ; alors le champ numéro d'inventaire dans le modèle sera : <\Y-\m-\d-555-1234-##\>.

À chaque création d'imprimante, la première imprimante aura son numéro d'inventaire sera 1984-JAN-02-555-1234-01, la deuxième imprimante 1984-JAN-02-555-1234-02 et ainsi de suite.

Modèles de tickets

Comme pour les objets d'inventaire, des modèles sont disponibles pour les tickets. Un modèle de ticket permet de personnaliser l'interface de création de ticket en fonction du type et de la catégorie du ticket.

Les comportements qui peuvent être modifiés sont :

• la liste des champs obligatoires pour créer le ticket ;

• la liste des champs dont la valeur est prédéfinie ;

• la liste des champs qui seront masqués.

Pour le contrôle des champs obligatoires, seuls les champs disponibles dans l'interface de l'utilisateur seront contrôlés. Par conséquent, si un champ est défini comme obligatoire mais n'est pas visible dans l'interface, il ne déclenchera pas d'erreur. Lors de la définition des champs obligatoires, les interfaces dans lesquelles ces champs sont utilisés sont affichées.

Un modèle est attaché à l'entité où il a été créé et peut être visible dans les sous-entités.

Des modèles par défaut peuvent être définis au niveau de l'entité ou au niveau du profil. Pour les profils, seuls les modèles de l'entité racine qui sont visibles depuis les sous-entités peuvent être attachés.

Des modèles par défaut peuvent également être définis par catégorie de ticket.

Lors de la création d'un ticket, le modèle utilisé est, par ordre de priorité :

1. Tout d'abord, le modèle défini dans la catégorie et le type sélectionnés

2. Ensuite, le modèle par défaut pour le profil actuel de l'utilisateur

3. Enfin, le modèle par défaut pour l'entité de création du ticket

Dans les deux derniers cas, si le modèle définit un nouveau couple type/catégorie, alors le premier cas est à nouveau testé avec ces nouvelles valeurs.

• Lors de la mise à jour d'un ticket, le même ordre de priorité est appliqué pour déterminer les champs obligatoires.

• Si l'une des entités, profils, types ou catégories de paramètres est modifiée lors du remplissage du ticket, le modèle à utiliser est alors recherché à nouveau selon ces nouvelles valeurs.

• Le modèle est utilisé pour créer des tickets récurrents.