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
