Réflexions sur GLPI / Prises de note

EmpereurZorg · 2006-01-04 15:45:14

Après quelques jours de tests sur le CVS (du 28/12 puis du 02/01), je me permet ces quelques remarques, qui sont avant tout des pistes d'amélioration, voire des incompréhensions de ma part, et appellent donc à des retours/ajouts/clarifications des utilisateurs comme des programmeurs.

Voici donc ce "listing" :
------------------------------
Général / Coeur de GLPI
1. Déplacer la rubrique Plugins dans la partie Administration, avec une vue intermédiaire si besoin pour pouvoir (dés)activer des plugins par exemple. Les plugins ne concernent pas la gestion de parc et il faut simplifier l'accès en ne laissant que les icônes utiles pour l'utilisation du logiciel.
[on oublie]
2. Modularité : si je n'utilise pas la gestion des consommables ou les contrats par exemple, pouvoir (dés)activer certains modules ne serait pas un mal
[prévu post 0.7]
------------------------------
Général / Interface des vues (ordinateurs/moniteurs/...) :
3. Export des vues en cours au format CSV, au lieu de passer par Outils/Rapports/Excel (ou par OCS).
[Youhouhou, c'est maintenant dans les cvs !]
4. Pouvoir ajouter ou masquer des colonnes directement dans les vues en cours et pas dans un menu de configuration.
[déjà intégré !?]
5. Remettre la vue par défaut (celle défini dans le menu conf) quand on revient sur cette vue.
[bouton reset à voir]
6. Définir des modèles de recherche pour ceux qui utilisent souvent les mêmes filtres (ex. simple : "pc portable de Paris" = "type notebook" + "lieu Paris")
[idée à suivre]
7. Possibilité de cocher des matériels dans les vues pour y effectuer des opérations répétitive plus facilement. Par exemple sélectionner des PC inférieurs à 500 MHz pour les passer dans un état "Remplacement à prévoir". (Interface à définir !)
[prévu]
------------------------------
Inventaire / Ordinateurs :
8. L'affectation d'une prise réseau n'est pas simple ni à trouver, ni à remplir ! Création des prises, ajout d'un port, un logical number (?), l'ip (dhcp ? Import OCS ?), etc... Associer directement un(des) numéro(s) de prise(s) à un périphérique réseau ne serait pas plus simple ?
[non, tant pis...]
------------------------------
Inventaire / Moniteurs :
9. L'import OCS remonte des noms d'écran qui ne servent pas à grand chose. J'ai droit à "1024*768", "Ecran par défaut", "S",... serait-il possible d'attribuer le nom du PC sur lequel il est raccordé ? Chez nous, le nom de tout matériel est le nom du PC sur lequel il est raccordé, pour simplifier les demandes utilisateurs (c'est comment ailleurs ?).
[J'ai fait un post séparé dans la partie plugin]
J'essaierai de modifier moi même le plugin OCS pour mon besoin
------------------------------
Inventaire / Etats :
10. L'utilisation du terme "Etats" prête à confusion car également synonyme de "Rapports" (ex. Etat des lieux) : il faudrait mieux utiliser le terme "Statuts".
[ok]
11. Mettre un état par défaut pour les éléments récupérés sur OCS (par ex. "en fonction") : s'ils sont scannés, c'est qu'ils fonctionnent !
[posté]
12. Impossibilitée d'afficher les états "non déterminés" (-----), pour éventuellement les passer dans un autre état.
[pas possible ? C'est d'autant plus dommage que c'est très/trop facile de sortir un matériel de son état ]
------------------------------
Assistance / HelpDesk :
13. La priorité sélectionnée par l'utilisateur est très peu crédible/utile, car ils laisseront par défaut à "Moyennne" ou choisiront "très haute" (c'est bien connu, c'est toujours urgent !). C'est surtout à l'administreur/au tech de juger de la priorité à définir, l'utilisateur pourrait simplement cocher si le problème est bloquant ou non (une case à cocher au lieu de 5 choix).
[Tout dépend de la personne qui remplie, technicien ou simple utilisateur : dans le premier cas, je suis d'accord que l'interface est ok]
------------------------------
Assistance / Plannings :
14. Il y a une vue Journée et Semaine, une vue Mois est manquante (à moins que les gros sites soient trop chargés)...
[ok]
15. Ajouter des bouton "précédent" "suivant" pour pourvoir zapper les semaines plus facilement.
[ok]
------------------------------

C'est tout !
Allez, j'y retourne

a+
Anthony.

Last edited by EmpereurZorg (2006-01-14 00:40:37)

JMD · 2006-01-04 23:57:44

Je répond en numérotant les éléments ( je vous conseille d'editer votre post et d'y ajouter des numéros également, ça n'en sera que plus lisible) :

1) Non, les plugins sont installables que si on le souhaite. Pour ce qui est des icones avec les menus déroulant ça semble tout de meme simple là.

2) Oui, c'est prévu mais aprés la 0.7.

3) Possible mais on s'éloigne fortement du concept de rapport.

4) Déjà fait dans la version cvs

5) Un bouton reset suffirait car la mémorisation de la recherche était une demande de nos utilisateurs.

