Cette version du plugin s'adresse à une version modifiée de GLPI (voir § installation). Pour la version 0.84.8 d'origine, voir la branche associée.
L'intérêt de cette branche est qu'elle utilise des liens ayant le format de liens utilisés dans les futures versions de GLPI, et est donc plus 'futur-proof'.
Ce plugin a pour objectif de fournir des redirection plus 'intelligentes' que ce que peuvent faire les URL de base de GLPI. L'objectif n'est pas d'ajouter des fonctionnalités à GLPI à proprement parler, mais d'en rendre l'utilisation plus naturelle et d'améliorer son confort d'usage, surtout pour des utilisateur occasionnels qui n'en maitrisent pas les subitilités et sont parfois déroutés par son comportement par défaut.
Pour l'instant, on a trois grandes fonctionnalités qui tournent principalement autour de la gestion de tickets, mais les principes sont assez facilement extrapolables à d'autres objets :
Par contexte, j'entend le profil et l'entité. L'objectif est de corriger un comportement aggaçant de GLPI pour les utilisateurs ayant plusieurs profils n'ayant pas tous les mêmes droits : quand je clique sur un lien vers un ticket, c'est mon profil par défaut qui est sélectionné, ce qui fait que si mon profil par défaut n'a pas les droits sur ce ticket, alors que j'ai un autre profil qui les a, GLPI m'envoie promener alors que dans l'absolu, j'ai les droits. (idem pour les entités).
Le principe est le suivant : je peux définir des règles qui permette que le profil soit choisi en fonction du type de lien, de l'entité, de mon rôle sur le ticket et/ou du statut de celui-ci. Par exemple, si j'ai un profil 'technicien', qui m'autorise à traiter les tickets qui me sont attribués, et un profil 'observateur' qui me permet de voir tous les tickets, mais pas de les modifier, je utiliser les deux règles suivantes : 'si mon rôle est 'attribué à', choisir le profil technicien', et 'dans tous les autres cas, je vais choisir le rôle observateur'. Le système de règles fait qu'on peut, si on le souhaite, définir des comportements assez fins, pour peu qu'on se donne le temps de paramétrer tous les cas possibles.
De plus, si jamais le ticket n'est pas visible avec l'entité par défaut sélecionnée après le changement de profil, il élargit autant que possible la vision, en sélectionnant pour les entités 'voir tous'. Notez que si le paramétrage est maladroit, ça peut ne pas être suffisant : le plugin n'est pas intelligent au point de tester si tel ou tel profil offre la vision sur le processus du ticket. Par exemple une règle dit que pour l'entité XXX on sélectionne le profil YYY, mais que le profil YYY ne nous donne aucun droit sur cette entité, on aura quand même l'erreur disant qu'on n'a pas les droits. En principe, si on définit bien les règles, on doit pouvoir l'éviter.
Si je veux informer un collègue d'un ticket, le moyen le plus naturel et de copier-coller l'URL de mon navigateur quand je vois le ticket et de lui envoyer par mail/messagerie instantanée. Or s'il n'est pas déjà authentifié dans GLPI, quand il clique dessus, ça ne marche pas; il sera redirigé vers l'authentification, et se retrouvera sur la page d'accueil. Pas très pratique.
Cette situation a été améliorée à partir de GLPI 0.85, il s'agit donc ici simplement d'une réintégration de cette amélioration dans GLPI 0.84. Cette modification n'est pas un simple plugin, il faut modifier le coeur comme décrit par le fichier glpi-0.84.8.diff
L'idée est que dans certaines situations, on voudrait bien faire un lien qui emmène directement dans GLPI, sur la page de création des tickets, avec un type de ticket et une catégorie déjà sélectionnée. Par exemple, on pourrait vouloir mettre dans un catalogue de service un lien qui emmène directement là où il faut faire les demandes pour tel ou tel service, ou bien si on fait régulièrement des demandes qui se ressemble, on mettrait bien un lien dans les favoris de son navigateur.
Ce plugin permet de définir des liens qui font exactement ça. En suivant le format décrit dans la doc, on peut faire en sorte de présélectionner le profil et/ou l'entité et/ou le type de ticket et/ou la catégorie du ticket, avant d'être redirigé vers la page de création du ticket. Deux inconvéniants :
- le format, sans être compliqué, n'est pas totalement trivial. Il faut être capable d'identifier les id des objets visés, ce qui est assez facile pour quelqu'un qui connait bien l'outil, mais moins pour un utilisateur occasionnel.
- ça encourage à faire des liens depuis l'extérieur de GLPI qui référencent des id d'objets internes à GLPI, ce qui fait que si on supprime des catégories (ou pire, si on les recycle pour autre chose), il faudra bien penser à changer tous les liens externes, ce qui n'est pas nécessairement évident.
Il suffit simplement de remplacer dans l'URL vers le ticket /front/ticket.form.php par /plugins/smartredirect/front/ticket.form.php. Par exemple : http://glpi0848.localhost/plugins/smartredirect/front/ticket.form.php?id=_1234_&forcetab=Ticket$2
Dans le cas où l'utilisateur a désactivé les redirections 'intelligentes', ce lien fonctionnera quand même. Il fera alors une bête redirection.
syntaxe de l'URL : http://glpi0848.localhost/plugins/smartredirect/front/createredir.form.php?profile=123&entity=123&type=123&category=123 où on remplace les 123 par :
- profile = id du profil avec lequel créer le ticket (profil en cours d'utilisation si ignoré)
- entity = id de l'entité (obligatoire)
- type = 1 pour incident, 2 pour demande (obligatoire)
- category = id de la catégorie (obligatoire)
Par exemple :
http://glpi0848.localhost/plugins/smartredirect/front/createredir.form.php?profile=8&entity=5&type=2&category=9pour un ticket de demande avec le profil n° 8, dans l'entité 5, catégorie 9http://glpi0848.localhost/plugins/smartredirect/front/createredir.form.php?entity=5&type=2&category=9pour un ticket au même endroit, mais sans changer le profilhttp://glpi0848.localhost/plugins/smartredirect/front/createredir.form.php?type=2&category=9va afficher un message d'erreur car l'entité n'est pas précisée
Dans le cas où le lien ne serait pas bon (enitié non précisée, non existante, non accessible, catégorie et type non précisés, non exitants, non accessibles avec le profil ou l'entité, ou non compatibles entre eux), un message d'erreur est affiché à l'utilisateur, et ce qui peut être sélectionné l'est (par exemple, si c'est la catégorie qui coince, le profil et l'entité sont tout de même sélectionnés).
Il ne s'agit pas d'un plugin classique : il est nécessaire de modifier le coeur de GLPI pour le faire fonctionner. Rassurez-vous les modifications sont mineures, et ne cassent rien d'existant. Il faut reporter dans cotre GLPI les modifications répertoriées par le fichier glpi-0.84.8.diff
Dans le cas où les lignes ne correspondraient plus à cause d'autres modifications, c'est largement faisable à la main. Seuls 5 fichiers sont concernés, pour ~une dizaine de copier-coller.
La configuration se base sur le plugin ConfigManager, donc gère les héritages de config et personnalisations. On a deux niveaux de configuration : globale, et personnalisation par utilisateurs. Niveau configurations, on a 6 élements de configuration, et un jeu de règles :
- activer ou non le changement de profil à la volée quand on accède à un ticket (par défaut non, réglable de façon globale, surchargeable par l'utilisateur)
- configuration des liens utilisés lors de la redirection vers la création de tickets : Il y en a 5, afin de premettre à l'administrateur de personnaliser ce qui se passe lors de la redirection en fonction du type d'erreur rencontré. Ca a été mis en place pour prendre rendre ce plugin compatible avec la fonctionnalité de uihacks qui force un choix explicite du type de ticket (qu'il faut ici court-circuiter). Mais ça pourrait être utile à d'autres... En cas de doute, laissez vide, il y a toutes les chances que ça marche très bien.
- règles : règle de choix du profil en fonction des caractéristiques du ticket visé (par défaut aucune règle, réglable de façon globale, avec possibilité d'ajouter des règles personnelles). Seule la première règle applicable s'applique (les suivantes seront ignorées), et si aucune règle n'est applicable lorsqu'on clique sur le lien, le profil sélectionné reste le profil par défaut. Une règle pour laquelle les critères sont vrais, mais pour laquelle l'utilisateur n'a pas le profil est considérée comme non applicable (donc on passe à la suivante). La configuration des règles nécessite une bonne connaissance de GLPI, et n'est donc pas très accessible à un utilisateur occasionnel. Telles qu'elles ont été conçues, il est prévu que la configuration générale faite par l'administrateur suffise à la majorité des utilisateurs, et que seuls quelques utilisateurs ayant des rôles particuliers aient besoin de la surcharger.
Afin de permettre l'utilisation des liens 'intelligents' dans les modèles de notification, le plugin définit les valeur suivantes :
##ticket.smartredirect.url##pour l'URL vers le ticket sans préciser l'onglet##ticket.smartredirect.urlapprove##pour l'URL vers le ticket avec l'onglet 'Solution' pré-sélectionné##ticket.smartredirect.urlvalidation##pour l'URL vers le ticket avec l'onglet 'Validation' pré-sélectionné##ticket.smartredirect.urldocument##pour l'URL vers le ticket avec l'onglet 'Documents' pré-sélectionné Il sont à utiliser à la place des tags du même nom sans le '.smartredirect'.
Le principe de la redirection intelligente sur les tickets est très facilement extentible à d'autres objets. Il suffit de créer les fichiers adaptés dans front, et il est possible de s'inspirer de inc/ticket.class.php pour la logique et la sélection de profils et processus.