[GenericObject] Champs non filtrés par type d'objet à l'affichage

Vincenzo · 2012-10-24 23:30:39

Bonjour,

tout d'abord je voulais dire un grand merci à Walid pour ce plugin qui va me rendre de grands services sous peu.

En préparant sa mise en place, je suis tombé sur un bug non répertorié mais qui est lié au n° 3765. Le bug n°3765 corrige le fait que la liste des champs disponibles n'était pas filtrée suivant le type d'objet. Mais la correction proposée ne prend en compte que l'onglet "Champs" des objets (la conception de la liste des champs). Hors, dans la partie formulaire (en saisie ou en prévisualisation), ce filtrage n'est pas fait.

Je rencontre ce problème car je veux redéfinir la valeur du libellé d'un champ standard (le champ "Lieu" dans mon cas) mais seulement pour un type d'objet. J'ai donc surchargé la valeur

$GO_FIELDS['locations_id']['name']

dans un fichier

fields/constants/montype.constant.php

La modification est bien prise en compte dans le formulaire de ce type d'objet particulier mais également dans les autres types d'objet personnalisés.

En cherchant un peu (bcp en fait) comment étendre la modification appliquée au bug n°3765, j'ai pû trouver une solution qui fonctionne dans mon cas. Je vous livre mon patch pour vous guider dans la résolution de ce problème (c'est pê plus parlant que mes explications à rallonge) :

--- object-org.class.php        2012-10-24 23:25:47.181408914 +0200
+++ object.class.php    2012-10-24 23:25:20.961409374 +0200
@@ -246,7 +246,7 @@
    }

    function showForm($id, $options=array(), $previsualisation = false) {
-      global $LANG, $DB;
+      global $LANG, $DB, $GO_FIELDS;

       if ($previsualisation) {
          $canedit = true;
@@ -284,6 +284,11 @@
       if ($previsualisation) {
          echo "<tr><th colspan='4'>".$LANG['genericobject']['config'][8]."</th></tr>";
       }
+
+      //Reset fields definition only to keep the itemtype ones
+      $GO_FIELDS = array();
+      plugin_genericobject_includeCommonFields(true);
+      PluginGenericobjectType::includeConstants($this->objecttype->fields['name'], true);

       foreach (PluginGenericobjectSingletonObjectField::getInstance($this->objecttype->fields['itemtype'])
                as $field => $description) {

Édition : j'ai oubli de préciser qu'il s'agit du fichier

inc/object.class.php

et que je n'ai pas encore fait beaucoup de test pour vérifier que tout va bien malgré cette modification. Si je trouve des problèmes, je les rapporterai dans ce sujet.

Last edited by Vincenzo (2012-10-25 00:04:22)

wawa · 2012-10-26 00:18:38

j'ai eu du mal à comprendre mais c'est ok, effectivement ça se tient
j'ai appliqué votre patch sur la future 2.2.0

merci de votre contribution

Vincenzo · 2012-10-26 02:22:06

Merci beaucoup ça me fera un patch de moins à gérer de mon coté.
J'ai effectivement souvent du mal à me faire comprendre c'est pour ça que j'en mets des tartines .

wawa · 2012-10-26 10:10:06

ça sera pas mal que vous testiez la version en dev, car je fais vraiment bcp de corrections ces jours-ci

Vincenzo · 2012-10-26 12:04:40

Le problème c'est que j'ai la version 0.83.2 de GLPI (la version des dépôts de Debian qui est actuellement gelée en attendant la sortie de la prochaine version stable) donc je m'étais limité à la version 2.1.2 de GenericObject (en rétro-portant les corrections du bug n°3765).
Je vais essayer de monter un environnement de test sous peu, je vous tiendrai au courant lorsque j'aurai avancé.

Vincenzo · 2012-10-27 02:57:22

Voilà, j'ai pu monter un petit environnement de test avec la version sid de Debian (du coup GLPI en version 0.83.31, c'est pas la dernière mais je tiens à essayer de me rapprocher le plus possible d'une gestion des logiciels par les paquets de la distribution pour simplifier la maintenance).
J'ai installé la version "nighty" de GenericObjets datée d'aujourd'hui, 27 octobre 2012 0h34, et taguée 2.2.0 dans GLPI.

Tout fonctionne comme attendu pour le moment (je n'ai pas encore de donnée chargée, je testerai dès que je pourrai l'alimenter et rapporterai l'(es) éventuel(s) problème(s)). En tout cas la gestion des champs spécifiques ou personnalisés pour chaque type d'objet (que ce soit lors de leur affectation ou de leur affichage) est exactement comme prévue, c'est à dire en tenant compte des informations spécifiques à chaque type d'objet.

Encore merci.

wawa · 2012-10-27 09:40:40

parfait
je travaille sur un mécanisme qui regénère automatiquement les fichiers front/ et inc/ à la mise à jour du plugin, histoire de simplifier l'utilisation de celui-ci

je ferme ce post

Forum GLPI-Project

Announcement

#1 2012-10-24 23:30:39

[GenericObject] Champs non filtrés par type d'objet à l'affichage

#2 2012-10-26 00:18:38

Re: [GenericObject] Champs non filtrés par type d'objet à l'affichage

#3 2012-10-26 02:22:06

Re: [GenericObject] Champs non filtrés par type d'objet à l'affichage

#4 2012-10-26 10:10:06

Re: [GenericObject] Champs non filtrés par type d'objet à l'affichage

#5 2012-10-26 12:04:40

Re: [GenericObject] Champs non filtrés par type d'objet à l'affichage

#6 2012-10-27 02:57:22

Re: [GenericObject] Champs non filtrés par type d'objet à l'affichage

#7 2012-10-27 09:40:40

Re: [GenericObject] Champs non filtrés par type d'objet à l'affichage

Board footer