6) bonne idée.

7) Oui c'est prévu

8) Non

9) Trop spécifique

10) Etat -> statut oui bonne idée.

11) Cela touche le plugin ocs , li faudrait reporter cette remarque dans le forum adhoc. Sinon on va le perdre.

12) Difficile voir impossible de faire autrement.

13) Totalement subjectif et ce que vous proposez ne me semble absolument pas répondre à votre postulat. Si vos utilisateurs mettent toujours urgent, ils mettront de la meme façon bloquant. De toute façon, l'équipe technique a toute lattitude pour reclassifier la priorité d'un ticket.

14) Oui cela manque.

15) Cela manque également.

Voilà j'espère ne pas en avoir oublié. pfiiou

EmpereurZorg · 2006-01-05 11:25:56

Modifié sur le post. Pour les commentaires :

JMD wrote:

(plugins à placer dans configuration)
1) Non, les plugins sont installables que si on le souhaite. Pour ce qui est des icones avec les menus déroulant ça semble tout de meme simple là.

En réfléchissant, effectivement je suis parti d'un mauvais constat. Ce que je pensais c'est qu'un plugin ne devrait pouvoir être configuré que par les "super-admin", en revanche il doivent rester accessible au moins pour certain aux admins... on oublie (j'avais prévenu, il peut y avoir des incompréhensions de ma part !)

(exports CSV)
3) Possible mais on s'éloigne fortement du concept de rapport.

Le but de cette remarque, c'est d'éviter autant que possible de passer par OCS qui lui propose cette solution, pour qu'il n'y ai qu'un seul logiciel réellement utilisé. Souvent, les personnes qui veulent présenter un état des lieux préfèrent passer par des graphiques ou des tableaux sous excel, et cet export permet d'éviter de triturer une quantité importante de données inutiles en exportant que la vue préconfigurée.

(noms d'écran = nom du PC)
9) Trop spécifique

Quelle est donc l'utilité d'avoir des noms de matos non identifiable, puisque la donnée récupérée sur OCS n'est pas standardisée ? (je parle bien des import OCS, pas d'une généralisation du nom de l'écran)
Cela pourrait être au moins être une option du plugin OCS, relégant l'actuel champs nom aux commentaires dans le cas où la donnée serait compréhensible, ce qui est très loin d'être le cas sur mon parc de 400 machines (les données EDID des écrans sont très aléatoires, très peu remontent le numéro de série par exemple)

(modification des priorité)
13) Totalement subjectif et ce que vous proposez ne me semble absolument pas répondre à votre postulat. Si vos utilisateurs mettent toujours urgent, ils mettront de la meme façon bloquant. De toute façon, l'équipe technique a toute lattitude pour reclassifier la priorité d'un ticket.

Subjectif certes, mais il faudrait avoir une remontée réelle de ce que cochent les utilisateurs : si cette option n'est pas utilisée (99% qui laissent par défaut), elle doit disparaître, et si elle est mal utilisée (90% qui laissent par défaut et 9% qui mettent urgent), elle doit être modifiée. Par expérience, il faut comprendre que les gens qui remplissent des demandes (chez nous en tout cas, avec un logiciel interne) le font par obligation et réfléchissent donc le minimum. Si le tech doit penser à modifier à chaque fois, autant que ce soit lui qui remplisse ce champs directement.

Voilà j'espère ne pas en avoir oublié. pfiiou

Mon post n'est pas une critique de glpi, juste des pistes d'amélioration et je n'ai aucune autre légitimité ! J'ai toujours peur de heurter alors que c'est loin d'être mon but, l'écrit étant pour moi plus difficile à nuancer que l'oral, surtout lorsque je dois argumenter.
Merci d'avoir pris le temps de me lire, et aussi de répondre !

Last edited by EmpereurZorg (2006-01-05 15:09:29)

JMD · 2006-01-09 14:27:48

3) (exports CSV)

