Re: [Glpi-dev] Fonctionalité : Lieu de tickets
Bonjour, tout d'abord désolé pour le délai de la réponse. j'ai ajouté votre proposition au ticket en cours sur le sujet. Le ticket a également été positionné pour la 0.84. Je pense qu'il faut continuer à bien définir ce que l'on souhaite faire de ce champ et les différentes méthodes d'alimentation de celui-ci avant de commencer la mise en place. Cordialement, Julien Dombre Le 31/01/2012 19:29, Eltharin a écrit : Bonjour, Voici ma proposition de patch, Celui-ci ne concerne que le fichier ticket.class.php, je travaille en ce moment sur les stats. Il ajoute un champs dans le formulaire, Lors de la création d'un ticket, si le lieu n'est pas saisi, il reprend celui du matériel ou si vide, celui du demandeur. Si cela peut aider qqn. Roman *De :*glpi-dev-boun...@gna.org [mailto:glpi-dev-boun...@gna.org] *De la part de* Julien Dombre *Envoyé :* lundi 30 janvier 2012 15:11 *À :* glpi-dev@gna.org *Objet :* Re: [Glpi-dev] Fonctionalité : Lieu de tickets Bonjour, cette demande est déjà remontée effectivement. Voir le ticket suivant : https://forge.indepnet.net/issues/2491 Dans un premier temps il faut bien spécifier ce que l'on souhaite en faire. Le ticket prévoyait un champ libre affecté par les règles métiers. On peut aussi aller plus loin est imaginer un système équivalent à l'auto-assignement des techniciens basé sur la matériel ou la catégorie des tickets. Une configuration disant : affecter le lieu sur le matériel puis l'utilisateur ou l'inverse ou rien du tout. Les 2 solutions n'étant pas contradictoire d'ailleurs. la première chose à faire est de spécifier complètement ce que l'on souhaite faire. Que tout le monde valide les choix mis en place et après mettre en oeuvre ces spécifications. Cordialement, Julien Dombre Le 28/01/2012 10:09, Eltharin a écrit : Bonjour, J'ai une fonctionnalité à proposer pour une version future, Nous utilisons les ticket par rapport à une personne et non par rapport à un matériel, La première raison est que nous recevons 99% des demandes par mail via le collecteur et que donc le champ matériel n'est pas rempli. Je propose donc d'ajouter un champ *Lieu *à un ticket qui réagirait comme ceci : Lors de la création, si le matériel est rempli, on peut affecter son lieu au ticket, sinon celui du demandeur, ou le laisser vide. On peut aussi le modifier manuellement via le formulaire de modification de ticket. Ceci permettrait de pouvoir filtrer sur ce champ, utile par exemple lorsqu'un technicien se déplace sur un site il pourrait lister l'ensemble des tickets de ce lieu et ne pas avoir à tout relire. J'essaie de voir ceci via un plugin (ou un patch). Cordialement, Roman ___ Glpi-dev mailing list Glpi-dev@gna.org mailto:Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Gestion cartes sims
Bonjour, une fois validé l'ensemble des spécifications qui ont été posée sur le wiki, nous pourrons alors lancer la mise en place de ce chantier. Cordialement, Julien Dombre Le 02/03/2012 09:08, walid nouh a écrit : Bonjour Jean-Mathieu, Dans le cadre d'un projet client, je souhe réaliser la gestion des cartes SIM dans GLPI. Mes propositions se trouvent sur la page du wiki suivante : https://forge.indepnet.net/projects/glpi/wiki/GlpiSimcards J'ai regardé et j'ai un peu de mal à voir ce que l'on souhaite faire avec les données renseignées d'un point de vue fonctionnel ? Traitement envisagé ? Rapports ? statistiques ? etc... le besoin ici est de pouvoir gérer correctement les flottes d'abonnement internet mobile. Bien entendu cela sert directement pour les téléphones, mais aussi pour les ordinateurs, etc. Actuellement j'ai des bases clients où les gens rentrent à la mano dans les commentaires les informations comme l'opérateur, le code pin, puk etc. Pour eux ces informations ont un intérêt à être stocké dans GLPI à des fins de support : si l'utilisateur de l'entreprise a bloqué son téléphone, le technicien a directement le code puk, de la même manière, si le collaborateur part, on a le code sim. On peut aussi sortir un état rapidement du nombre de puce par opérateur. De la même manière savoir que tel abonnement a une puce MiniSIM permet de voir tout de suite qu'on ne peut pas la mettre dans un iPhone, etc. C'est donc de la gestion de parc, qui facilitera la vie du helpdesk. Concernant les automatismes, je vois juste l'envoi d'alertes sur les infocoms comme pour les autres types d'objets. Concernant les données, j'envisageais cela comme une gestion classique des périphériques, Du ticket #642 je garde la liaison entre SIM et contrat. Définir ce qui compose un contrat de téléphonie mobile et reporter la consommation tous les mois, ne sort-on pas du contexte d'un gestionnaire de parc ? Je vois bien l'intérêt de ce qui est proposé, je me demande juste si ce n'est pas trop poussé. Niveau statistiques je n'est rien prévu d'autre actuellement que les rapports par défaut. Ci-joint au mail un patch contenant une première version concernant cette fonctionnalité (...) A quelle version s'applique ce patch ? c'est écrit dans le nom du fichier, désolé je n'ai pas précisé mais c'est pour la 0.84. Les propositions intègrent-elle les tickets #642 et #230 ? #642 en partie (cf plus haut), #230 et #498 (pour la partie sim, concernant la partie devices, je n'ai pas encore fait de proposition mais j'ai la demande aussi). Bonne soirée, Merci beaucoup de tes retours et bonne journée à tous, Walid. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Gestion cartes sims
Bonjour Julien, Merci pour ta réponse. Je viens de remettre à jour la page. J'ai ajouté un paragraphe pour les choses qui restent en discussion de mon côté, le reste me semblant assez classique de la gestion d'un objet GLPI. J'ai séparé la gestion des cartes SIM des connexions directes, où là c'est un autre chantier que je décris sur la page https://forge.indepnet.net/projects/glpi/wiki/Extend_Direct_Connections. Walid. On 21/03/2012 09:23, Julien Dombre wrote: Bonjour, une fois validé l'ensemble des spécifications qui ont été posée sur le wiki, nous pourrons alors lancer la mise en place de ce chantier. Cordialement, Julien Dombre Le 02/03/2012 09:08, walid nouh a écrit : Bonjour Jean-Mathieu, Dans le cadre d'un projet client, je souhe réaliser la gestion des cartes SIM dans GLPI. Mes propositions se trouvent sur la page du wiki suivante : https://forge.indepnet.net/projects/glpi/wiki/GlpiSimcards J'ai regardé et j'ai un peu de mal à voir ce que l'on souhaite faire avec les données renseignées d'un point de vue fonctionnel ? Traitement envisagé ? Rapports ? statistiques ? etc... le besoin ici est de pouvoir gérer correctement les flottes d'abonnement internet mobile. Bien entendu cela sert directement pour les téléphones, mais aussi pour les ordinateurs, etc. Actuellement j'ai des bases clients où les gens rentrent à la mano dans les commentaires les informations comme l'opérateur, le code pin, puk etc. Pour eux ces informations ont un intérêt à être stocké dans GLPI à des fins de support : si l'utilisateur de l'entreprise a bloqué son téléphone, le technicien a directement le code puk, de la même manière, si le collaborateur part, on a le code sim. On peut aussi sortir un état rapidement du nombre de puce par opérateur. De la même manière savoir que tel abonnement a une puce MiniSIM permet de voir tout de suite qu'on ne peut pas la mettre dans un iPhone, etc. C'est donc de la gestion de parc, qui facilitera la vie du helpdesk. Concernant les automatismes, je vois juste l'envoi d'alertes sur les infocoms comme pour les autres types d'objets. Concernant les données, j'envisageais cela comme une gestion classique des périphériques, Du ticket #642 je garde la liaison entre SIM et contrat. Définir ce qui compose un contrat de téléphonie mobile et reporter la consommation tous les mois, ne sort-on pas du contexte d'un gestionnaire de parc ? Je vois bien l'intérêt de ce qui est proposé, je me demande juste si ce n'est pas trop poussé. Niveau statistiques je n'est rien prévu d'autre actuellement que les rapports par défaut. Ci-joint au mail un patch contenant une première version concernant cette fonctionnalité (...) A quelle version s'applique ce patch ? c'est écrit dans le nom du fichier, désolé je n'ai pas précisé mais c'est pour la 0.84. Les propositions intègrent-elle les tickets #642 et #230 ? #642 en partie (cf plus haut), #230 et #498 (pour la partie sim, concernant la partie devices, je n'ai pas encore fait de proposition mais j'ai la demande aussi). Bonne soirée, Merci beaucoup de tes retours et bonne journée à tous, Walid. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
[Glpi-dev] Création des utilisateurs
Salut, Pour voir un utilisateur, il faut avoir accès à l'une des entités sur lesquelles il a des droits. En contexte multi-entités, si l'administrateur est positionné sur une sous-entité, lors de la création d'un utilisateur, le profil par défaut est affecté, sur l'entité courante. Dans le cas ou il n'y a pas de profil par défaut (donc création des utilisateurs sans droit par défaut) Actuellement (glpi = 0.83) --- L'ajout est interdit, en effet, l'utilisateur créé sans droit ne sera pas visible, donc la création n'a pas d'intérêt, puisque qu'il sera impossible de le modifier pour lui donner des droits Cela oblige donc a se positionner sur l'entité racine pour tout ajout et interdit l’éventuelle délégation à un admin d'une sous-entité. Prochainement (glpi = 0.84) Cf https://forge.indepnet.net/projects/glpi/repository/revisions/17949 Le formulaire de création de l'utilisateur permet désormais de choisir le profil et l'entité, donc les premiers droits qui seront donnés à l'utilisateur. Cette modification (notamment des contrôles de droit pour l'ajout) mérite des tests approfondis. Merci de vos retours, Remi. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] [glpi] remi | rev 17909 - try to make 'use_slave_for_search' more usable, to be discussed
Le 20/03/2012 13:13, Remi a écrit : Bon, dans l'idéal, il serait bien (pour nous) d'appliquer cette modif en 0.83, qu'on puisse la tester en prod (peut-etre juste après la sortie de la 0.83, il n'y a pas de modif de schéma, juste des nouvelles de langue) Pour avis, Remi. Salut, pas de problème pour moi pour une application en 0.83, vu le peu d'impact de cette fonctionnalité (peu utilisée). Donc pas de problème pour moi. ++ Julien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
[Glpi-dev] Re : [Patch] Possibilité de modifier les dates dans les cartouches
Bonjour, Tout d'abord merci beaucoup ! 2 petites choses : - Vous pouvez effacer la fonction updatesPages, en effet elle ne sert plus la maj des pages est maintenant effectué par updateCartOut, et aussi du coup je crois que l'image actualiser.png ne sert plus. - J'ai remarqué un bug après avoir proposé le patch, c'est par rapport à l'ordre d’affichage des cartouches, elles n'était pas bien ordonnées ce qui pose problème pour le compteur d'impression. Ci joint vous trouverez un patch correctif pour la version 0.83 A par ça tout va bien encore une fois merci ! De : Julien Dombre m...@indepnet.net À : glpi-dev@gna.org Envoyé le : Mercredi 21 mars 2012 10h04 Objet : Re: [Glpi-dev] [Patch] Possibilité de modifier les dates dans les cartouches Bonjour, Patch adapté et appliqué en 0.83. Merci de votre contribution Cordialement, Julien Dombre Le 21/03/2012 09:29, Julien Dombre a écrit : Bonjour, désolé pour la réponse tardive. je viens de déplacer le ticket correspondant (que j'ai découpé en 2). Je vais étudier votre proposition pour une intégration en 0.83. Cordialement, Julien Dombre Le 08/03/2012 09:31, BRICCHI Jérôme a écrit : Bonjour, Pour répondre à un besoin spécifique à notre fonctionnement j'ai du modifier les sources de GLPI : Contexte : Actuellement lors de la remise de cartouche d’encre à un utilisateur, une feuille de papier est renseigné avec la date et la/les modèles de cartouches. La personne qui s’occupe de l’inventaire rassemble ces feuilles toutes les fins de mois pour les saisir dans GLPI. Problème : La saisie pouvant s’effectuer bien après la date de remise, pour des besoins de statistique pertinente, il est impossible d’antidaté une opération. Solution : Dans Inventaire Imprimantes : - Dans Cartouches utilisées, lorsqu’on installe une cartouche possibilité de modifier la Date utilisation. - Dans Cartouches usagées, lorsqu’on passe en Fin de vie une cartouche, possibilité de modifier la Date fin. Screenshot du résultat : Voir en PJ Demandes similaire sur le forum : http://www.glpi-project.org/forum/viewtopic.php?id=4556 http://www.glpi-project.org/forum/viewtopic.php?id=9733 http://www.glpi-project.org/forum/viewtopic.php?id=5740 Un ticket existe mais il parle aussi d'une autre fonctionnalité (tout aussi intéressante), je pense qu'il faudrait les séparer : https://forge.indepnet.net/issues/776 Patch : Ce patch s'applique à la version 0.80.7 de GLPI, j’espère que c'est propre (je suis très loin d’être un expert ) Je vous le propose en espérant qu'il soit intégré à GLPI. D'ailleurs ce serai une bonne idée que cette fonctionnalité s'étende aux autres élément de l'inventaire (exemple : la date d'ajout des consommables) au besoin en ajoutant un droit supplémentaire dans les profils. Bien Cordialement BRICCHI Jérôme Service informatique - Mairie de Saint Laurent du Var ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev cartridge.class.patch Description: Binary data ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Re : [Patch] Possibilité de modifier les dates dans les cartouches
Le 21/03/2012 13:55, BRICCHI Jérôme a écrit : Bonjour, Tout d'abord merci beaucoup ! 2 petites choses : - Vous pouvez effacer la fonction updatesPages, en effet elle ne sert plus la maj des pages est maintenant effectué par updateCartOut, et aussi du coup je crois que l'image actualiser.png ne sert plus. Bonjour, Oui j'ai laissé la fonction qui peut être utilisée pour la mise à jour via un autre moyen (plugin...) - J'ai remarqué un bug après avoir proposé le patch, c'est par rapport à l'ordre d'affichage des cartouches, elles n'était pas bien ordonnées ce qui pose problème pour le compteur d'impression. heu pas complètement d'accord avec votre proposition. Il y a quand même un soucis je pense mais : - pour les anciennes cartouches : tri par date_out ASC, pages ASC (pour le cas ou plusieurs date_out identiques) - pour les cartouches en stock ou en cours d'utilisation : date_use ASC, date_in ASC Si cela vous semble cohérent je mettrais ca en place. Cordialement Julien Ci joint vous trouverez un patch correctif pour la version 0.83 A par ça tout va bien encore une fois merci ! ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
[Glpi-dev] Re : Re : [Patch] Possibilité de modifier les dates dans les cartouches
Oubliez le dernier patch, en fait je me suis trompé c'est pas ce que je voulais faire. - pour les anciennes cartouches : tri par date_out ASC, pages ASC (pour le cas ou plusieurs date_out identiques) Le problème c'est qu'en triant par pages, ça groupe les compteurs quand il sont à 0 et je trouve que c'est beaucoup moins clair pour les renseigner. - pour les cartouches en stock ou en cours d'utilisation : date_use ASC, date_in ASC Je suis ok C'est ce qui me semble être le mieux Cordialement De : Julien Dombre m...@indepnet.net À : glpi-dev@gna.org Envoyé le : Mercredi 21 mars 2012 14h30 Objet : Re: [Glpi-dev] Re : [Patch] Possibilité de modifier les dates dans les cartouches Le 21/03/2012 13:55, BRICCHI Jérôme a écrit : Bonjour, Tout d'abord merci beaucoup ! 2 petites choses : - Vous pouvez effacer la fonction updatesPages, en effet elle ne sert plus la maj des pages est maintenant effectué par updateCartOut, et aussi du coup je crois que l'image actualiser.png ne sert plus. Bonjour, Oui j'ai laissé la fonction qui peut être utilisée pour la mise à jour via un autre moyen (plugin...) - J'ai remarqué un bug après avoir proposé le patch, c'est par rapport à l'ordre d’affichage des cartouches, elles n'était pas bien ordonnées ce qui pose problème pour le compteur d'impression. heu pas complètement d'accord avec votre proposition. Il y a quand même un soucis je pense mais : - pour les anciennes cartouches : tri par date_out ASC, pages ASC (pour le cas ou plusieurs date_out identiques) - pour les cartouches en stock ou en cours d'utilisation : date_use ASC, date_in ASC Si cela vous semble cohérent je mettrais ca en place. Cordialement Julien Ci joint vous trouverez un patch correctif pour la version 0.83 A par ça tout va bien encore une fois merci ! ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev cartridge.class.patch Description: Binary data ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Optimisation consommable.
Salut, patch intégré en partie. N'hésites pas à renvoyer des modifs si nécessaire. ++ Julien Le 19/03/2012 13:19, MoYo a écrit : Le 19/03/2012 06:03, Sylvain Briallon a écrit : Apres les cartouches d'encre, voici les consommables. http://postimage.org/image/4bsa0ilut/ (avant) http://postimage.org/image/dxlugtd0l/ (apres) Les optimisations, - Mise en place du donner à en bas, je ne sais pas si vous apprécierez mais je trouve cela plus parlant. Salut, l'intérêt du donner à en haut est sa position fixe. Avec un donner à en bas, sa position est fonction de la taille de la liste des consommables. Si vous en avez 100 par exemple, atteindre le donner à peut être compliqué. Je regarde tout ca demain. ++ Julien - Correction du pluriel dans l’état utilisé(s) - suppression du supprimer si nous n'avons que les droits en lecture. - suppression de la date d'utilisation dans neufs - et quelques minis trucs... Voila! A vous de me dire ce que vous en pensez. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
