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
