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 mailing list Glpi-dev@gna.org https://mail.gna.org/listinfo/glpi-dev
