Développement de la gestion des SLA

floNe · 2008-07-23 11:56:27

Bonjour,

Je suis stagiaire dans une entreprise qui souhaite migrer vers GLPI. Nous sommes deux à nous occuper de cette migration, étant concernés à la fois par la partie inventaire et la partie helpdesk.

Le service souhaite cependant configurer GLPI pour qu'il corresponde parfaitement à ses besoins. J'ai bien sur soulevé le problème d'évolution qui en résulte, à quoi l'on m'a répondu que l'idée était de modifier au maximum GLPI tout en gardant une certaine facilité de migration vers les versions supérieures.

Si je vous interpelle, c'est parce qu'une des priorités du service est la gestion des SLA et en particulier la priorisation des tickets par rapport aux engagements (pour un choix immédiat du support pour savoir quel incident traité).

Il m'est donc demandé de développer cette fonctionnalité soit directement dans le code source, soit sous forme de plugin. Notre problématique ne correspond pas exactement au ticket de développement ouvert sur les SLA. Je vous demande donc votre avis sur la question, sachant que bien entendu tout le travail que je fournirais sera mis à votre disposition à la fin mais que je ne peux prendre en charge l'intégralité de votre ticket.

En bref, il y a t-il d'autres personnes intéressées et/ou ayant commencées un développement ?
Me conseillez-vous le dévelopement sous forme d'un plugin ?
Etes-vous intéressés par les sources qui en résulteront ?
etc ...

Merci

remi · 2008-07-23 12:27:57

floNe wrote:

... l'idée était de modifier au maximum GLPI tout en gardant une certaine facilité de migration vers les versions supérieures.

Donc il faut faire un plugin.

floNe wrote:

Notre problématique ne correspond pas exactement au ticket de développement ouvert sur les SLA.

Merci de décrire précisément votre besoin et en quoi ce qui est inscrit dans le ticket n'est pas adapté. Les développement n'ont pas encore commencé et les spec ne sont pas définitives.

++

IronTUX · 2008-07-23 13:40:55

une des grosses parties à faire dans GLPI

floNe · 2008-07-24 12:29:08

Notre besoin de SLA passe par l'ajout de champs dans la fiche incident en particulier criticité et complexité.

Ces deux champs permettent de qualifier la priorité de l'incident et le temps de résolution attribué. Ce ne serait donc plus à l'utilisateur de qualifier la priorité mais au support de renseigner les champs criticité et complexité lors de l'attribution du ticket.

Il y a de plus quelques champs annexes que souhaite ajouter mon entreprise.

Le problème :
- sous forme de plugin : il est difficile de réutiliser tout l'existant en adjoignant uniquement certains champs et un nouvel ordre de tri.
- en hackant : on perd toute possibilité d'évolution.

A combien chiffrez-vous la différence de charge de travail entre un développement plugin et un hack?

Merci.

Last edited by floNe (2008-07-24 12:29:53)

remi · 2008-07-24 12:44:40

Et ça ne correspond pas à ça : https://dev.indepnet.net/glpi/wiki/Impa … tyPriority ?

++

floNe · 2008-07-24 12:51:27

Si cela correspond à la différence près que chez nous ce n'est pas l'utilisateur qui définit l'urgence (criticité) mais le support et les termes (ce qui n'est pas très important).

Nous pouvons donc surement tomber d'accord sur de nombreux points.

floNe · 2008-08-11 11:08:12

Je commence le calcul des SLA.

Je suis confronté à un problème de taille, la gestion des horaires d'ouvertures. Nous avons déterminé pour chaque couple criticité/complexité un temps de résolution max. Je dois donc dans un premier temps remplir le champ date limite (rajouté).

Le problème est que l'on désire enlever les heures de fermetures (18h-9h + week-end et jours fériés) à cette date limite. Je pensais utiliser le planning mais je vous demande avant si vous auriez une idée plus simple?

Merci.

Last edited by floNe (2008-08-11 11:08:47)

