Re: [Glpi-dev] Nouvelles fonctionnalités GLPI
Le 18/10/2010 14:08, Walid Nouh a écrit : Dans le cadre d'un projet de développement nous souhaiterions apporter Salut, Pouvez-vous nous indiquer les démarches à suivre pour que l'on puisse développer ces fonctionnalités ? (notamment sur la prise en charge de tickets présents dans la forge) Je répond d'abord à cette question car c'est surement la plus importante. Les workflows du projet se trouve ici : https://forge.indepnet.net/projects/glpi/wiki/WorkflowGlpi Si tu as des questions ou des accès que tu n'as pas (genre édition wiki) n'hésite pas. notre contribution à GLPI sous différentes formes : - prendre en charge le développement de tickets déjà présents dans la forge, Toute aide est la bienvenue :) - proposer des nouvelles fonctionnalités pour les prochaines versions, Toutes les idées intéressantes sont les bienvenues :) Pour les nouvelles fonctionnalités, les voici résumées en quelques lignes : 1 : ajouter la possibilité de définir un (des) champ(s) d'unicité dans l'application, permettant ainsi d'éviter au maximum les doublons. C'est une demande de fonctionnalité qui revient très souvent mais qui n'a jamais été suivi des faits faute de temps. Cela pose la problématique générale de la validation des données. Dans l'immédiat, c'est en partie ce que propose de faire le plugin Behavior. Je laisse Julien ou Jean-Mathieu te répondre, car ça me rappelle une discussion lors d'un séminaire. Walid, tu parles de la partie checks ici : https://forge.indepnet.net/projects/glpi/wiki/GlpiImportLib ? La ca va quand même plus loin vu que c'est de la configuration même de l'unicité et non des checks fixes. Mais effectivement il faut pouvoir gérer tout cela de la même manière. Il faudrait donc écrire complètement les specs sur cette partie en essayant d'intégrer les checks globaux dedans. J'ai ouvert un ticket ici : https://forge.indepnet.net/issues/2316 2 : Fusion ocs/glpi - laisser libre l'administrateur de définir ses propres critères de fusion en se basant sur l'ensemble des propriétés disponibles pour un matériel Cela ressemble au ticket https://forge.indepnet.net/issues/2235 et à la page qui va avec : https://forge.indepnet.net/projects/glpi/wiki/ImproveOcsFusion Un moteur de règle semble la bonne solution, avec une action pour refuser l'import d'un matériel suivant certains critères (voir la page wiki). Effectivement c'est une réflexion en cours. Pour la table des matos rejetés pour liaison, ça me semble plus concerner massocsimport non ? Je rappelle quand même qu'il est prévu que la synchro OCS sorte en plugin avec intégration de la partie mass ocs import dedans si mes souvenirs sont bons... 3 : Donner la possibilité de traiter automatiquement le transfert d’une entité à l’autre sur un changement de valeur du TAG : une là on touche à un point sensible. Personnellement je n'étais pas trop pour ce genre de choses mais il faudrait que tu expliques dans le détail comment tu vois les choses. Sachant que le TAG ocs n'est actuellement pas stocké dans la DB de GLPI, cela voudrait dire le rajouter ? Ca serait bien que tu fasses une page de specs pour expliquer ce que tu proposes de ce côté là, et exactement ce qu'on t'a demandé. Tout à fait d'accord avec Walid. Nécessite des specs pour voir les choses plus clairement. 4 : Pouvoir supprimer réinitialiser le lien OCS/GLPI à discrétion par machine et non plus en globalité : amélioration de l'interface existante, lorsque l'utilisateur final clique sur « Nettoyage des liens GLPI / OCSNG » depuis le menu « Outils OCSNG » il arrive sur cette interface et il peut choisir sur quel matériel réaliser l'opération, ou alors de lancer l'opération de manière globale comme actuellement (les habilitations seront aussi à mettre en place pour cette fonctionnalité). donc tu veux dire une interface avec filtrage par entité ? Idem. ++ Julien ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Nouvelles fonctionnalités GLPI
Le 19/10/2010 10:26, MoYo a écrit : Le 18/10/2010 14:08, Walid Nouh a écrit : Dans le cadre d'un projet de développement nous souhaiterions apporter Salut, Pouvez-vous nous indiquer les démarches à suivre pour que l'on puisse développer ces fonctionnalités ? (notamment sur la prise en charge de tickets présents dans la forge) Je répond d'abord à cette question car c'est surement la plus importante. Les workflows du projet se trouve ici : https://forge.indepnet.net/projects/glpi/wiki/WorkflowGlpi Si tu as des questions ou des accès que tu n'as pas (genre édition wiki) n'hésite pas. notre contribution à GLPI sous différentes formes : - prendre en charge le développement de tickets déjà présents dans la forge, Toute aide est la bienvenue :) - proposer des nouvelles fonctionnalités pour les prochaines versions, Toutes les idées intéressantes sont les bienvenues :) Pour les nouvelles fonctionnalités, les voici résumées en quelques lignes : 1 : ajouter la possibilité de définir un (des) champ(s) d'unicité dans l'application, permettant ainsi d'éviter au maximum les doublons. C'est une demande de fonctionnalité qui revient très souvent mais qui n'a jamais été suivi des faits faute de temps. Cela pose la problématique générale de la validation des données. Dans l'immédiat, c'est en partie ce que propose de faire le plugin Behavior. Je laisse Julien ou Jean-Mathieu te répondre, car ça me rappelle une discussion lors d'un séminaire. Walid, tu parles de la partie checks ici : https://forge.indepnet.net/projects/glpi/wiki/GlpiImportLib ? La ca va quand même plus loin vu que c'est de la configuration même de l'unicité et non des checks fixes. Mais effectivement il faut pouvoir gérer tout cela de la même manière. Il faudrait donc écrire complètement les specs sur cette partie en essayant d'intégrer les checks globaux dedans. J'ai ouvert un ticket ici : https://forge.indepnet.net/issues/2316 j'ai fait une page à complèter associée au ticket. 2 : Fusion ocs/glpi - laisser libre l'administrateur de définir ses propres critères de fusion en se basant sur l'ensemble des propriétés disponibles pour un matériel Cela ressemble au ticket https://forge.indepnet.net/issues/2235 et à la page qui va avec : https://forge.indepnet.net/projects/glpi/wiki/ImproveOcsFusion Un moteur de règle semble la bonne solution, avec une action pour refuser l'import d'un matériel suivant certains critères (voir la page wiki). Effectivement c'est une réflexion en cours. pour moi il faut juste une validation de ce qui est écrit. Techniquement il n'y a pas trop de soucis sur cette partie. Il faudra modifier OcsServer::importComputer() et OcsServer::getComputersAlreadyImported(). Pour la table des matos rejetés pour liaison, ça me semble plus concerner massocsimport non ? Je rappelle quand même qu'il est prévu que la synchro OCS sorte en plugin avec intégration de la partie mass ocs import dedans si mes souvenirs sont bons... oui, et actuellement dans le plugin massocsimport on a une liste des matériels non importés. il faut logger en base l'information qu'une machine devant être affecter à telle entité (après passage dans le moteur de règles) n'a pas pu être importé car elle n'a pas vérifié les règles de liaison. on rajoute dans le plugin une interface, par entité, de visualitation/import des machines. Walid. ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Nouvelles fonctionnalités GLPI
Le 12/10/2010 12:01, François LEGASTELOIS a écrit : Bonjour à tous, Bonjour François, Dans le cadre d'un projet de développement nous souhaiterions apporter notre contribution à GLPI sous différentes formes : - prendre en charge le développement de tickets déjà présents dans la forge, - proposer des nouvelles fonctionnalités pour les prochaines versions, - et ouvrir de nouveaux tickets dans la Roadmap si ces fonctionnalités sont validées. Pour les nouvelles fonctionnalités, les voici résumées en quelques lignes : 1 : ajouter la possibilité de définir un (des) champ(s) d'unicité dans l'application, permettant ainsi d'éviter au maximum les doublons : cela sous la forme d'une interface dans la Configuration Générale de l'inventaire qui pourrait s'appeler Unicité des matériels et qui permettra pour chaque type de matériel pour une Entité particulière (ou pour tous les matériels dans toutes les entités) de définir les critères (les champs sur lesquels s'appuyer) qui définissent l'unicité. Elle sera optionnelle, si l'administrateur décide de ne pas mettre en place ses propres règles d'unicité, les traitements d'imports/d'ajout dans la base de données de GLPI se réaliseront alors exactement de la même façon qu'actuellement. Afin de faciliter la gestion des problèmes d'import on pourra également permettre aux administrateurs de consulter les problèmes qui sont apparus lors des différents traitements réalisés avant ajout d'item dans la base de données (import fichiers, saisie manuelle, synchronisation OCS Inventory NG) via une (autre) nouvelle interface. Cela pose la problématique générale de la validation des données. Dans l'immédiat, c'est en partie ce que propose de faire le plugin Behavior. Je laisse Julien ou Jean-Mathieu te répondre, car ça me rappelle une discussion lors d'un séminaire. 2 : Fusion ocs/glpi - laisser libre l'administrateur de définir ses propres critères de fusion en se basant sur l'ensemble des propriétés disponibles pour un matériel : actuellement, dans GLPI, il n'est possible de définir que 4 critères d'existance pour réaliser la fusion des matériels présents dans GLPI avec ceux présents dans OCS. Le développement de cette fonctionnalité passera par l'amélioration de l'interface existante, et permettra de définir pour chaque type de matériel (ou pour tous les types) les champs à prendre en compte pour réaliser les fusions. Cette fonctionnalité pourra être couplée avec une nouvelle interface qui listera avec précision les matériels (soit entité/entité, soit de manière globale) qui n'ont pas pu être fusionné entre OCS et GLPI. Elle permettra également de réaliser les actions nécessaire à la résolution de ces problèmes de fusion : soit par fusion manuelle avec une machine existante, soit par proposition de redéfinition des champs qui ont bloqués l'import et relance manuelle de celui-ci. Cela ressemble au ticket https://forge.indepnet.net/issues/2235 et à la page qui va avec : https://forge.indepnet.net/projects/glpi/wiki/ImproveOcsFusion Un moteur de règle semble la bonne solution, avec une action pour refuser l'import d'un matériel suivant certains critères (voir la page wiki). Pour la table des matos rejetés pour liaison, ça me semble plus concerner massocsimport non ? 3 : Donner la possibilité de traiter automatiquement le transfert d’une entité à l’autre sur un changement de valeur du TAG : une nouvelle interface va permettre de définir les actions à réaliser lors d'un changement de TAG. Elle pourra être intégrée dans un nouvel onglet du mode OCSNG de GLPI et reste optionnelle par défaut (pour ne pas perturber les actions déjà en place actuellement). là on touche à un point sensible. Personnellement je n'étais pas trop pour ce genre de choses mais il faudrait que tu expliques dans le détail comment tu vois les choses. Sachant que le TAG ocs n'est actuellement pas stocké dans la DB de GLPI, cela voudrait dire le rajouter ? Ca serait bien que tu fasses une page de specs pour expliquer ce que tu proposes de ce côté là, et exactement ce qu'on t'a demandé. 4 : Pouvoir supprimer réinitialiser le lien OCS/GLPI à discrétion par machine et non plus en globalité : amélioration de l'interface existante, lorsque l'utilisateur final clique sur « Nettoyage des liens GLPI / OCSNG » depuis le menu « Outils OCSNG » il arrive sur cette interface et il peut choisir sur quel matériel réaliser l'opération, ou alors de lancer l'opération de manière globale comme actuellement (les habilitations seront aussi à mettre en place pour cette fonctionnalité). donc tu veux dire une interface avec filtrage par entité ? Pouvez-vous nous indiquer les démarches à suivre pour que l'on puisse développer ces fonctionnalités ? (notamment sur la prise en charge de tickets présents dans la forge) je laisse Julien ou Jean-Mathieu répondre à ces questions :) Walid.
[Glpi-dev] Nouvelles fonctionnalités GLPI
Bonjour à tous, Dans le cadre d'un projet de développement nous souhaiterions apporter notre contribution à GLPI sous différentes formes : - prendre en charge le développement de tickets déjà présents dans la forge, - proposer des nouvelles fonctionnalités pour les prochaines versions, - et ouvrir de nouveaux tickets dans la Roadmap si ces fonctionnalités sont validées. Pour les nouvelles fonctionnalités, les voici résumées en quelques lignes : 1 : ajouter la possibilité de définir un (des) champ(s) d'unicité dans l'application, permettant ainsi d'éviter au maximum les doublons : cela sous la forme d'une interface dans la Configuration Générale de l'inventaire qui pourrait s'appeler Unicité des matériels et qui permettra pour chaque type de matériel pour une Entité particulière (ou pour tous les matériels dans toutes les entités) de définir les critères (les champs sur lesquels s'appuyer) qui définissent l'unicité. Elle sera optionnelle, si l'administrateur décide de ne pas mettre en place ses propres règles d'unicité, les traitements d'imports/d'ajout dans la base de données de GLPI se réaliseront alors exactement de la même façon qu'actuellement. Afin de faciliter la gestion des problèmes d'import on pourra également permettre aux administrateurs de consulter les problèmes qui sont apparus lors des différents traitements réalisés avant ajout d'item dans la base de données (import fichiers, saisie manuelle, synchronisation OCS Inventory NG) via une (autre) nouvelle interface. 2 : Fusion ocs/glpi - laisser libre l'administrateur de définir ses propres critères de fusion en se basant sur l'ensemble des propriétés disponibles pour un matériel : actuellement, dans GLPI, il n'est possible de définir que 4 critères d'existance pour réaliser la fusion des matériels présents dans GLPI avec ceux présents dans OCS. Le développement de cette fonctionnalité passera par l'amélioration de l'interface existante, et permettra de définir pour chaque type de matériel (ou pour tous les types) les champs à prendre en compte pour réaliser les fusions. Cette fonctionnalité pourra être couplée avec une nouvelle interface qui listera avec précision les matériels (soit entité/entité, soit de manière globale) qui n'ont pas pu être fusionné entre OCS et GLPI. Elle permettra également de réaliser les actions nécessaire à la résolution de ces problèmes de fusion : soit par fusion manuelle avec une machine existante, soit par proposition de redéfinition des champs qui ont bloqués l'import et relance manuelle de celui-ci. 3 : Donner la possibilité de traiter automatiquement le transfert d’une entité à l’autre sur un changement de valeur du TAG : une nouvelle interface va permettre de définir les actions à réaliser lors d'un changement de TAG. Elle pourra être intégrée dans un nouvel onglet du mode OCSNG de GLPI et reste optionnelle par défaut (pour ne pas perturber les actions déjà en place actuellement). 4 : Pouvoir supprimer réinitialiser le lien OCS/GLPI à discrétion par machine et non plus en globalité : amélioration de l'interface existante, lorsque l'utilisateur final clique sur « Nettoyage des liens GLPI / OCSNG » depuis le menu « Outils OCSNG » il arrive sur cette interface et il peut choisir sur quel matériel réaliser l'opération, ou alors de lancer l'opération de manière globale comme actuellement (les habilitations seront aussi à mettre en place pour cette fonctionnalité). Pouvez-vous nous indiquer les démarches à suivre pour que l'on puisse développer ces fonctionnalités ? (notamment sur la prise en charge de tickets présents dans la forge) En espérant ne pas avoir été trop long, je vous remercie d'avance pour vos réponses. Bien cordialement, François ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
Re: [Glpi-dev] Nouvelles fonctionnalités GLPI
Salut, Ben ça n'a pas déjà été acté avec la core team comme défini dans l'appel d'offre? je vois pas trop le soucis de la demande là. Cordialement, David DURIEUX Tel : +33 (0)4.74.04.81.34 Port : +33 (0)6.34.99.45.18 Mail : d.duri...@siprossii.com Site Web : http://www.siprossii.com/ SIPROSSII 847 route de Frans (Créacité) 69400 Villefranche sur Saône FRANCE Le Tue, 12 Oct 2010 12:01:09 +0200 François LEGASTELOIS francoislegastel...@gmail.com a écrit: Bonjour à tous, Dans le cadre d'un projet de développement nous souhaiterions apporter notre contribution à GLPI sous différentes formes : - prendre en charge le développement de tickets déjà présents dans la forge, - proposer des nouvelles fonctionnalités pour les prochaines versions, - et ouvrir de nouveaux tickets dans la Roadmap si ces fonctionnalités sont validées. Pour les nouvelles fonctionnalités, les voici résumées en quelques lignes : 1 : ajouter la possibilité de définir un (des) champ(s) d'unicité dans l'application, permettant ainsi d'éviter au maximum les doublons : cela sous la forme d'une interface dans la Configuration Générale de l'inventaire qui pourrait s'appeler Unicité des matériels et qui permettra pour chaque type de matériel pour une Entité particulière (ou pour tous les matériels dans toutes les entités) de définir les critères (les champs sur lesquels s'appuyer) qui définissent l'unicité. Elle sera optionnelle, si l'administrateur décide de ne pas mettre en place ses propres règles d'unicité, les traitements d'imports/d'ajout dans la base de données de GLPI se réaliseront alors exactement de la même façon qu'actuellement. Afin de faciliter la gestion des problèmes d'import on pourra également permettre aux administrateurs de consulter les problèmes qui sont apparus lors des différents traitements réalisés avant ajout d'item dans la base de données (import fichiers, saisie manuelle, synchronisation OCS Inventory NG) via une (autre) nouvelle interface. 2 : Fusion ocs/glpi - laisser libre l'administrateur de définir ses propres critères de fusion en se basant sur l'ensemble des propriétés disponibles pour un matériel : actuellement, dans GLPI, il n'est possible de définir que 4 critères d'existance pour réaliser la fusion des matériels présents dans GLPI avec ceux présents dans OCS. Le développement de cette fonctionnalité passera par l'amélioration de l'interface existante, et permettra de définir pour chaque type de matériel (ou pour tous les types) les champs à prendre en compte pour réaliser les fusions. Cette fonctionnalité pourra être couplée avec une nouvelle interface qui listera avec précision les matériels (soit entité/entité, soit de manière globale) qui n'ont pas pu être fusionné entre OCS et GLPI. Elle permettra également de réaliser les actions nécessaire à la résolution de ces problèmes de fusion : soit par fusion manuelle avec une machine existante, soit par proposition de redéfinition des champs qui ont bloqués l'import et relance manuelle de celui-ci. 3 : Donner la possibilité de traiter automatiquement le transfert d’une entité à l’autre sur un changement de valeur du TAG : une nouvelle interface va permettre de définir les actions à réaliser lors d'un changement de TAG. Elle pourra être intégrée dans un nouvel onglet du mode OCSNG de GLPI et reste optionnelle par défaut (pour ne pas perturber les actions déjà en place actuellement). 4 : Pouvoir supprimer réinitialiser le lien OCS/GLPI à discrétion par machine et non plus en globalité : amélioration de l'interface existante, lorsque l'utilisateur final clique sur « Nettoyage des liens GLPI / OCSNG » depuis le menu « Outils OCSNG » il arrive sur cette interface et il peut choisir sur quel matériel réaliser l'opération, ou alors de lancer l'opération de manière globale comme actuellement (les habilitations seront aussi à mettre en place pour cette fonctionnalité). Pouvez-vous nous indiquer les démarches à suivre pour que l'on puisse développer ces fonctionnalités ? (notamment sur la prise en charge de tickets présents dans la forge) En espérant ne pas avoir été trop long, je vous remercie d'avance pour vos réponses. Bien cordialement, François ___ Glpi-dev mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