Le but de cette remarque, c'est d'éviter autant que possible de passer par OCS qui lui propose cette solution, pour qu'il n'y ai qu'un seul logiciel réellement utilisé. Souvent, les personnes qui veulent présenter un état des lieux préfèrent passer par des graphiques ou des tableaux sous excel, et cet export permet d'éviter de triturer une quantité importante de données inutiles en exportant que la vue préconfigurée.

Nous sommes bien d'accord sur cette notion de graphiques et de tableau, c'est une évidence. C'est d'ailleurs pour cela que nous proposons l'export de rapports non pas au format csv mais au format sylk qui permet une exploitation des données dans des tableurs et pas seulement excel...

Vous proposez simplement d'étendre cette notion d'export aux vues obtenues lors des recherches, c'est bien ça ?

Techniquement c'est faisable, mais je vous invite à lire http://glpi.indepnet.org/forum/viewtopic.php?id=1327 pour déterminer la question du qui et du comment.

(noms d'écran = nom du PC)
9) Trop spécifique

Quelle est donc l'utilité d'avoir des noms de matos non identifiable, puisque la donnée récupérée sur OCS n'est pas standardisée ? (je parle bien des import OCS, pas d'une généralisation du nom de l'écran)
(...)

J'aurai tendance à dire que c' est plus un pb au niveau d'OCS que de GLPI.

Quand je disais "trop spécifique", je parlais de la solution que vous proposez : donner le nom du pc à l'écran. C'est un choix de structure, il me semble trés difficile de le généraliser.

J'ai pas de solution au pb pour le moment.

(modification des priorité)
13)

Subjectif certes, mais il faudrait avoir une remontée réelle de ce que cochent les utilisateurs : si cette option n'est pas utilisée (99% qui laissent par défaut), elle doit disparaître, et si elle est mal utilisée (90% qui laissent par défaut et 9% qui mettent urgent), elle doit être modifiée. Par expérience, il faut comprendre que les gens qui remplissent des demandes (chez nous en tout cas, avec un logiciel interne) le font par obligation et réfléchissent donc le minimum. Si le tech doit penser à modifier à chaque fois, autant que ce soit lui qui remplisse ce champs directement.

J'avoue avoir un peu de mal à comprendre que cette notion de priorité vous pose tant de problème. Je comprend vos arguments "si personne l'utilise ou l'utilise mal autant la supprimer" sauf que cela ne me semble pas justifié et spécifique encore une fois à votre structure.

GLPI est utilisé par des structures trés variées avec notament des utilisateurs plus ou moins sensibilises à la problématique informatique. Dans certains cas, c'est même un responsable technique d'un service ou d'un bureau qui utilise le helpdesk pour les ouvertures de tickets. Il me semble que les utilisateurs avancés ou les responsables techniques sont à même de pouvoir proposer une priorité pertinente pour leurs tickets.

Et de toute façon encore une fois, quelle différence flagrante y a t-il entre la situation actuelle sur glpi :

- Ouverture de ticket et définition de priorité -> acceptation ou modification de cette priorité par le technicien

Et celle que vous proposez :

- Ouverture du ticket -> attribution d'une priorité par le technicien

Au pire de toute façon, vous pouvez modifier le helpdesk pour qu'il affecte une priorité par défaut et donc supprimer le choix de la priorité pour vos utilisateurs. C'est ça aussi l'intéret de l'opensource, vous ADAPTEZ à vos besoins.

Mon post n'est pas une critique de glpi, juste des pistes d'amélioration et je n'ai aucune autre légitimité ! J'ai toujours peur de heurter alors que c'est loin d'être mon but, l'écrit étant pour moi plus difficile à nuancer que l'oral, surtout lorsque je dois argumenter.

Je vous rassure, vous n'heurtez personne. De toute façon, si jamais c'était le cas, on a toujours la liberté de ne pas vous répondre ou de vous envoyer promener (gentiment)

EmpereurZorg · 2006-01-09 19:58:31

JMD wrote:

(exports CSV) Nous sommes bien d'accord sur cette notion de graphiques et de tableau, c'est une évidence. C'est d'ailleurs pour cela que nous proposons l'export de rapports non pas au format csv mais au format sylk qui permet une exploitation des données dans des tableurs et pas seulement excel... Vous proposez simplement d'étendre cette notion d'export aux vues obtenues lors des recherches, c'est bien ça ?

Comme je l'ai écris, ces rapports pourraient être beaucoup plus facilement exploitables si déjà épurés en amont, ce qui n'est pas le cas avec les options de rapport actuelles. La meilleure façon de faire étant - à mon sens - d'utiliser un simple icone "export" dans les vues existantes qui permettent ce tri.
Après, CSV, SYLK, ou TXT, Peutimporte (c)Eric&Ramzy