MoYo · 2008-08-11 11:55:33

vous voulez que l'on vous aide sur un développement spécifique qui va vous bloquer au moment des prochaines mises à jour.
Les SLAs sont dans le roadmap de GLPI, toutes les spécifications sont déjà faites.
Au lieu de faire quelque chose dans votre coin, je pense qu'il y a d'autres moyens de contribuer intelligemment pour que les SLAs soient intégrées le plus rapidement possible dans une version officielle.

floNe · 2008-08-12 11:04:00

Je suis bien d'accord avec vous, le seul problème est le temps. Je suis dans une entreprise qui ne dispose pas de développeurs en cdi. Ils prennent des stagiaires pendants l'été pour leurs développements spécifiques.

Le fait est que je suis arrivé alors qu'un cahier des charges et une mission précise m'étaient assignés. Il faut lors de mon départ que la mission soit remplie et notamment la gestion des SLA. Il ne me reste que deux semaines et demi pour finir tout ça.

Alors oui bien sur j'aurais aimé récupérer le ticket sur les SLA et contribuer plus intelligemment. Cependant, le temps ne permet pas de faire quelque chose de joli et configurable mais simplement qui puisse fonctionner pendant un an.

Voilà tout je n'ai peut-être pas l'air de contribuer activement au projet glpi (et je ne le fais effectivement pas). Pourtant, je pense que lorsque je vous fournirai mon code à la fin du stage certaines idées pourront vraisemblablement être reprises et faciliter le travail du développeur en charge des SLA, voir vous servir pour d'autres parties (notamment la disposition graphiques des éléments, etc).

(Pour répondre à ma question, j'utiliserais le planning pour les horaires et une fonction php pour les week ends et jours fériés).

JMD · 2008-08-15 14:02:03

Bonjour,

Nous ne vous reprochons pas de ne pas contribuer personnellement. Il n'y a d'ailleurs rien de personnel dans l'histoire.
Vous faites ce que vous pouvez avec les contraintes que vous avez. Nous le comprenons parfaitement.

Maintenant du point de vue du principe ça nous gonfle. Tous les étés, on observe le défilé des stagiaires qui doivent réaliser de la customisation de GLPI pour leurs structures.

A chaque fois ces structures ne prennent absolument pas la peine de se poser la question de la contribution intelligente au projet et se focalisent sur leur developpements spécifiques sans voir plus large pour une intégration générique.

Quelques rares fois, le code est reversé à la communauté (dans une démarche de déculpabiliation) et ce code souvent sale, non documenté et spécifique est tout simplement mis à la poubelle car inexploitable. Je ne dis pas que les stagiaires travaillent systématiquement mal, simplement cela relève de leur statut et surtout de la nature de leur mission. Leur but est de répondre à une commande pas d'intégrer un projet sur le long terme.

Bilan des courses : de l'énergie fournie par la communauté à des stagiaires en pure perte.
(je ne parlerai pas de ceux qui polluent le forum avec des "au secours, c'est urgent, aidez moi, quelqu'un peut me lire la doc etc...").

Voilà pourquoi nous râlons

Forum GLPI-Project

Announcement

#1 2008-07-23 11:56:27

Développement de la gestion des SLA

#2 2008-07-23 12:27:57

Re: Développement de la gestion des SLA

#3 2008-07-23 13:40:55

Re: Développement de la gestion des SLA

#4 2008-07-24 12:29:08

Re: Développement de la gestion des SLA

#5 2008-07-24 12:44:40

Re: Développement de la gestion des SLA

#6 2008-07-24 12:51:27

Re: Développement de la gestion des SLA

#7 2008-08-11 11:08:12

Re: Développement de la gestion des SLA

#8 2008-08-11 11:55:33

Re: Développement de la gestion des SLA

#9 2008-08-12 11:04:00

Re: Développement de la gestion des SLA

#10 2008-08-15 14:02:03

Re: Développement de la gestion des SLA

Board footer