J'ai testé les rapports Sylk, sous OpenOffice.org pas de problème apparent, par contre Excel affiche des messages d'erreurs à l'ouverture :
- "Impossible de lire l'enregistrement xxx. Signaler à chaque erreur ?" Oui/Non
- "Excel ne peut convertir certaines cellules, nombre d'erreur : xxx"
A priori, les champs trop long posent problèmes (périphériques, logiciels, ...) et je m'aperçoit que dans OOo certains de ces champs sont remplis de données dupliquées, ex. une prise réseau = au moins 150 fois la même !

Techniquement c'est faisable, mais je vous invite à lire http://glpi.indepnet.org/forum/viewtopic.php?id=1327 pour déterminer la question du qui et du comment.

Avec l'habitude du logiciel proprio, les décideurs ont un facheux parti pris d'acheter un logiciel fini s'il répond à des besoins, alors que l'OpenSource donne une réponse inverse : nous avons une base qui répond à 80% de vos besoins, et vous avez la possibilité de l'adapter en participant/payant/autre. Il faudra encore un peu de temps pour que les petites sociétés pensent différement, mais je m'acharnerait sur ce point !

Mon "problème" actuel, c'est que je trouve le projet excellent, mais je sais que ce point en particulier (les exports) bloquera son adoption par mes collaborateurs, alors même que OCS a tout de suite accroché pour cette raison (export CSV direct). Avant tout, GLPI serait utilisé chez nous comme base de parc (dans un premier temps), en remplacement d'une solution existante développée en interne. Pour moi, si OCS est un excellent produit d'inventaire, c'est aussi parceque Glpi en décuple ses possibilités sans pour autant être plus complexe à maitriser, au point d'espérer qu'un jour les 2 projets fusionnent en une "petite bombe" !

Il est vrai qu'aujourd'hui l'OpenSource a beaucoup plus d'utilisateurs que de contributeurs, c'est un fait. Mais en l'état - et pour le moment à titre personnel -, je suis bien incapable de réaliser quoi que ce soit en dehors de modifier deux trois champs existants, et encore...
Le mieux que je puisse faire est donc de signaler les bug, et proposer des améliorations (en cherchant à comprendre les choix qui ont été faits), voire faire des docs si le projet est adopté... Mais tout vient à point, je n'exclu pas de parvenir à dompter - un jour - le couple PHP/SQL !

(noms d'écran = nom du PC) J'aurai tendance à dire que c' est plus un pb au niveau d'OCS que de GLPI. Quand je disais "trop spécifique", je parlais de la solution que vous proposez : donner le nom du pc à l'écran. C'est un choix de structure, il me semble trés difficile de le généraliser. J'ai pas de solution au pb pour le moment.

Je crois avoir trouvé le bout de code dans un fichier du plugin OCS, il faut que j'essaye de comprendre comment ça marche pour remplacer la zone nom des moniteurs, et encore mieux si je peux conserver la donnée récupérée dans les commentaires (modifier l'existant, ça passe, mais ajouter sans maîtriser totalement...)
Donc, j'essaye de me débrouiller tout seul là dessus au moins

(modification des priorité)J'avoue avoir un peu de mal à comprendre que cette notion de priorité vous pose tant de problème. Je comprend vos arguments "si personne l'utilise ou l'utilise mal autant la supprimer" sauf que cela ne me semble pas justifié et spécifique encore une fois à votre structure. GLPI est utilisé par des structures trés variées avec notament des utilisateurs plus ou moins sensibilises à la problématique informatique. Dans certains cas, c'est même un responsable technique d'un service ou d'un bureau qui utilise le helpdesk pour les ouvertures de tickets. Il me semble que les utilisateurs avancés ou les responsables techniques sont à même de pouvoir proposer une priorité pertinente pour leurs tickets.

C'est avant tout une question d'échelle effectivement :
- Si ce sont des intervenants techniques qui créent les tickets, ils maîtrisent et remplissent tout les champs correctement, c'est leur métier.
- Par contre dans une entitée où ce sont des utilisateurs "lambda" qui font ces demandes, plus l'interface est simple et mieux est elle exploitée. Une simple case à cocher est beaucoup plus parlante qu'une liste de choix non pertinente à leurs yeux... résultant un ticket d'incident qui correspond mieux à la réalité de la demande.

Je cerne mieux la problématique inverse maintenant, il suffisait de prendre le temps de m'expliquer : bon, maintenant que j'ai compris, à quand le choix de l'interface des tickets en fonction du type d'utilisateur ?

Je vous rassure, vous n'heurtez personne. De toute façon, si jamais c'était le cas, on a toujours la liberté de ne pas vous répondre ou de vous envoyer promener (gentiment)

Allez, je vous embête plus... jusqu'à demain

Last edited by EmpereurZorg (2006-01-09 23:15:47)

JMD · 2006-01-09 23:12:31

J'ai testé les rapports Sylk, sous OpenOffice.org pas de problème apparent, par contre Excel affiche des messages d'erreurs à l'ouverture :
- "Impossible de lire l'enregistrement xxx. Signaler à chaque erreur ?" Oui/Non
- "Excel ne peut convertir certaines cellules, nombre d'erreur : xxx"
A priori, les champs trop long posent problèmes (périphériques, logiciels, ...) et je m'aperçoit que dans OOo certains de ces champs sont remplis de données dupliquées, ex. une prise réseau = au moins 150 fois la même !

Sous excel vous avez testé les rapports sylk limités ou complets ?

Si vous avez testé les complets, les erreurs que vous avez sont normales comme expliqué dans l'aide en ligne si vous avez testé les limités, c'est pas normal et il faudra un peu plus d'infos pour débugger.

EmpereurZorg · 2006-01-09 23:21:04

J'ai testé les 2, la version limité faisait beaucoup moins d'erreur, mais il y en avait bien.
Comme c'était pour répondre au post, je n'ai pas été voir dans la rubrique dans l'aide en ligne, j'y retournerai demain, je n'y pense pas assez à cette aide (excuse bidon : d'habitude, elles ne sont pas très remplies sur les pre-versions des autres logiciels libres... )

Last edited by EmpereurZorg (2006-01-09 23:38:38)

JMD · 2006-01-11 14:19:44

Concernant l'export des vues, on en a discuté et on va en étudier la possibilité.

A suivre donc .

EmpereurZorg · 2006-01-11 18:28:43

JMD wrote:

Concernant l'export des vues, on en a discuté et on va en étudier la possibilité.
A suivre donc .

JMD · 2006-01-13 02:31:13

Maintenant vous pouvez le sortir

Jm0u · 2006-01-13 13:00:10

Clair JMD clap clap pour les rapport je trouve vraiment ça génial

tsmr · 2006-01-13 15:59:23

moi pareil.

Ce serait bien si on pouvait aussi en créer un pour toutes les licences d'un logiciel

EmpereurZorg · 2006-01-14 00:35:31

JMD wrote:

Maintenant vous pouvez le sortir

Arg, et moi qui ne bosse pas le vendredi après midi, j'ai raté ça !
Tant pis, obligé d'attendre lundi pour tester...

Je remets pas la bouteille, mais le coeur y est, merci beaucoup

Jm0u wrote:

Clair JMD clap clap pour les rapport je trouve vraiment ça génial

Bah oui, je ne fais pas que des posts juste pour lancer des défits aux progs, il y a un peu de réflexion quand même
Ca me paraissait "indispensable" comme fonction, et ils l'ont fait qui plus avec un délais impressionnant ! Re-Chapeau !

Last edited by EmpereurZorg (2006-01-14 00:39:33)

Forum GLPI-Project

Announcement

#1 2006-01-04 15:45:14

Réflexions sur GLPI / Prises de note

#2 2006-01-04 23:57:44

Re: Réflexions sur GLPI / Prises de note

#3 2006-01-05 11:25:56

Re: Réflexions sur GLPI / Prises de note

#4 2006-01-09 14:27:48

Re: Réflexions sur GLPI / Prises de note

#5 2006-01-09 19:58:31

Re: Réflexions sur GLPI / Prises de note

#6 2006-01-09 23:12:31

Re: Réflexions sur GLPI / Prises de note

#7 2006-01-09 23:21:04

Re: Réflexions sur GLPI / Prises de note

#8 2006-01-11 14:19:44

Re: Réflexions sur GLPI / Prises de note

#9 2006-01-11 18:28:43

Re: Réflexions sur GLPI / Prises de note

#10 2006-01-13 02:31:13

Re: Réflexions sur GLPI / Prises de note

#11 2006-01-13 13:00:10

Re: Réflexions sur GLPI / Prises de note

#12 2006-01-13 15:59:23

Re: Réflexions sur GLPI / Prises de note

#13 2006-01-14 00:35:31

Re: Réflexions sur GLPI / Prises de note

Board footer