Re: [Glpi-dev] Patch 0.90 for add massiveaction in calendars to add holidays in one time

[Alexandre Delaunay]

Hello.

Added.
https://forge.indepnet.net/issues/5416
https://forge.indepnet.net/projects/glpi/repository/revisions/23591

I modified some parts before commit : 

- locales
- comments
- minor indentation

Regards.

Alexandre Delaunay 
adelau...@teclib.com 

118, Rue de Rivoli - 75001 Paris 
Tel. +33 1 79 97 02 78 - Fax. +33 1 72 70 31 18 
Facebook | Twitter | www.teclib.com 


- Mail original -
> De: "David DURIEUX" 
> À: glpi-dev@gna.org
> Envoyé: Vendredi 10 Juillet 2015 10:01:32
> Objet: Re: [Glpi-dev] Patch 0.90 for add massiveaction in calendars to add 
> holidays in one time
> 
> Hello,
> 
> Patch fixed (2 bugs inside)
> 
> Best regards,
> --
> David DURIEUX
> Tel : +33 (0)4.82.53.30.53
> Mail : d.duri...@siprossii.com
> Site Web : http://www.siprossii.com/
> 
> SIPROSSII
> Rue des jardins
> 69860 Monsols
> FRANCE
> 
> 
> Le Thu, 9 Jul 2015 09:48:50 +0200
> David DURIEUX  a écrit:
> 
> >Hello,
> >
> >This is a patch propose a new massive action in calendar to add a
> >holiday to many calendars in one time
> >
> >
> >Best regards,
> >--
> >David DURIEUX
> >Tel : +33 (0)4.82.53.30.53
> >Mail : d.duri...@siprossii.com
> >Site Web : http://www.siprossii.com/
> >
> >SIPROSSII
> >Rue des jardins
> >69860 Monsols
> >FRANCE
> 
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch 0.90 for add massiveaction in calendars to add holidays in one time

[David DURIEUX]

Hello,

Patch fixed (2 bugs inside)

Best regards,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Rue des jardins
69860 Monsols
FRANCE


Le Thu, 9 Jul 2015 09:48:50 +0200
David DURIEUX  a écrit:

>Hello,
>
>This is a patch propose a new massive action in calendar to add a
>holiday to many calendars in one time
>
>
>Best regards,
>--
>David DURIEUX
>Tel : +33 (0)4.82.53.30.53
>Mail : d.duri...@siprossii.com
>Site Web : http://www.siprossii.com/
>
>SIPROSSII
>Rue des jardins
>69860 Monsols
>FRANCE
Index: inc/calendar.class.php
===
--- inc/calendar.class.php	(revision 23579)
+++ inc/calendar.class.php	(working copy)
@@ -85,7 +85,8 @@
 
   if ($isadmin) {
  $actions[__CLASS__.MassiveAction::CLASS_ACTION_SEPARATOR.'duplicate'] = _x('button', 'Duplicate');
-  }
+ $actions[__CLASS__.MassiveAction::CLASS_ACTION_SEPARATOR.'addholiday'] = _x('button', 'Add holiday');
+ }
   return $actions;
}
 
@@ -103,6 +104,12 @@
 echo "";
 echo Html::submit(_x('button', 'Duplicate'), array('name' => 'massiveaction'))."";
 return true;
+
+ case 'addholiday' :
+Holiday::dropdown();
+echo "";
+echo Html::submit(_x('button', 'Add holiday'), array('name' => 'massiveaction'))."";
+return true;
   }
 
   return parent::showMassiveActionsSubForm($ma);
@@ -153,6 +160,43 @@
$ma->itemDone($item->getType(), $ids, MassiveAction::ACTION_KO);
 }
 return;
+
+ case 'addholiday' : // For calendar duplicate in another entity
+$input = $ma->getInput();
+if ($input['holidays_id'] > 0) {
+   $holiday = new Holiday();
+   $calendar_holiday = new Calendar_Holiday();
+
+   $holiday->getFromDB($input['holidays_id']);
+   $entities = array(
+  $holiday->getEntityID() => $holiday->getEntityID()
+   );
+   if ($holiday->isRecursive()) {
+  $entities = getSonsOf("glpi_entities", $holiday->getEntityID());
+   }
+
+   foreach ($ids as $id) {
+  $entities_id = CommonDBTM::getItemEntity('Calendar', $id);
+  if (isset($entities[$entities_id])) {
+ $input = array(
+'calendars_id' => $id,
+'holidays_id'  => $input['holidays_id']
+ );
+ if ($calendar_holiday->add($input)) {
+$ma->itemDone($item->getType(), $id, MassiveAction::ACTION_OK);
+ } else {
+$ma->itemDone($item->getType(), $id, MassiveAction::ACTION_KO);
+$ma->addMessage($item->getErrorMessage(ERROR_ON_ACTION));
+ }
+  } else {
+ $ma->itemDone($item->getType(), $id, MassiveAction::ACTION_KO);
+ $ma->addMessage($item->getErrorMessage(ERROR_ON_ACTION));
+  }
+   }
+} else {
+   $ma->itemDone($item->getType(), $ids, MassiveAction::ACTION_KO);
+}
+return;
   }
   parent::processMassiveActionsForOneItemtype($ma, $item, $ids);
}
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch 0.90 for add massiveaction in calendars to add holidays in one time

[David DURIEUX]

Hello,

This is a patch propose a new massive action in calendar to add a
holiday to many calendars in one time


Best regards,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Rue des jardins
69860 Monsols
FRANCEIndex: inc/calendar.class.php
===
--- inc/calendar.class.php	(revision 23579)
+++ inc/calendar.class.php	(working copy)
@@ -85,7 +85,8 @@
 
   if ($isadmin) {
  $actions[__CLASS__.MassiveAction::CLASS_ACTION_SEPARATOR.'duplicate'] = _x('button', 'Duplicate');
-  }
+ $actions[__CLASS__.MassiveAction::CLASS_ACTION_SEPARATOR.'addholiday'] = _x('button', 'Add holiday');
+ }
   return $actions;
}
 
@@ -103,6 +104,12 @@
 echo "";
 echo Html::submit(_x('button', 'Duplicate'), array('name' => 'massiveaction'))."";
 return true;
+
+ case 'addholiday' :
+Holiday::dropdown();
+echo "";
+echo Html::submit(_x('button', 'Add holiday'), array('name' => 'massiveaction'))."";
+return true;
   }
 
   return parent::showMassiveActionsSubForm($ma);
@@ -153,6 +160,43 @@
$ma->itemDone($item->getType(), $ids, MassiveAction::ACTION_KO);
 }
 return;
+
+ case 'addholiday' : // For calendar duplicate in another entity
+$input = $ma->getInput();
+if ($input['holidays_id'] > 0) {
+   $holiday = new Holiday();
+   $calendar_holiday = new Calendar_Holiday();
+
+   $holiday->getFromDB($holiday);
+   $entities = array(
+  $holiday->getEntityID() => $holiday->getEntityID()
+   );
+   if ($holiday->isRecursive()) {
+  $entities = getAncestorsOf("glpi_entities", $holiday->getEntityID());
+   }
+
+   foreach ($ids as $id) {
+  $entities_id = CommonDBTM::getItemEntity('glpi_holidays', $id);
+  if (isset($entities[$entities_id])) {
+ $input = array(
+'calendars_id' => $id,
+'holidays_id'  => $input['holidays_id']
+ );
+ if ($calendar_holiday->add($input)) {
+$ma->itemDone($item->getType(), $id, MassiveAction::ACTION_OK);
+ } else {
+$ma->itemDone($item->getType(), $id, MassiveAction::ACTION_KO);
+$ma->addMessage($item->getErrorMessage(ERROR_ON_ACTION));
+ }
+  } else {
+ $ma->itemDone($item->getType(), $id, MassiveAction::ACTION_KO);
+ $ma->addMessage($item->getErrorMessage(ERROR_ON_ACTION));
+  }
+   }
+} else {
+   $ma->itemDone($item->getType(), $ids, MassiveAction::ACTION_KO);
+}
+return;
   }
   parent::processMassiveActionsForOneItemtype($ma, $item, $ids);
}
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch GLPI coeur qui ajoute des hooks aux items de tickets (>= 0.85.3)

[David DURIEUX]

Patch corrigé, il y avait du code au mauvais endroit

David
++


Le Thu, 12 Feb 2015 10:49:37 +0100
David DURIEUX  a écrit:

>Bonjour,
>
>Voici un patch qui permet d'ajouter des hooks aux plugins afin
>d'afficher ce qu'on veut pour les items de tickets.
>
>Là par exemple, je suis en train de porter le plugin appliance en 0.85,
>et dans ce plugin on crée un applicatif et dans cet applicatif, on peut
>avoir plusieurs items (exemple un 'cluster xx' peut avoir plusieurs
>ordinateurs, un switch...)
>
>Ainsi donc ce patch permet d'ajouter notre classe de relation entre
>le cluster et l'ordinateur en item de ticket
>
>Ainsi il faut rajouter dans le plugin :
>
>Dans le setup.php :
>   $PLUGIN_HOOKS['assign_to_ticket_dropdown']['appliances'] = true;
>   $PLUGIN_HOOKS['assign_to_ticket_itemtype']['appliances'] =
>   array('PluginAppliancesAppliance_Item');
>
>
>assign_to_ticket_dropdown => pour dire qu'on veut afficher une dropdown
>personalisée dans l'ajout d'un item au ticket et va appeler la fonction
>'plugin_appliances_AssignToTicketDropdown'
>
>assign_to_ticket_itemtype => ce sont la liste des itemtypes qui seront
>définis dans la table glpi_items_tickets et pour lequel on appelle la
>fonction 'plugin_appliances_AssignToTicketDisplay' qui va gérer
>l'affichage du tableau dans l'onglets items du ticket
>
>
>Est-ce assez clair?
>
>Si c'est OK, je peux pousser directement sur le dépot ;)
>
>
>Cordialement,
>--
>David DURIEUX
>Tel : +33 (0)4.82.53.30.53
>Mail : d.duri...@siprossii.com
>Site Web : http://www.siprossii.com/
>
>SIPROSSII
>Rue des jardins
>69860 Monsols
>FRANCE
Index: ajax/dropdownTrackingDeviceType.php
===
--- ajax/dropdownTrackingDeviceType.php	(revision 23363)
+++ ajax/dropdownTrackingDeviceType.php	(working copy)
@@ -42,7 +42,23 @@
 && CommonITILObject::isPossibleToAssignType($_POST["itemtype"])) {
$table = getTableForItemType($_POST["itemtype"]);
$rand  = mt_rand();
+   // Custom dropdown
+  $ptypes = array();
+   if (isset($PLUGIN_HOOKS['assign_to_ticket_dropdown'])) {
+  foreach ($PLUGIN_HOOKS['assign_to_ticket_dropdown'] as $plugin => $value) {
+ $ptypes = Plugin::doOneHook($plugin, 'AssignToTicket', array());
+ foreach ($ptypes as $pitemtype => $pvalue) {
+if ($pitemtype == $_POST["itemtype"]) {
+   Plugin::doOneHook($plugin, 'AssignToTicketDropdown', $_POST);
+   exit;
+}
+ }
+  }
+   }
 
+
+
+
// Message for post-only
if (!isset($_POST["admin"]) || ($_POST["admin"] == 0)) {
   echo "".__('Enter the first letters (user, item name, serial or asset number)');
Index: inc/item_ticket.class.php
===
--- inc/item_ticket.class.php	(revision 23363)
+++ inc/item_ticket.class.php	(working copy)
@@ -165,7 +165,7 @@
 * @return Nothing (display)
**/
static function showForTicket(Ticket $ticket) {
-  global $DB, $CFG_GLPI;
+  global $DB, $CFG_GLPI, $PLUGIN_HOOKS;
 
   $instID = $ticket->fields['id'];
 
@@ -290,39 +290,52 @@
 $nb= $DB->numrows($result_linked);
 
 for ($prem=true ; $data=$DB->fetch_assoc($result_linked) ; $prem=false) {
-   $name = $data["name"];
-   if ($_SESSION["glpiis_ids_visible"]
-   || empty($data["name"])) {
-  $name = sprintf(__('%1$s (%2$s)'), $name, $data["id"]);
+   $continue = true;
+   if (isset($PLUGIN_HOOKS['assign_to_ticket_itemtype'])) {
+  foreach ($PLUGIN_HOOKS['assign_to_ticket_itemtype'] as $plugin => $value) {
+ if (in_array($itemtype, $value)) {
+$continue = Plugin::doOneHook($plugin, 'AssignToTicketDisplay',
+array('itemtype'   => $itemtype,
+  'canedit'=> $canedit,
+  'data'   => $data));
+ }
+  }
}
-   if($_SESSION['glpiactiveprofile']['interface'] != 'helpdesk') {
-  $link = Toolbox::getItemTypeFormURL($itemtype);
-  $namelink = "".$name."";
-   } else {
-  $namelink = $name;
-   }
+   if ($continue) {
+  $name = $data["name"];
+  if ($_SESSION["glpiis_ids_visible"]
+  || empty($data["name"])) {
+ $name = sprintf(__('%1$s (%2$s)'), $name, $data["id"]);
+  }
+  if($_SESSION['glpiactiveprofile']['interface'] != 'helpdesk') {
+ $link = Toolbox::getItemTypeFormURL($itemtype);
+ $namelink = "".$name."";
+  } else {
+ $namelink = $name;
+  }
 
-   echo "";
-   if (

[Glpi-dev] Patch GLPI coeur qui ajoute des hooks aux items de tickets (>= 0.85.3)

[David DURIEUX]

Bonjour,

Voici un patch qui permet d'ajouter des hooks aux plugins afin
d'afficher ce qu'on veut pour les items de tickets.

Là par exemple, je suis en train de porter le plugin appliance en 0.85,
et dans ce plugin on crée un applicatif et dans cet applicatif, on peut
avoir plusieurs items (exemple un 'cluster xx' peut avoir plusieurs
ordinateurs, un switch...)

Ainsi donc ce patch permet d'ajouter notre classe de relation entre
le cluster et l'ordinateur en item de ticket

Ainsi il faut rajouter dans le plugin :

Dans le setup.php :
   $PLUGIN_HOOKS['assign_to_ticket_dropdown']['appliances'] = true;
   $PLUGIN_HOOKS['assign_to_ticket_itemtype']['appliances'] =
   array('PluginAppliancesAppliance_Item');


assign_to_ticket_dropdown => pour dire qu'on veut afficher une dropdown
personalisée dans l'ajout d'un item au ticket et va appeler la fonction
'plugin_appliances_AssignToTicketDropdown'

assign_to_ticket_itemtype => ce sont la liste des itemtypes qui seront
définis dans la table glpi_items_tickets et pour lequel on appelle la
fonction 'plugin_appliances_AssignToTicketDisplay' qui va gérer
l'affichage du tableau dans l'onglets items du ticket


Est-ce assez clair?

Si c'est OK, je peux pousser directement sur le dépot ;)


Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Rue des jardins
69860 Monsols
FRANCE
Index: ajax/dropdownTrackingDeviceType.php
===
--- ajax/dropdownTrackingDeviceType.php	(revision 23363)
+++ ajax/dropdownTrackingDeviceType.php	(working copy)
@@ -42,7 +42,23 @@
 && CommonITILObject::isPossibleToAssignType($_POST["itemtype"])) {
$table = getTableForItemType($_POST["itemtype"]);
$rand  = mt_rand();
+   // Custom dropdown
+  $ptypes = array();
+   if (isset($PLUGIN_HOOKS['assign_to_ticket_dropdown'])) {
+  foreach ($PLUGIN_HOOKS['assign_to_ticket_dropdown'] as $plugin => $value) {
+ $ptypes = Plugin::doOneHook($plugin, 'AssignToTicket', array());
+ foreach ($ptypes as $pitemtype => $pvalue) {
+if ($pitemtype == $_POST["itemtype"]) {
+   Plugin::doOneHook($plugin, 'AssignToTicketDropdown', $_POST);
+   exit;
+}
+ }
+  }
+   }
 
+
+
+
// Message for post-only
if (!isset($_POST["admin"]) || ($_POST["admin"] == 0)) {
   echo "".__('Enter the first letters (user, item name, serial or asset number)');
Index: inc/item_ticket.class.php
===
--- inc/item_ticket.class.php	(revision 23363)
+++ inc/item_ticket.class.php	(working copy)
@@ -165,7 +165,7 @@
 * @return Nothing (display)
**/
static function showForTicket(Ticket $ticket) {
-  global $DB, $CFG_GLPI;
+  global $DB, $CFG_GLPI, $PLUGIN_HOOKS;
 
   $instID = $ticket->fields['id'];
 
@@ -325,6 +325,17 @@
echo "";
 }
 $totalnb += $nb;
+ } else {
+if (isset($PLUGIN_HOOKS['assign_to_ticket_itemtype'])) {
+   foreach ($PLUGIN_HOOKS['assign_to_ticket_itemtype'] as $plugin => $value) {
+  if (in_array($itemtype, $value)) {
+ Plugin::doOneHook($plugin, 'AssignToTicketDisplay',
+ array('itemtype'   => $itemtype,
+   'tickets_id' => $instID,
+   'canedit'=> $canedit));
+  }
+   }
+}
  }
   }
 
Index: inc/search.class.php
===
--- inc/search.class.php	(revision 23363)
+++ inc/search.class.php	(working copy)
@@ -3751,7 +3751,7 @@
**/
static function giveItem($itemtype, $ID, array $data, $num, $meta=0,
 array $addobjectparams=array()) {
-  global $CFG_GLPI;
+  global $CFG_GLPI, $PLUGIN_HOOKS;
 
   $searchopt = &self::getOptions($itemtype);
   if (isset($CFG_GLPI["union_search_type"][$itemtype])
@@ -4208,7 +4208,17 @@
  if (is_numeric($key)) {
 if (!empty($val['itemtype'])
 && ($item = getItemForItemtype($val['itemtype']))) {
-   if ($item->getFromDB($val['name'])) {
+   $custom = false;
+   if (isset($PLUGIN_HOOKS['assign_to_ticket_itemtype'])) {
+  foreach ($PLUGIN_HOOKS['assign_to_ticket_itemtype'] as $plugin => $value) {
+ if (in_array($val['itemtype'], $value)) {
+$items[] = Plugin::doOneHook($plugin, 'AssignToTicketGiveItem', $val);
+$custom = true;
+ }
+  }
+   }
+   

Re: [Glpi-dev] Patch 0.85 : Ajout de multiples éléments associés aux tickets

[Tsmr]

 

C'est fait. 

J'ai refait patch avec svn de ce matin - upgrade
0.85.3 OK de mon coté 

Par contre je n'ai pas modifié mon patch avec la
nouvelle variable de session (pour les plurals) 

Cordialement 

Le
22.01.2015 11:23, MoYo a écrit : 

> Bonjour,
> 
> Il me semble qu'il y
a un ticket sur la forge non ?
> Il faudrait :
> - ajouter ces
informations dedans / le patch en particulier 
> - Déplacer le ticket
dans la release souhaitée
> 
> Cordialement
> 
> Le 22/01/2015 11:13,
Tsmr a écrit : 
> 
>> Messieurs dames ? on peut l'integrer en 0.85.3
pour vous ? 
>> 
>> ++ 
>> 
>> Le 05.11.2014 17:35, DUPONT Ludovic a
écrit : 
>> 
>>> Bonjour, 
>>> 
>>> J'ai développé une amélioration de
la liaison des tickets aux éléments de l'inventaire.
>>> Le patch
ci-joint contient la modification pour lier plusieurs éléments aux
tickets. 
>>> 
>>> Lien wiki :
https://forge.indepnet.net/projects/glpi/wiki/Permit_to_link_several_items_to_a_ticket
[1] 
>>> 
>>> Le patch est fait à partir du trunk de GLPI 0.85 (mis à
jour le 05/11/2014 17:30).
>>> 
>>> Liste des éléments impactés : 
>>>

>>> - Ajout d'une nouvelle table et d'une nouvelle classe 
>>> 
>>> -
La règle de copie du lieu de l'élément sur le ticket : action « lieu >
Copier depuis l'élément » 
>>> 
>>> o Le lieu est copié à l'ajout d'un
élément si le lieu du ticket est vide 
>>> 
>>> - Les gabarits de
tickets 
>>> 
>>> - Les tickets (ajout d'un onglet « éléments ») 
>>>

>>> - Affichage des tickets du central 
>>> 
>>> - L'affichage des
tickets associés aux éléments de l'inventaire 
>>> 
>>> - Les
notifications des tickets : 
>>> 
>>> o ajout d'une balise « Foreach
items » pour lister les éléments associés 
>>> 
>>> - Modification de la
requête sur la statistique « Ticket > Par éléments » 
>>> 
>>>
Cordialement,
>> 
>> -- 
>> 
>> Tsmr
>> Xavier CAILLAUD
>> 
>>
___
>> Glpi-dev mailing
list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev

--


Tsmr
Xavier CAILLAUD
 

Links:
--
[1]
https://forge.indepnet.net/projects/glpi/wiki/Permit_to_link_several_items_to_a_ticket
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch 0.85 : Ajout de multiples éléments associés aux tickets

[MoYo]

Bonjour,

Il me semble qu'il y a un ticket sur la forge non ?
Il faudrait :
- ajouter ces informations dedans / le patch en particulier
- Déplacer le ticket dans la release souhaitée

Cordialement

Le 22/01/2015 11:13, Tsmr a écrit :


Messieurs dames ? on peut l'integrer en 0.85.3 pour vous ?

++

Le 05.11.2014 17:35, DUPONT Ludovic a écrit :


Bonjour,

J’ai développé une amélioration de la liaison des tickets aux 
éléments de l’inventaire.
Le patch ci-joint contient la modification pour lier plusieurs 
éléments aux tickets.


Lien wiki : 
https://forge.indepnet.net/projects/glpi/wiki/Permit_to_link_several_items_to_a_ticket


Le patch est fait à partir du trunk de GLPI 0.85 (mis à jour le 
05/11/2014 17:30).


Liste des éléments impactés :

-Ajout d’une nouvelle table et d’une nouvelle classe

-La règle de copie du lieu de l’élément sur le ticket : action « lieu 
> Copier depuis l'élément »


oLe lieu est copié à l’ajout d’un élément si le lieu du ticket est vide

-Les gabarits de tickets

-Les tickets (ajout d’un onglet « éléments »)

-Affichage des tickets du central

-L’affichage des tickets associés aux éléments de l’inventaire

-Les notifications des tickets :

oajout d’une balise « Foreach items » pour lister les éléments associés

-Modification de la requête sur la statistique « Ticket > Par éléments »

Cordialement,


--
Tsmr
Xavier CAILLAUD


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch 0.85 : Ajout de multiples éléments associés aux tickets

[Moron, Olivier]

Ok pour moi,
Merci,
A+

Olivier MORON
Miscellaneous Program Member

RAYNET SNC
Tel : +33 4 76 33 49 52
Fax: +33 4 76 70 56 63


From: Glpi-dev [mailto:glpi-dev-boun...@gna.org] On Behalf Of Tsmr
Sent: Thursday, January 22, 2015 11:14 AM
To: glpi-dev@gna.org
Subject: Re: [Glpi-dev] Patch 0.85 : Ajout de multiples éléments associés aux 
tickets


Messieurs dames ? on peut l'integrer en 0.85.3 pour vous ?

++



Le 05.11.2014 17:35, DUPONT Ludovic a écrit :
Bonjour,

J’ai développé une amélioration de la liaison des tickets aux éléments de 
l’inventaire.
Le patch ci-joint contient la modification pour lier plusieurs éléments aux 
tickets.

Lien wiki : 
https://forge.indepnet.net/projects/glpi/wiki/Permit_to_link_several_items_to_a_ticket

Le patch est fait à partir du trunk de GLPI 0.85 (mis à jour le 05/11/2014 
17:30).

Liste des éléments impactés :

-  Ajout d’une nouvelle table et d’une nouvelle classe

-  La règle de copie du lieu de l’élément sur le ticket : action « lieu 
> Copier depuis l'élément »

o   Le lieu est copié à l’ajout d’un élément si le lieu du ticket est vide

-  Les gabarits de tickets

-  Les tickets (ajout d’un onglet « éléments »)

-  Affichage des tickets du central

-  L’affichage des tickets associés aux éléments de l’inventaire

-  Les notifications des tickets :

o   ajout d’une balise « Foreach items » pour lister les éléments associés

-  Modification de la requête sur la statistique « Ticket > Par 
éléments »

Cordialement,



--

Tsmr
Xavier CAILLAUD
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch 0.85 : Ajout de multiples éléments associés aux tickets

[Tsmr]

 

Messieurs dames ? on peut l'integrer en 0.85.3 pour vous ? 

++ 

Le
05.11.2014 17:35, DUPONT Ludovic a écrit : 

> Bonjour, 
> 
> J'ai
développé une amélioration de la liaison des tickets aux éléments de
l'inventaire.
> Le patch ci-joint contient la modification pour lier
plusieurs éléments aux tickets. 
> 
> Lien wiki :
https://forge.indepnet.net/projects/glpi/wiki/Permit_to_link_several_items_to_a_ticket
[1] 
> 
> Le patch est fait à partir du trunk de GLPI 0.85 (mis à jour
le 05/11/2014 17:30).
> 
> Liste des éléments impactés : 
> 
> - Ajout
d'une nouvelle table et d'une nouvelle classe 
> 
> - La règle de copie
du lieu de l'élément sur le ticket : action « lieu > Copier depuis
l'élément » 
> 
> o Le lieu est copié à l'ajout d'un élément si le lieu
du ticket est vide 
> 
> - Les gabarits de tickets 
> 
> - Les tickets
(ajout d'un onglet « éléments ») 
> 
> - Affichage des tickets du
central 
> 
> - L'affichage des tickets associés aux éléments de
l'inventaire 
> 
> - Les notifications des tickets : 
> 
> o ajout d'une
balise « Foreach items » pour lister les éléments associés 
> 
> -
Modification de la requête sur la statistique « Ticket > Par éléments »

> 
> Cordialement,

-- 

Tsmr
Xavier CAILLAUD
 

Links:
--
[1]
https://forge.indepnet.net/projects/glpi/wiki/Permit_to_link_several_items_to_a_ticket
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] corrections des URLs sur le formulaire de gabarits (lié au plugin genericobject)

[Julien Dombre]

Bonsoir,

les patchs viennent d'être appliqués.

++

Julien


Le 01/10/2014 17:45, Kevin Roy a écrit :

Bonjour,

Voici 2 patches permettant de corriger l'affichage des URLs sur les
différents formulaires de gabarits.

Le premier patch (0.85_fix_form_urls_in_templates_setup.patch) utilise
la fonction getFormURL de la classe associé à l'itemtype directement
dans le formulaire des gabarits.

Le deuxième patch
(0.85_handle_existing_params_in_listTemplates_targets.patch) modifie
la construction des URLs de la fonction CommonDBTM::listTemplates() en
tenant compte des paramètres existants dans le lien d'accès au
formulaire de l'itemtype.

Cordialement,
--
Kevin Roy


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] [PATCH] corrections des URLs sur le formulaire de gabarits (lié au plugin genericobject)

[Kevin Roy]

Bonjour,

Voici 2 patches permettant de corriger l'affichage des URLs sur les
différents formulaires de gabarits.

Le premier patch (0.85_fix_form_urls_in_templates_setup.patch) utilise
la fonction getFormURL de la classe associé à l'itemtype directement
dans le formulaire des gabarits.

Le deuxième patch
(0.85_handle_existing_params_in_listTemplates_targets.patch) modifie
la construction des URLs de la fonction CommonDBTM::listTemplates() en
tenant compte des paramètres existants dans le lien d'accès au
formulaire de l'itemtype.

Cordialement,
--
Kevin Roy
Index: inc/commondbtm.class.php
===
--- inc/commondbtm.class.php	(revision 23167)
+++ inc/commondbtm.class.php	(working copy)
@@ -4175,10 +4175,14 @@
   if ($result = $DB->query($query)) {
  echo "";
  if ($add) {
+$blank_params =
+   (strpos($target, '?') ? '&' : '?')
+   . "id=-1&withtemplate=2";
+$target_blank = $target . $blank_params;
 echo "" . $item->getTypeName(1)."";
 echo "".__('Choose a template')."";
 echo "";
-echo "".__('Blank Template')."";
+echo "".__('Blank Template')."";
 echo "";
  } else {
 echo "".$item->getTypeName(1)."".__('Templates')."";
@@ -4190,8 +4194,14 @@
$templname = sprintf(__('%1$s (%2$s)'), $templname, $data["id"]);
 }
 if ($item->canCreate() && !$add) {
+   $modify_params =
+  (strpos($target, '?') ? '&' : '?')
+  . "id=".$data['id']
+  . "&withtemplate=1";
+   $target_modify = $target . $modify_params;
+
echo "";
-   echo "";
+   echo "";
echo "   $templname   ";
echo "";
Html::showSimpleForm($target, 'purge', _x('button', 'Delete permanently'),
@@ -4199,8 +4209,14 @@
   'id'   => $data['id']));
echo "";
 } else {
+   $add_params =
+  (strpos($target, '?') ? '&' : '?')
+  . "id=".$data['id']
+  . "&withtemplate=2";
+   $target_add = $target . $add_params;
+
echo "";
-   echo "";
+   echo "";
echo "   $templname   ";
 }
 echo "";
@@ -4207,8 +4223,12 @@
  }
 
  if ($item->canCreate() && !$add) {
+$create_params =
+   (strpos($target, '?') ? '&' : '?')
+   . "withtemplate=1";
+$target_create = $target . $create_params;
 echo "";
-echo "" . __('Add a template...') . "";
+echo "" . __('Add a template...') . "";
 echo "";
  }
  echo "\n";
Index: front/setup.templates.php
===
--- front/setup.templates.php	(revision 23167)
+++ front/setup.templates.php	(working copy)
@@ -40,7 +40,7 @@
 
 if (isset($_GET["itemtype"])) {
 
-   $link = Toolbox::getItemTypeFormURL($_GET["itemtype"]);
+   $link = $_GET["itemtype"]::getFormURL();
$item = str_replace(".form.php","",$link);
$item = str_replace("front/","",$item);
 
@@ -61,4 +61,4 @@
 
Html::footer();
 }
-?>
\ No newline at end of file
+?>
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Corrections sur les URLs de tri dans les listes d'inventaire

[Kevin Roy]

2014-09-10 16:03 GMT+02:00 MoYo :
> Le 10/09/2014 15:59, Kevin Roy a écrit :
>
>> 2014-09-10 14:22 GMT+02:00 MoYo :
>>>
>>> est-ce que ce fix n'est pas plus simple :
>>>
>>> https://forge.indepnet.net/projects/glpi/repository/revisions/23158/diff/trunk/inc/search.class.php
>>
>> Ça fonctionne mais ça me rajoute 2 fois l'itemtype en paramètre GET :
>>
>> plugins/genericobject/front/object.php?itemtype=PluginGenericobjectCar&itemtype=PluginGenericobjectCar&sort=1&order=DESC&start=0...
>>
>> L'idée du patch c'était surtout de réutiliser les fonctions communes
>> getSearchURL() comme pour les précédents patchs (c.f.
>> Search::showGenericSearch et Search::prepareDatasForSearch).
>
>
> Oui j'ai bien compris mais normalement le $data['search']['target'] doit
> déjà provenir de ces fonctions donc je ne vois pas trop l'intérêt de le
> recalculer.
> Si 2 fois l'itemtype est génant on peut conditionner sont ajout

Ce n'est pas gênant pour faire le tri, ça rallonge juste l'url.
Par contre je ne comprends pas l'ajout de l'itemtype à cet endroit si
la variable data['search']['target'] contient déjà la base de l'url de
recherche à laquelle on colle les paramètres de tri et de recherche.
Je viens de faire l'essai en enlevant ce paramètre de l'url de
plusieurs type et le tri se fait correctement.

--
Kevin Roy

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Corrections sur les URLs de tri dans les listes d'inventaire

[Kevin Roy]

2014-09-10 14:22 GMT+02:00 MoYo :
> est-ce que ce fix n'est pas plus simple :
> https://forge.indepnet.net/projects/glpi/repository/revisions/23158/diff/trunk/inc/search.class.php

Ça fonctionne mais ça me rajoute 2 fois l'itemtype en paramètre GET :
plugins/genericobject/front/object.php?itemtype=PluginGenericobjectCar&itemtype=PluginGenericobjectCar&sort=1&order=DESC&start=0...

L'idée du patch c'était surtout de réutiliser les fonctions communes
getSearchURL() comme pour les précédents patchs (c.f.
Search::showGenericSearch et Search::prepareDatasForSearch).

Cheers,
--
Kevin Roy

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Corrections sur les URLs de tri dans les listes d'inventaire

[MoYo]

Bonjour,

est-ce que ce fix n'est pas plus simple :
https://forge.indepnet.net/projects/glpi/repository/revisions/23158/diff/trunk/inc/search.class.php

Cordialement

Le 10/09/2014 14:00, Kevin Roy a écrit :

Bonjour,

Actuellement, les URLs de tri des listes d'inventaire ne sont pas
construites avec la méthode getSearchURL() de l'itemtype (ou
Toolbox::getItemtypeSearchUrl() dans le cas de la recherche globale).

Les objets gérés par le plugin GenericObject ne sont plus triables car
les liens ne sont pas valides.

Par exemple, l'url de recherche GenericObject suivante :
/plugins/genericobject/front/object.php?itemtype=PluginGenericobjectCar

l'url de tri devient :
/plugins/genericobject/front/object.php?itemtype=PluginGenericobjectCar?itemtype=PluginGenericobjectCar

Cheers,
--
Kevin Roy


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Construction des URLs de la classe Search à partir des méthodes de CommonGLPI au lieu de Toolbox

[MoYo]

Le 05/09/2014 11:13, Kevin Roy a écrit :

Hello,

2014-07-24 11:18 GMT+02:00 Julien Dombre :

Effectivement c'est plus logique comme ca.
Le patch vient d'être intégré.

Un petit dernier patch pour régler les URLs des types de la page
Configuration > Intitulés que j'avais occultée lors de mes
développements sur le plugin genericobject.


Patch intégré



Cheers,
--
Kevin Roy


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] [PATCH] Corrections sur les URLs de tri dans les listes d'inventaire

[Kevin Roy]

Bonjour,

Actuellement, les URLs de tri des listes d'inventaire ne sont pas
construites avec la méthode getSearchURL() de l'itemtype (ou
Toolbox::getItemtypeSearchUrl() dans le cas de la recherche globale).

Les objets gérés par le plugin GenericObject ne sont plus triables car
les liens ne sont pas valides.

Par exemple, l'url de recherche GenericObject suivante :
/plugins/genericobject/front/object.php?itemtype=PluginGenericobjectCar

l'url de tri devient :
/plugins/genericobject/front/object.php?itemtype=PluginGenericobjectCar?itemtype=PluginGenericobjectCar

Cheers,
--
Kevin Roy
Index: inc/search.class.php
===
--- inc/search.class.php	(revision 23156)
+++ inc/search.class.php	(working copy)
@@ -1257,14 +1257,26 @@
  $metanames = array();
  foreach ($data['data']['cols'] as $key => $val) {
 $linkto = '';
-if (!$val['meta']
-&& (!isset($val['searchopt']['nosort'])
-|| !$val['searchopt']['nosort'])) {
+if (
+   !$val['meta']
+   && (
+  !isset($val['searchopt']['nosort'])
+  || !$val['searchopt']['nosort']
+   )
+) {
 
-   $linkto = $data['search']['target']."?itemtype=".$data['itemtype']."&sort=".
-   $val['id']."&order=".
-   (($data['search']['order'] == "ASC") ?"DESC":"ASC").
-   "&start=".$data['search']['start']."&".$globallinkto;
+   if (class_exists($data['itemtype'])) {
+  $target = $data['itemtype']::getSearchURL();
+   } else {
+  $target = Toolbox::getItemTypeSearchURL($data['itemtype']);
+   }
+
+   $linkto = $target
+ .(strpos($target,'?') ? '&' : '?')
+ ."sort=".$val['id']
+ ."&order="
+ .(($data['search']['order'] == "ASC") ?"DESC":"ASC")
+ ."&start=".$data['search']['start']."&".$globallinkto;
 }
 
 $name = $val["name"];
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Construction des URLs de la classe Search à partir des méthodes de CommonGLPI au lieu de Toolbox

[Kevin Roy]

Hello,

2014-07-24 11:18 GMT+02:00 Julien Dombre :
> Effectivement c'est plus logique comme ca.
> Le patch vient d'être intégré.

Un petit dernier patch pour régler les URLs des types de la page
Configuration > Intitulés que j'avais occultée lors de mes
développements sur le plugin genericobject.

Cheers,
--
Kevin Roy
Index: inc/dropdown.class.php
===
--- inc/dropdown.class.php	(revision 23152)
+++ inc/dropdown.class.php	(working copy)
@@ -894,7 +894,7 @@
 
   foreach ($optgroup as $label => $dp) {
  foreach ($dp as $key => $val) {
-$search = Toolbox::getItemTypeSearchURL($key);
+$search = $key::getSearchURL();
 
 if (basename($search) == basename($value)) {
$selected = $search;
@@ -937,7 +937,7 @@
 && $itemtype->isEntityAssign()) {
$class="class='tab_bg_2'";
 }
-echo "";
+echo "";
 echo "$val\n";
 $i++;
  }
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[nini.lasson]

Bonjour,

L'association est effectivement gérée dans la conf pour le plugin
Appliances.

Donc comme Tsmr, si cela doit être fait, uniquement dans une version
majeur de GLPI, sinon effectivement ça va tout péter.

Bizz
Nelly

Le 03/09/2014 10:03, Julien Dombre a écrit :
> Bonjour,
>
> De mémoire c'était pour que la configuration des plugins ne soit
> faites que dans les plugins.
> J'imagine que certains plugins gèrent l'associabilité directement dans
> la conf de leurs plugins.
> Si on applique ton patch ca voudra dire qu'on bascule complètement
> cette conf dans la conf générale et je n'aimerai pas que ca pète les
> autres plugins.
> C'est faisable mais il faut que les autres mainteneurs de plugins qui
> utilisent cette fonctionnalité valide cette bascule.
>
> Qu'ils se manifestent donc où se taisent à jamais :)
>
> ++
>
> Julien
>
>
>
> Le 02/09/2014 17:30, Kevin Roy a écrit :
>> Bonjour,
>>
>> Actuellement, les plugins peuvent enregistrer des types d'objets pour
>> pouvoir les assigner à un ticket grâce à
>> $PLUGIN_HOOKS['assign_to_ticket'][''] = true
>> et en utilisant la méthode
>> Plugin::RegisterClass("").
>>
>> Une liste peut ainsi être générée par la fonction
>> plugin__AssignToTicket($types)
>> qui est utilisée dans la méthode
>> CommonITILObject::getAllTypesForHelpdesk().
>>
>> Jusqu'ici tout va bien :) ... mais les 2 points suivants
>> empêchent la pleine intégration de ces types dans GLPI :
>>
>> 1. Ces types n'apparaissent pas dans la liste des éléments associables
>>autorisés pour un profil (ie. onglet Assistance du formulaire d'un
>>Profil) à cause d'une condition empêchant les types provenant de
>>plugins d'y être répertoriés.
>>À mon avis, on peut faire sauter cette condition vu que les plugins
>>peuvent déjà utiliser le hook (... à moins qu'il y ait d'autres
>>implications que mon grep n'a pas relevé).
>>
>> 2. Si la correction du point précédent est acceptée, la méthode
>>CommonITILObject::getAllTypesForHelpdesk() devrait aussi filtrer
>>ces types par la liste des types autorisés pour le profil actif,
>>c'est à dire $_SESSION["glpiactiveprofile"]["helpdesk_item_type"].
>>Cela peut être fait côté plugin mais comme cette méthode le fait
>>déjà pour les types du coeur, je pense qu'elle devrait vérifier
>>aussi les types des plugins.
>>
>> J'ai fait plusieurs tests avec le patch ci-joint en reliant un objet
>> et en supprimant de la base et je n'ai pas encore constaté de
>> surprise.
>>
>> --
>> Kevin Roy
>>
>>
>> ___
>> Glpi-dev mailing list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev
>
>
>
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[thierry DeTheGeek]

Merci pour l'analyse, je garde la discussion de côté pour mes prochaines
contributions.

Le patch sera appliqué sur quelle version de GLPI ? 0.85 ?


Le 3 septembre 2014 13:45, Julien Dombre  a écrit :

> Le 03/09/2014 13:40, Kevin Roy a écrit :
>
>  2014-09-03 11:41 GMT+02:00 thierry DeTheGeek :
>>
>>> Je pense que c'est une bonne amélioration. Il faudra vérifier l'impact
>>> sur
>>> SimCards et le patcher en conséquence.
>>>
>> D'après le hook présent dans le trunk actuel du plugin Simcard [1],
>> que l'objet soit présent ou non dans la liste des éléments assignables
>> à un ticket n'aura aucune incidence sur le comportement du plugin car
>> c'est le droit géré par le plugin qui est utilisé au moment d'afficher
>> la liste des types assignables à un ticket.
>>
>> [1] https://forge.indepnet.net/projects/simcard/repository/
>> entry/trunk/hook.php#L173
>>
>
> Il y a donc bien une modification à faire car s'il n'est pas dans la liste
> des éléments assignables, il ne sera plus accessible.
>
> je vais commiter d'ici 1 minute ton patch un peu modifié et complété.
>
> ++
>
> Julien
>
>
>
>> ___
>> Glpi-dev mailing list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev
>>
>
>
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev
>
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[Julien Dombre]

Le 03/09/2014 13:40, Kevin Roy a écrit :

2014-09-03 11:41 GMT+02:00 thierry DeTheGeek :

Je pense que c'est une bonne amélioration. Il faudra vérifier l'impact sur
SimCards et le patcher en conséquence.

D'après le hook présent dans le trunk actuel du plugin Simcard [1],
que l'objet soit présent ou non dans la liste des éléments assignables
à un ticket n'aura aucune incidence sur le comportement du plugin car
c'est le droit géré par le plugin qui est utilisé au moment d'afficher
la liste des types assignables à un ticket.

[1] 
https://forge.indepnet.net/projects/simcard/repository/entry/trunk/hook.php#L173


Il y a donc bien une modification à faire car s'il n'est pas dans la 
liste des éléments assignables, il ne sera plus accessible.


je vais commiter d'ici 1 minute ton patch un peu modifié et complété.

++

Julien



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[Kevin Roy]

2014-09-03 11:41 GMT+02:00 thierry DeTheGeek :
> Je pense que c'est une bonne amélioration. Il faudra vérifier l'impact sur
> SimCards et le patcher en conséquence.

D'après le hook présent dans le trunk actuel du plugin Simcard [1],
que l'objet soit présent ou non dans la liste des éléments assignables
à un ticket n'aura aucune incidence sur le comportement du plugin car
c'est le droit géré par le plugin qui est utilisé au moment d'afficher
la liste des types assignables à un ticket.

[1] 
https://forge.indepnet.net/projects/simcard/repository/entry/trunk/hook.php#L173

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[thierry DeTheGeek]

Bonjour

Je pense que c'est une bonne amélioration. Il faudra vérifier l'impact sur
SimCards et le patcher en conséquence.


Le 3 septembre 2014 10:32, Tsmr  a écrit :

>  Du moment que ceci est appliqué lors d'un passage dans une version
> majeure et que c'est documenté dans la procédure d'upgrade des plugins sur
> le wiki de la forge, pas de souci de mon coté.
>
> Le 03.09.2014 10:03, Julien Dombre a écrit :
>
> Bonjour,
>
> De mémoire c'était pour que la configuration des plugins ne soit faites
> que dans les plugins.
> J'imagine que certains plugins gèrent l'associabilité directement dans la
> conf de leurs plugins.
> Si on applique ton patch ca voudra dire qu'on bascule complètement cette
> conf dans la conf générale et je n'aimerai pas que ca pète les autres
> plugins.
> C'est faisable mais il faut que les autres mainteneurs de plugins qui
> utilisent cette fonctionnalité valide cette bascule.
>
> Qu'ils se manifestent donc où se taisent à jamais :)
>
> ++
>
> Julien
>
>
>
> Le 02/09/2014 17:30, Kevin Roy a écrit :
>
> Bonjour,
>
> Actuellement, les plugins peuvent enregistrer des types d'objets pour
> pouvoir les assigner à un ticket grâce à
> $PLUGIN_HOOKS['assign_to_ticket'][''] = true
> et en utilisant la méthode
> Plugin::RegisterClass("").
>
> Une liste peut ainsi être générée par la fonction
> plugin__AssignToTicket($types)
> qui est utilisée dans la méthode
> CommonITILObject::getAllTypesForHelpdesk().
>
> Jusqu'ici tout va bien :) ... mais les 2 points suivants
> empêchent la pleine intégration de ces types dans GLPI :
>
> 1. Ces types n'apparaissent pas dans la liste des éléments associables
>autorisés pour un profil (ie. onglet Assistance du formulaire d'un
>Profil) à cause d'une condition empêchant les types provenant de
>plugins d'y être répertoriés.
>À mon avis, on peut faire sauter cette condition vu que les plugins
>peuvent déjà utiliser le hook (... à moins qu'il y ait d'autres
>implications que mon grep n'a pas relevé).
>
> 2. Si la correction du point précédent est acceptée, la méthode
>CommonITILObject::getAllTypesForHelpdesk() devrait aussi filtrer
>ces types par la liste des types autorisés pour le profil actif,
>c'est à dire $_SESSION["glpiactiveprofile"]["helpdesk_item_type"].
>Cela peut être fait côté plugin mais comme cette méthode le fait
>déjà pour les types du coeur, je pense qu'elle devrait vérifier
>aussi les types des plugins.
>
> J'ai fait plusieurs tests avec le patch ci-joint en reliant un objet
> et en supprimant de la base et je n'ai pas encore constaté de
> surprise.
>
> --
> Kevin Roy
>
>
>
> ___
> Glpi-dev mailing listGlpi-dev@gna.orghttps://mail.gna.org/listinfo/glpi-dev
>
>
> --
>
> Tsmr
> Xavier CAILLAUD
>
>
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev
>
>
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[Tsmr]

 

Du moment que ceci est appliqué lors d'un passage dans une version
majeure et que c'est documenté dans la procédure d'upgrade des plugins
sur le wiki de la forge, pas de souci de mon coté. 

Le 03.09.2014
10:03, Julien Dombre a écrit : 

> Bonjour,
> 
> De mémoire c'était pour
que la configuration des plugins ne soit faites que dans les plugins.
>
J'imagine que certains plugins gèrent l'associabilité directement dans
la conf de leurs plugins.
> Si on applique ton patch ca voudra dire
qu'on bascule complètement cette conf dans la conf générale et je
n'aimerai pas que ca pète les autres plugins.
> C'est faisable mais il
faut que les autres mainteneurs de plugins qui utilisent cette
fonctionnalité valide cette bascule.
> 
> Qu'ils se manifestent donc où
se taisent à jamais :)
> 
> ++
> 
> Julien
> 
> Le 02/09/2014 17:30,
Kevin Roy a écrit : 
> 
>> Bonjour,
>> 
>> Actuellement, les plugins
peuvent enregistrer des types d'objets pour
>> pouvoir les assigner à un
ticket grâce à
>> $PLUGIN_HOOKS['assign_to_ticket'][''] = true
>> et en
utilisant la méthode
>> Plugin::RegisterClass("").
>> 
>> Une liste peut
ainsi être générée par la fonction
>> plugin__AssignToTicket($types)
>>
qui est utilisée dans la méthode
>>
CommonITILObject::getAllTypesForHelpdesk().
>> 
>> Jusqu'ici tout va
bien :) ... mais les 2 points suivants
>> empêchent la pleine
intégration de ces types dans GLPI :
>> 
>> 1. Ces types n'apparaissent
pas dans la liste des éléments associables
>> autorisés pour un profil
(ie. onglet Assistance du formulaire d'un
>> Profil) à cause d'une
condition empêchant les types provenant de
>> plugins d'y être
répertoriés.
>> À mon avis, on peut faire sauter cette condition vu que
les plugins
>> peuvent déjà utiliser le hook (... à moins qu'il y ait
d'autres
>> implications que mon grep n'a pas relevé).
>> 
>> 2. Si la
correction du point précédent est acceptée, la méthode
>>
CommonITILObject::getAllTypesForHelpdesk() devrait aussi filtrer
>> ces
types par la liste des types autorisés pour le profil actif,
>> c'est à
dire $_SESSION["glpiactiveprofile"]["helpdesk_item_type"].
>> Cela peut
être fait côté plugin mais comme cette méthode le fait
>> déjà pour les
types du coeur, je pense qu'elle devrait vérifier
>> aussi les types des
plugins.
>> 
>> J'ai fait plusieurs tests avec le patch ci-joint en
reliant un objet
>> et en supprimant de la base et je n'ai pas encore
constaté de
>> surprise.
>> 
>> --
>> Kevin Roy
>> 
>>
___
>> Glpi-dev mailing
list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev

--


Tsmr
Xavier CAILLAUD
 ___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[Julien Dombre]

Bonjour,

De mémoire c'était pour que la configuration des plugins ne soit faites 
que dans les plugins.
J'imagine que certains plugins gèrent l'associabilité directement dans 
la conf de leurs plugins.
Si on applique ton patch ca voudra dire qu'on bascule complètement cette 
conf dans la conf générale et je n'aimerai pas que ca pète les autres 
plugins.
C'est faisable mais il faut que les autres mainteneurs de plugins qui 
utilisent cette fonctionnalité valide cette bascule.


Qu'ils se manifestent donc où se taisent à jamais :)

++

Julien



Le 02/09/2014 17:30, Kevin Roy a écrit :

Bonjour,

Actuellement, les plugins peuvent enregistrer des types d'objets pour
pouvoir les assigner à un ticket grâce à
 $PLUGIN_HOOKS['assign_to_ticket'][''] = true
et en utilisant la méthode
 Plugin::RegisterClass("").

Une liste peut ainsi être générée par la fonction
 plugin__AssignToTicket($types)
qui est utilisée dans la méthode
 CommonITILObject::getAllTypesForHelpdesk().

Jusqu'ici tout va bien :) ... mais les 2 points suivants
empêchent la pleine intégration de ces types dans GLPI :

1. Ces types n'apparaissent pas dans la liste des éléments associables
autorisés pour un profil (ie. onglet Assistance du formulaire d'un
Profil) à cause d'une condition empêchant les types provenant de
plugins d'y être répertoriés.
À mon avis, on peut faire sauter cette condition vu que les plugins
peuvent déjà utiliser le hook (... à moins qu'il y ait d'autres
implications que mon grep n'a pas relevé).

2. Si la correction du point précédent est acceptée, la méthode
CommonITILObject::getAllTypesForHelpdesk() devrait aussi filtrer
ces types par la liste des types autorisés pour le profil actif,
c'est à dire $_SESSION["glpiactiveprofile"]["helpdesk_item_type"].
Cela peut être fait côté plugin mais comme cette méthode le fait
déjà pour les types du coeur, je pense qu'elle devrait vérifier
aussi les types des plugins.

J'ai fait plusieurs tests avec le patch ci-joint en reliant un objet
et en supprimant de la base et je n'ai pas encore constaté de
surprise.

--
Kevin Roy


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] [PATCH] Les types d'un plugin associables à des ticket ne sont pas visibles dans l'onglet Assistance des profils

[Kevin Roy]

Bonjour,

Actuellement, les plugins peuvent enregistrer des types d'objets pour
pouvoir les assigner à un ticket grâce à
$PLUGIN_HOOKS['assign_to_ticket'][''] = true
et en utilisant la méthode
Plugin::RegisterClass("").

Une liste peut ainsi être générée par la fonction
plugin__AssignToTicket($types)
qui est utilisée dans la méthode
CommonITILObject::getAllTypesForHelpdesk().

Jusqu'ici tout va bien :) ... mais les 2 points suivants
empêchent la pleine intégration de ces types dans GLPI :

1. Ces types n'apparaissent pas dans la liste des éléments associables
   autorisés pour un profil (ie. onglet Assistance du formulaire d'un
   Profil) à cause d'une condition empêchant les types provenant de
   plugins d'y être répertoriés.
   À mon avis, on peut faire sauter cette condition vu que les plugins
   peuvent déjà utiliser le hook (... à moins qu'il y ait d'autres
   implications que mon grep n'a pas relevé).

2. Si la correction du point précédent est acceptée, la méthode
   CommonITILObject::getAllTypesForHelpdesk() devrait aussi filtrer
   ces types par la liste des types autorisés pour le profil actif,
   c'est à dire $_SESSION["glpiactiveprofile"]["helpdesk_item_type"].
   Cela peut être fait côté plugin mais comme cette méthode le fait
   déjà pour les types du coeur, je pense qu'elle devrait vérifier
   aussi les types des plugins.

J'ai fait plusieurs tests avec le patch ci-joint en reliant un objet
et en supprimant de la base et je n'ai pas encore constaté de
surprise.

--
Kevin Roy
Index: inc/profile.class.php
===
--- inc/profile.class.php	(revision 23148)
+++ inc/profile.class.php	(working copy)
@@ -2336,9 +2336,7 @@
   $values = array();
   foreach ($CFG_GLPI["ticket_types"] as $key => $itemtype) {
  if ($item = getItemForItemtype($itemtype)) {
-if (!isPluginItemType($itemtype)) { // No Plugin for the moment
-   $values[$itemtype] = $item->getTypeName();
-}
+$values[$itemtype] = $item->getTypeName();
  } else {
 unset($CFG_GLPI["ticket_types"][$key]);
  }
Index: inc/commonitilobject.class.php
===
--- inc/commonitilobject.class.php	(revision 23148)
+++ inc/commonitilobject.class.php	(working copy)
@@ -4088,7 +4088,13 @@
   }
   asort($types); // core type first... asort could be better ?
   $types = array_merge($types, $ptypes);
-  return $types;
+  $filtered_types = array();
+  foreach($types as $itemtype => $itemtype_name) {
+ if (in_array($itemtype,$_SESSION["glpiactiveprofile"]["helpdesk_item_type"])) {
+$filtered_types[$itemtype] = $itemtype_name;
+ }
+  }
+  return $filtered_types;
}
 
 
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Construction des URLs de la classe Search à partir des méthodes de CommonGLPI au lieu de Toolbox

[Kevin Roy]

2014-07-24 11:18 GMT+02:00 Julien Dombre :
> Effectivement c'est plus logique comme ca.
> Le patch vient d'être intégré.

Merci :-)

Cheers,
--
Kevin Roy

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Construction des URLs de la classe Search à partir des méthodes de CommonGLPI au lieu de Toolbox

[Julien Dombre]

Le 24/07/2014 10:34, Kevin Roy a écrit :

Bonjour,


Je pense que ce patch ne concerne que le travail que j'effectue en ce
moment sur le plugin GenericObject. Pour faire court : les fichiers
générés par le plugin vont dans le répertoire
files/_plugins/genericobject qui est normalement dédié à cet effet de
résolution de chemins 'front'.

Ainsi, les URLs générées par la classe Search sont toutes issues des
fonctions Toolbox::getItemTypeSearchURL() et
Toolbox::getItemTypeFormURL() au lieu des fonctions de la classe de
base CommonDBTM.

Malgré ma problématique, la majorité des fonctions du framework et des
plugins (inc et front confondus) consommant ce type d'URL utilise les
méthodes communes de CommonGLPI et je me dis que la classe Search
n'est pas une exception et que le patch proposé essaie de corriger.

Effectivement c'est plus logique comme ca.
Le patch vient d'être intégré.

++

Julien



PS: Mes développement actuels sur le plugin genericobject se trouve
sur https://github.com/kiniou/glpi-plugin-genericobject (branche
glpi0.85).

Cordialement,
--
Kevin Roy


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] [PATCH] Construction des URLs de la classe Search à partir des méthodes de CommonGLPI au lieu de Toolbox

[Kevin Roy]

Bonjour,


Je pense que ce patch ne concerne que le travail que j'effectue en ce
moment sur le plugin GenericObject. Pour faire court : les fichiers
générés par le plugin vont dans le répertoire
files/_plugins/genericobject qui est normalement dédié à cet effet de
résolution de chemins 'front'.

Ainsi, les URLs générées par la classe Search sont toutes issues des
fonctions Toolbox::getItemTypeSearchURL() et
Toolbox::getItemTypeFormURL() au lieu des fonctions de la classe de
base CommonDBTM.

Malgré ma problématique, la majorité des fonctions du framework et des
plugins (inc et front confondus) consommant ce type d'URL utilise les
méthodes communes de CommonGLPI et je me dis que la classe Search
n'est pas une exception et que le patch proposé essaie de corriger.

PS: Mes développement actuels sur le plugin genericobject se trouve
sur https://github.com/kiniou/glpi-plugin-genericobject (branche
glpi0.85).

Cordialement,
--
Kevin Roy
Index: inc/search.class.php
===
--- inc/search.class.php	(revision 23099)
+++ inc/search.class.php	(working copy)
@@ -137,7 +137,7 @@
   $p['start']   = 0;//
   $p['is_deleted']  = 0;
   $p['export_all']  = 0;
-  $p['target']  = Toolbox::getItemTypeSearchURL($itemtype);
+  $p['target']  = $itemtype::getSearchURL();
   $p['display_type']= self::HTML_OUTPUT;
   $p['list_limit']  = $_SESSION['glpilist_limit'];
   $p['massiveactionparams'] = array();
@@ -1688,7 +1688,7 @@
   $p['is_deleted']   = 0;
   $p['criteria'] = array();
   $p['metacriteria'] = array();
-  $p['target']   = Toolbox::getItemTypeSearchURL($itemtype);
+  $p['target']   = $itemtype::getSearchURL();
   $p['showreset']= true;
   $p['showbookmark'] = true;
   $p['addhidden']= array();
@@ -1768,7 +1768,10 @@
  }
 
  if ($p['showreset']) {
-echo "";
+echo "";
 echo "  ";
  }
@@ -4327,7 +4330,7 @@
 $out .= $separate;
  }
  $count_display++;
- $page  = Toolbox::getItemTypeFormURL($linkitemtype);
+ $page  = $linkitemtype::getFormUrl();
  $page .= (strpos($page,'?') ? '&id' : '?id');
  $name  = Dropdown::getValueWithUnit($data[$num][$k]['name'],$unit);
  if ($_SESSION["glpiis_ids_visible"] || empty($data[$num][$k]['name'])) {
@@ -5832,4 +5835,4 @@
}
 
 }
-?>
\ No newline at end of file
+?>
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour se déplacer de form en form

[thierry DeTheGeek]

Dans la foulée : Que pensez-vous de MAJ+Flèche pour sauvegarder les
changements puis passer à la fiche précédente/suivante ?

Ca m'arrive souvent de faire des changements en masse sur des champs qui ne
sont pas disponibles avec les actions de masse. (genre la perte des numéros
de série sur 250 imprimantes ).


Le 11 juin 2014 13:48, David DURIEUX  a écrit :

> Le Wed, 11 Jun 2014 13:39:41 +0200
> Julien Dombre  a écrit:
>
> >Le 11/06/2014 13:09, thierry DeTheGeek a écrit :
> >> Bonjour
> >>
> >> Justement j'y pensais depuis quelques semaines ! C'est possible de
> >> porter le patch pour la branche 0.84 ?
> >>
> >Tel quel je ne pense pas car la gestion des onglets à changer entre la
> >0.84 et la 0.85.
> >
> >Concernant l'usage des flèches ca me semble violent je trouve.
> >Peut-être qu'une combinaison serait plus adaptée (CTRL+ fleches ou
> >ALT+fleches ?)
>
> Pas faux, plutot CTRL + flèche car le ALT + flèche est le racourcis du
> navigateur pour la page précédente.
>
> Je modifie et commite
>
> Merci ;)
>
> David
> ++
>
> >++
> >
> >Julien
> >
> >
> >>
> >> Le 11 juin 2014 12:01, David DURIEUX  >> > a écrit :
> >>
> >> Bonjour,
> >>
> >> Voici un patch 0.85 pour naviguer avec la flèche de gauche et
> >> droite dans les formulaire.
> >>
> >> Quand on est dans un formulaire, on a les flèches de navigation
> >> pour aller a la fiche suivante ou précédente. Ce patch permet de
> >> naviguer avec les touches du clavier (flèche de droite pour aller à
> >> la fiche suivante, et flèche de gauche pour aller à la fiche
> >> précédente).
> >>
> >>
> >>
> >> Cordialement,
> >> --
> >> David DURIEUX
> >> Tel : +33 (0)4.82.53.30.53 
> >> Mail : d.duri...@siprossii.com 
> >> Site Web : http://www.siprossii.com/
> >>
> >> SIPROSSII
> >> Rue des jardins
> >> 69860 Monsols
> >> FRANCE
> >>
> >> ___
> >> Glpi-dev mailing list
> >> Glpi-dev@gna.org 
> >> https://mail.gna.org/listinfo/glpi-dev
> >>
> >>
> >>
> >>
> >> ___
> >> Glpi-dev mailing list
> >> Glpi-dev@gna.org
> >> https://mail.gna.org/listinfo/glpi-dev
> >
>
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev
>
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour se déplacer de form en form

[David DURIEUX]

Le Wed, 11 Jun 2014 13:39:41 +0200
Julien Dombre  a écrit:

>Le 11/06/2014 13:09, thierry DeTheGeek a écrit :
>> Bonjour
>>
>> Justement j'y pensais depuis quelques semaines ! C'est possible de 
>> porter le patch pour la branche 0.84 ?
>>
>Tel quel je ne pense pas car la gestion des onglets à changer entre la 
>0.84 et la 0.85.
>
>Concernant l'usage des flèches ca me semble violent je trouve.
>Peut-être qu'une combinaison serait plus adaptée (CTRL+ fleches ou
>ALT+fleches ?)

Pas faux, plutot CTRL + flèche car le ALT + flèche est le racourcis du
navigateur pour la page précédente.

Je modifie et commite

Merci ;)

David
++

>++
>
>Julien
>
>
>>
>> Le 11 juin 2014 12:01, David DURIEUX > > a écrit :
>>
>> Bonjour,
>>
>> Voici un patch 0.85 pour naviguer avec la flèche de gauche et
>> droite dans les formulaire.
>>
>> Quand on est dans un formulaire, on a les flèches de navigation
>> pour aller a la fiche suivante ou précédente. Ce patch permet de
>> naviguer avec les touches du clavier (flèche de droite pour aller à
>> la fiche suivante, et flèche de gauche pour aller à la fiche
>> précédente).
>>
>>
>>
>> Cordialement,
>> --
>> David DURIEUX
>> Tel : +33 (0)4.82.53.30.53 
>> Mail : d.duri...@siprossii.com 
>> Site Web : http://www.siprossii.com/
>>
>> SIPROSSII
>> Rue des jardins
>> 69860 Monsols
>> FRANCE
>>
>> ___
>> Glpi-dev mailing list
>> Glpi-dev@gna.org 
>> https://mail.gna.org/listinfo/glpi-dev
>>
>>
>>
>>
>> ___
>> Glpi-dev mailing list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev
>

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour se déplacer de form en form

[Julien Dombre]

Le 11/06/2014 13:09, thierry DeTheGeek a écrit :

Bonjour

Justement j'y pensais depuis quelques semaines ! C'est possible de 
porter le patch pour la branche 0.84 ?


Tel quel je ne pense pas car la gestion des onglets à changer entre la 
0.84 et la 0.85.


Concernant l'usage des flèches ca me semble violent je trouve. Peut-être 
qu'une combinaison serait plus adaptée (CTRL+ fleches ou ALT+fleches ?)


++

Julien




Le 11 juin 2014 12:01, David DURIEUX > a écrit :


Bonjour,

Voici un patch 0.85 pour naviguer avec la flèche de gauche et droite
dans les formulaire.

Quand on est dans un formulaire, on a les flèches de navigation pour
aller a la fiche suivante ou précédente. Ce patch permet de naviguer
avec les touches du clavier (flèche de droite pour aller à la fiche
suivante, et flèche de gauche pour aller à la fiche précédente).



Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53 
Mail : d.duri...@siprossii.com 
Site Web : http://www.siprossii.com/

SIPROSSII
Rue des jardins
69860 Monsols
FRANCE

___
Glpi-dev mailing list
Glpi-dev@gna.org 
https://mail.gna.org/listinfo/glpi-dev




___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour se déplacer de form en form

[thierry DeTheGeek]

Bonjour

Justement j'y pensais depuis quelques semaines ! C'est possible de porter
le patch pour la branche 0.84 ?


Le 11 juin 2014 12:01, David DURIEUX  a écrit :

> Bonjour,
>
> Voici un patch 0.85 pour naviguer avec la flèche de gauche et droite
> dans les formulaire.
>
> Quand on est dans un formulaire, on a les flèches de navigation pour
> aller a la fiche suivante ou précédente. Ce patch permet de naviguer
> avec les touches du clavier (flèche de droite pour aller à la fiche
> suivante, et flèche de gauche pour aller à la fiche précédente).
>
>
>
> Cordialement,
> --
> David DURIEUX
> Tel : +33 (0)4.82.53.30.53
> Mail : d.duri...@siprossii.com
> Site Web : http://www.siprossii.com/
>
> SIPROSSII
> Rue des jardins
> 69860 Monsols
> FRANCE
>
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev
>
>
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch pour se déplacer de form en form

[David DURIEUX]

Bonjour,

Voici un patch 0.85 pour naviguer avec la flèche de gauche et droite
dans les formulaire. 

Quand on est dans un formulaire, on a les flèches de navigation pour
aller a la fiche suivante ou précédente. Ce patch permet de naviguer
avec les touches du clavier (flèche de droite pour aller à la fiche
suivante, et flèche de gauche pour aller à la fiche précédente).



Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Rue des jardins
69860 Monsols
FRANCE
Index: inc/commonglpi.class.php
===
--- inc/commonglpi.class.php	(revision 22999)
+++ inc/commonglpi.class.php	(working copy)
@@ -752,9 +752,15 @@
  }
 
  if ($prev >= 0) {
-echo "".
+echo "".
   "";
+$js = '$("body").keydown(function(e) {
+   if(e.keyCode == 37) {
+ window.location = $("#previouspage").attr("href");
+   }
+  });';
+echo Html::scriptBlock($js);
  } else {
 echo "";
@@ -798,9 +804,15 @@
  }
 
  if ($next >= 0) {
-echo "".
+echo "".
   "";
+$js = '$("body").keydown(function(e) {
+   if(e.keyCode == 39) {
+ window.location = $("#nextpage").attr("href");
+   }
+  });';
+echo Html::scriptBlock($js);
  } else {
 echo "";
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch plugins Report

[Adrien Beudin]

 

Bonjour, 

j'ai fait un petit patch pour ajouter la possibilité de
voir les contrats qui on était déplacé d'une entité à une autre dans le
rapport "Liste des objets transférés" 

Cordialement 

Adrien Beudin -
05 82 95 65 36
Objectif Libre www.objectif-libre.com
Infrastructure et
Formations Linux
 --- reports/report/transferreditems/transferreditems.php2013-05-02 
15:03:33.0 +0200
+++ 
/var/www/html/glpi/plugins/reports/report/transferreditems/transferreditems.php 
2014-04-22 13:14:06.580330286 +0200
@@ -42,7 +42,7 @@
 new PluginReportsDateIntervalCriteria($report, "`glpi_logs`.`date_mod`");
 
 $types = array();
-foreach (array('Computer', 'Monitor', 'NetworkEquipment', 'Peripheral', 
'Phone', 'Printer',
+foreach (array('Computer', 'Contract',  'Monitor', 'NetworkEquipment', 
'Peripheral', 'Phone', 'Printer',
'Software','SoftwareLicense') as $type) {
$label   = call_user_func(array($type, 'getTypeName'));
$types[$type] = $label;
@@ -65,8 +65,22 @@
 new PluginReportsColumn('new_value', __('Target entity', 
'reports')),
 new PluginReportsColumnDateTime('date_mod', __('Transfert 
date', 'reports')));
$report->setColumns($columns);
-
-   $query = "SELECT `$table`.`id` as `items_id`,
+   if ($itemtype == 'Contract') {
+  $query = "SELECT `$table`.`id` as `items_id`,
+`$table`.`name`,
+`glpi_logs`.`date_mod` as `date_mod`,
+`glpi_logs`.`itemtype` as `itemtype`,
+`glpi_logs`.`old_value`,
+`glpi_logs`.`new_value`
+ FROM `$table`, `glpi_logs` ".
+ $report->addSqlCriteriasRestriction("WHERE")."
+   AND `glpi_logs`.`items_id` = `$table`.`id`
+   AND `glpi_logs`.`itemtype` = '$itemtype'
+   AND `glpi_logs`.`id_search_option`='80'
+ ORDER BY `date_mod` ASC";
+   }
+   else {
+  $query = "SELECT `$table`.`id` as `items_id`,
 `$table`.`name`,
 `$table`.`otherserial`,
 `glpi_logs`.`date_mod` as `date_mod`,
@@ -79,8 +93,9 @@
AND `glpi_logs`.`itemtype` = '$itemtype'
AND `glpi_logs`.`id_search_option`='80'
  ORDER BY `date_mod` ASC";
+   }
 
$report->setSqlRequest($query);
$report->execute();
 }
-?>
\ Pas de fin de ligne à la fin du fichier.
+?>___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] correction du chargement initial des dropdown 'searchtype' pour les critères

[Kevin Roy]

2014-04-10 17:36 GMT+02:00 MoYo :
> le correctif proposé change fondamentalement le comportement de la fonction
> updateItemOnEventJsCode en ajoutant un déclenchement de l'action à la
> définition de la gestion d'un événement. Les effets de bords à d'autres
> endroits de GLPI me semble donc plutôt dangereux.

Je me suis fais la même réflexion que toi mais après avoir fais le
test sur plusieurs formulaire de GLPI, le seul danger (si on peut
appeler ça un danger) que j'ai pu voir en rajoutant le trigger, c'est
qu'une requête ajax est faite en lieu et place d'un éventuel
chargement initial des données par le PHP (ce qui à l'air de
transparaître dans ton dernier commit) et duplique le code normalement
déjà en place par cette requête ajax pour charger les données en
fonctions des paramètres associés à l'évènement.

> Je viens de commiter une correction pour le problème soulevé sans toucher à
> cette fonction.

Le problème est bien réglé avec ton dernier commit.

> A voir par la suite pour reréflechir à une gestion plus simple de tout cela.

Une fois mon "chantier" fusioninventory 0.85 terminé, je devrais
pouvoir me pencher un peu plus sur le sujet.

Cordialement,
--
Kevin 'kiniou' Roy

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] correction du chargement initial des dropdown 'searchtype' pour les critères

[MoYo]

Bonjour,

le correctif proposé change fondamentalement le comportement de la 
fonction updateItemOnEventJsCode en ajoutant un déclenchement de 
l'action à la définition de la gestion d'un événement. Les effets de 
bords à d'autres endroits de GLPI me semble donc plutôt dangereux.


Je viens de commiter une correction pour le problème soulevé sans 
toucher à cette fonction.


A voir par la suite pour reréflechir à une gestion plus simple de tout cela.

Cordialement,

Julien Dombre



Le 10/04/2014 15:49, Kevin Roy a écrit :

Bonjour,

La dropdown 'searchtype' des critères globaux du moteur de recherche
ne sont pas correctement chargés et ne contiennent que le type
'contains'.
Pour illustrer mon propos et reproduire ce comportement, il suffit de
rajouter un critère global et de sélectionner le type Logiciel. Le
champ du critère global sélectionné est le Nom et la dropdown
'searchtype' ne possède que "contient" alors qu'elle devrait lister
"contient","est" et "n'est pas".

Le patch suivant rajoute un appel à .trigger('change') sur l'objet
jQuery chargé d'écouter l'évènement. Cela a pour effet de charger
correctement cette liste lors de l'affichage de la dropdown des champs
du critère global sélectionné.

J'ai aussi supprimé les différents include du fichier
ajax/searchoption.php dans les fichiers ajax concernés car le
.trigger('change') permet à la fonction javascript généré par
updateItemOnEventJsCode de recharger la dropdown 'searchoption' à
l'affichage.

Cordialement,
--
Kevin 'kiniou' Roy


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] [PATCH] correction du chargement initial des dropdown 'searchtype' pour les critères

[Kevin Roy]

Bonjour,

La dropdown 'searchtype' des critères globaux du moteur de recherche
ne sont pas correctement chargés et ne contiennent que le type
'contains'.
Pour illustrer mon propos et reproduire ce comportement, il suffit de
rajouter un critère global et de sélectionner le type Logiciel. Le
champ du critère global sélectionné est le Nom et la dropdown
'searchtype' ne possède que "contient" alors qu'elle devrait lister
"contient","est" et "n'est pas".

Le patch suivant rajoute un appel à .trigger('change') sur l'objet
jQuery chargé d'écouter l'évènement. Cela a pour effet de charger
correctement cette liste lors de l'affichage de la dropdown des champs
du critère global sélectionné.

J'ai aussi supprimé les différents include du fichier
ajax/searchoption.php dans les fichiers ajax concernés car le
.trigger('change') permet à la fonction javascript généré par
updateItemOnEventJsCode de recharger la dropdown 'searchoption' à
l'affichage.

Cordialement,
--
Kevin 'kiniou' Roy
Index: ajax/searchoption.php
===
--- ajax/searchoption.php	(revision 22892)
+++ ajax/searchoption.php	(working copy)
@@ -93,7 +93,6 @@
$_POST['value']  = stripslashes($_POST['value']);
$_POST['searchopt']  = $searchopt;
 
-   include(GLPI_ROOT."/ajax/searchoptionvalue.php");
echo "\n";
echo "";
 
Index: ajax/searchoptionvalue.php
===
--- ajax/searchoptionvalue.php	(revision 22892)
+++ ajax/searchoptionvalue.php	(working copy)
@@ -45,7 +45,11 @@
 Session::checkLoginUser();
 
 if (isset($_POST['searchtype'])) {
-   $searchopt  = $_POST['searchopt'];
+   if ( isset($_POST['searchopt'])) {
+  $searchopt  = $_POST['searchopt'];
+   } else {
+  $searchopt = array();
+   }
$_POST['value'] = rawurldecode($_POST['value']);
 
$fieldname = 'criteria';
Index: ajax/searchrow.php
===
--- ajax/searchrow.php	(revision 22892)
+++ ajax/searchrow.php	(working copy)
@@ -180,7 +180,6 @@
$_POST['field']  = $value;
$_POST['searchtype'] = (isset($criteria['searchtype'])?$criteria['searchtype']:"" );
$_POST['value']  = (isset($criteria['value'])?stripslashes($criteria['value']):"" );
-   include (GLPI_ROOT."/ajax/searchoption.php");
echo "\n";
 
$params = array('field'  => '__VALUE__',
@@ -194,4 +193,4 @@
 
echo "\n";
 }
-?>
\ No newline at end of file
+?>
Index: ajax/updateMetaSearch.php
===
--- ajax/updateMetaSearch.php	(revision 22892)
+++ ajax/updateMetaSearch.php	(working copy)
@@ -70,7 +70,6 @@
 
 $_POST['meta'] = 1;
 
-include (GLPI_ROOT."/ajax/searchoption.php");
 echo "\n";
 
 $params = array('field'  => '__VALUE__',
Index: inc/ajax.class.php
===
--- inc/ajax.class.php	(revision 22892)
+++ inc/ajax.class.php	(working copy)
@@ -499,7 +499,8 @@
  $output .= "}";
   }
$output .=  "}";
-$output .=");\n";
+// trigger the event in order to correctly load ajax url at initial display.
+$output .=").trigger('$event');\n";
  }
   }
   if ($display) {
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch pour le plugin webservice

[David DURIEUX]

Bonjour,

Voici un patch pour le plugin webservice (bug avec l'option show_name
de glpi.getObject dans la version cpmpatible 0.84).

Je ne suis pas sûr que le patch soit complet. le problème est dû au
fait que le getsearchoptions 'itemtype_link' n'existe plus en 0.84

Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Rue des jardins
69860 Monsols
FRANCE
Index: inc/methodcommon.class.php
===
--- inc/methodcommon.class.php	(revision 374)
+++ inc/methodcommon.class.php	(working copy)
@@ -484,7 +484,8 @@
   if (isset($option['itemlink_type'])) {
  $obj = new $option['itemlink_type']();
   } else {
- $obj = new $option['itemlink_link']();
+ $itemtype = getItemTypeForTable($option['table']);
+ $obj = new $itemtype();
   }
   $obj->getFromDB($p['data'][$linkfield]);
   $tmp[$linkfield]   = $p['data'][$linkfield];
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch plugin report

[David DURIEUX]

Ce patch rajoute les contrats dans le raport `transferreditems`.

Si un des dev du plugin report peut l'intégrer ou alors me donner les
droits dessus.

David
++
Index: report/transferreditems/transferreditems.php
===
--- report/transferreditems/transferreditems.php	(revision 281)
+++ report/transferreditems/transferreditems.php	(working copy)
@@ -43,7 +43,7 @@
 
 $types = array();
 foreach (array('Computer', 'Monitor', 'NetworkEquipment', 'Peripheral', 'Phone', 'Printer',
-   'Software','SoftwareLicense') as $type) {
+   'Software','SoftwareLicense', 'Contract') as $type) {
$label   = call_user_func(array($type, 'getTypeName'));
$types[$type] = $label;
 }
@@ -66,9 +66,14 @@
 new PluginReportsColumnDateTime('date_mod', __('Transfert date', 'reports')));
$report->setColumns($columns);
 
+   $otherserial = "`$table`.`otherserial`,";
+   if ($itemtype == 'Contract') {
+  $otherserial = '';
+   }
+
$query = "SELECT `$table`.`id` as `items_id`,
 `$table`.`name`,
-`$table`.`otherserial`,
+".$otherserial."
 `glpi_logs`.`date_mod` as `date_mod`,
 `glpi_logs`.`itemtype` as `itemtype`,
 `glpi_logs`.`old_value`,
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [PATCH] Fix calendar icon path when used in plugin.

[Julien Dombre]

Patch applied.

Thanks

Le 16/03/2014 19:41, Kevin Roy a écrit :

Hi GLPI developpers,

When used in a plugin, the calendar icon used in
Html::showDateTimeField() doesn't load sinc it uses a relative path
instead of an absolute path constructed with CFG_GLPI['root_doc'].

The following small patch fix this issue.

Best regards,
--
Kevin Roy


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] [PATCH] Fix calendar icon path when used in plugin.

[Kevin Roy]

Hi GLPI developpers,

When used in a plugin, the calendar icon used in
Html::showDateTimeField() doesn't load sinc it uses a relative path
instead of an absolute path constructed with CFG_GLPI['root_doc'].

The following small patch fix this issue.

Best regards,
--
Kevin Roy
Index: inc/html.class.php
===
--- inc/html.class.php	(revision 22791)
+++ inc/html.class.php	(working copy)
@@ -3064,7 +3064,7 @@
   showOn: 'button',
   showWeek: true,
   controlType: 'select',
-  buttonImage: '../pics/calendar.png',
+  buttonImage: '".$CFG_GLPI['root_doc']."/pics/calendar.png',
   buttonImageOnly: true";
   if (!$p['canedit']) {
  $js .= ",disabled: true";
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch migration depuis la 0.72

[Julien Dombre]

Le 27/04/2013 23:49, David DURIEUX a écrit :

Bonjour,

Il y a un soucis lors de la migration depuis la 0.72, avant on
utilisait des numéros pour les itemtype, et il faut les définir en dur
dans la fonction de mise à jour en 0.78.

Bonjour,

le problème vient d'être corrigé différemment



J'ai corrigé aussi un bug dans le script CLI de migration.


Celui ci est intégré également.

Merci

Julien



Voici le patch pour la 0.84

Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch migration depuis la 0.72

[Julien Dombre]

Le 27/04/2013 23:49, David DURIEUX a écrit :

Bonjour,

Il y a un soucis lors de la migration depuis la 0.72, avant on
utilisait des numéros pour les itemtype, et il faut les définir en dur
dans la fonction de mise à jour en 0.78.

Bizarre car normalement ils sont inclus dans define.php :

// ITEMS TYPE
/// Temporary definition for test
// TODO clean it.
if (!strstr($_SERVER['PHP_SELF'], "/install/")
&& !strstr($_SERVER['PHP_SELF'], '/cliupdate')) {

++

Julien


J'ai corrigé aussi un bug dans le script CLI de migration.

Voici le patch pour la 0.84

Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch migration depuis la 0.72

[David DURIEUX]

Bonjour,

Il y a un soucis lors de la migration depuis la 0.72, avant on
utilisait des numéros pour les itemtype, et il faut les définir en dur
dans la fonction de mise à jour en 0.78.  

J'ai corrigé aussi un bug dans le script CLI de migration.

Voici le patch pour la 0.84

Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE
Index: install/update_0723_078.php
===
--- install/update_0723_078.php	(revision 20823)
+++ install/update_0723_078.php	(working copy)
@@ -2607,65 +2607,65 @@
   'Update itemtype fields'));
 
// Convert itemtype to Class names
-   $typetoname = array(GENERAL_TYPE  => "",// For tickets
-   COMPUTER_TYPE => "Computer",
-   NETWORKING_TYPE   => "NetworkEquipment",
-   PRINTER_TYPE  => "Printer",
-   MONITOR_TYPE  => "Monitor",
-   PERIPHERAL_TYPE   => "Peripheral",
-   SOFTWARE_TYPE => "Software",
-   CONTACT_TYPE  => "Contact",
-   ENTERPRISE_TYPE   => "Supplier",
-   INFOCOM_TYPE  => "Infocom",
-   CONTRACT_TYPE => "Contract",
-   CARTRIDGEITEM_TYPE=> "CartridgeItem",
-   TYPEDOC_TYPE  => "DocumentType",
-   DOCUMENT_TYPE => "Document",
-   KNOWBASE_TYPE => "KnowbaseItem",
-   USER_TYPE => "User",
-   TRACKING_TYPE => "Ticket",
-   CONSUMABLEITEM_TYPE   => "ConsumableItem",
-   CONSUMABLE_TYPE   => "Consumable",
-   CARTRIDGE_TYPE=> "Cartridge",
-   SOFTWARELICENSE_TYPE  => "SoftwareLicense",
-   LINK_TYPE => "Link",
-   STATE_TYPE=> "States",
-   PHONE_TYPE=> "Phone",
-   DEVICE_TYPE   => "Device",
-   REMINDER_TYPE => "Reminder",
-   STAT_TYPE => "Stat",
-   GROUP_TYPE=> "Group",
-   ENTITY_TYPE   => "Entity",
-   RESERVATION_TYPE  => "ReservationItem",
-   AUTHMAIL_TYPE => "AuthMail",
-   AUTHLDAP_TYPE => "AuthLDAP",
-   OCSNG_TYPE=> "OcsServer",
-   REGISTRY_TYPE => "RegistryKey",
-   PROFILE_TYPE  => "Profile",
-   MAILGATE_TYPE => "MailCollector",
-   RULE_TYPE => "Rule",
-   TRANSFER_TYPE => "Transfer",
-   BOOKMARK_TYPE => "Bookmark",
-   SOFTWAREVERSION_TYPE  => "SoftwareVersion",
-   PLUGIN_TYPE   => "Plugin",
-   COMPUTERDISK_TYPE => "ComputerDisk",
-   NETWORKING_PORT_TYPE  => "NetworkPort",
-   FOLLOWUP_TYPE => "TicketFollowup",
-   BUDGET_TYPE   => "Budget");
+   $typetoname = array(0  => "",// For tickets
+   1  => "Computer",
+   2  => "NetworkEquipment",
+   3  => "Printer",
+   4  => "Monitor",
+   5  => "Peripheral",
+   6  => "Software",
+   7  => "Contact",
+   8  => "Supplier",
+   9  => "Infocom",
+   10 => "Contract",
+   11 => "CartridgeItem",
+   12 => "DocumentType",
+   13 => "Document",
+   14 => "KnowbaseItem",
+   15 => "User",
+   16 => "Ticket",
+   17 => "ConsumableItem",
+   18 => "Consumable",
+   19 => "Cartridge",
+   20 => "SoftwareLicense",
+   21 => "Link",
+   22 => "States",
+   23 => "Phone",
+   24 => "Device",
+   25 => "Reminder",
+   26 => "Stat",
+   27 => "Group",
+   28 => "Entity",
+   29 => "ReservationItem",
+   30 => "AuthMail",
+   31 => "AuthLDAP",
+   32 => "OcsServer",
+  

Re: [Glpi-dev] Patch pour le ticket #2476

[Julien Dombre]

Le 30/10/2012 09:13, David DURIEUX a écrit :

Nouveau patch upstream



Salut,

Je viens de faire un premier passage très rapide sur ton patch.
Déjà merci pour une telle contribution.

Quelques soucis assez gênants déjà remontés en direct :
- gestion des meta recherches HS
- manque de commentaires pour bien comprendre les mécanismes en place 
(fonctions + interne au code)
- des erreurs du genre Undefined index: nosort in 
/home/dombre/httpd/glpi-test/inc/search.class.php at line 1286

- quelques petits soucis d'indentation du code.
- ligne 4448 la gestion des liens est plutôt étrange... ne tiens pas 
compte des datatypes.
- Gestion des unités (ex clôture auto sur les entités -> -2day / -1day ) 
(sûrement des modifs à faire dans CommonDBTM aussi


Voilà pour mes premières remarques rapides, je n'ai malheureusement pas 
plus de temps pour tester.


++

Julien




___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[David DURIEUX]

Ah zut, ben je vais mettre à jour et refaire un patch ce soir alors,
t'embête pas à remonter la version


Le Thu, 25 Oct 2012 17:34:48 +0200
Julien Dombre  a écrit:

>Le 25/10/2012 15:45, David DURIEUX a écrit :
>> Voici le patch pour ce ticket 2476
>Salut,
>
>je n'arrive pas à l'appliquer sur le trunk.
>Je n'ai pas assez de temps pour remonter la version sur laquelle tu as 
>fait la patch.
>
>++
>
>Julien
>
>
>___
>Glpi-dev mailing list
>Glpi-dev@gna.org
>https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[Julien Dombre]

Le 25/10/2012 15:45, David DURIEUX a écrit :

Voici le patch pour ce ticket 2476

Salut,

je n'arrive pas à l'appliquer sur le trunk.
Je n'ai pas assez de temps pour remonter la version sur laquelle tu as 
fait la patch.


++

Julien


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[David DURIEUX]

Le Tue, 16 Oct 2012 08:20:26 +0200
MoYo  a écrit:

>Le 16/10/2012 08:12, David DURIEUX a écrit :
>>
>> Ca se comporte bien au final, les data sont ajoutés en fin de tableau
>> des données et ces données splité en array, exemple (recherche
>> ordinateur ayant logiciel "apache" :
>>
>> [13] => Array
>> (
>>[separate] =>
>>
>>[value] => Array
>>   (
>>  [0] => Array
>> (
>>[name] => Apache Tomcat 4.0 (remove only)
>>[itemtype] => Software
>>[items_id] => 1738
>>[unit] =>
>> )
>>)
>> )
>>
>> Ca c'est à la sortie de constructData() et displayData() va afficher
>> ça correctement ;)
>Pourquoi là on a un tableau de données alors que pour les autres tu
>met [1] [1_2]...
>Je ne vois pas trop la logique.
>Pareil pour les chaines avec des  et $$ pourquoi ne pas les
>splitter en sortie de constructdata ?

Ah vi c'est vrai, j'ai modifié le comportement, tous les  et $$
sont splités de cette manière. j'ai mis à jour l'array de sortie, voici
une sortie complète

http://pastebin.com/YNCTYAZf




>++
>
>Julien
>
>
>___
>Glpi-dev mailing list
>Glpi-dev@gna.org
>https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[MoYo]

Le 16/10/2012 08:12, David DURIEUX a écrit :


Ca se comporte bien au final, les data sont ajoutés en fin de tableau
des données et ces données splité en array, exemple (recherche
ordinateur ayant logiciel "apache" :

[13] => Array
(
   [separate] =>

   [value] => Array
  (
 [0] => Array
(
   [name] => Apache Tomcat 4.0 (remove only)
   [itemtype] => Software
   [items_id] => 1738
   [unit] =>
)
   )
)

Ca c'est à la sortie de constructData() et displayData() va afficher ça
correctement ;)
Pourquoi là on a un tableau de données alors que pour les autres tu met 
[1] [1_2]...

Je ne vois pas trop la logique.
Pareil pour les chaines avec des  et $$ pourquoi ne pas les splitter 
en sortie de constructdata ?


++

Julien


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[David DURIEUX]

Le Mon, 15 Oct 2012 14:12:32 +0200
MoYo  a écrit:

>
>>
>> Est-ce que celà vous parait bien?
>
>Salut,
>
>Et comment ca se comporte sur les meta recherches (plus rouge) ?

Ca se comporte bien au final, les data sont ajoutés en fin de tableau
des données et ces données splité en array, exemple (recherche
ordinateur ayant logiciel "apache" :

[13] => Array
   (
  [separate] => 

  [value] => Array
 (
[0] => Array
   (
  [name] => Apache Tomcat 4.0 (remove only)
  [itemtype] => Software 
  [items_id] => 1738
  [unit] => 
   )
  )
   )

Ca c'est à la sortie de constructData() et displayData() va afficher ça
correctement ;)

David
++

>++
>
>Julien
>
>
>
>___
>Glpi-dev mailing list
>Glpi-dev@gna.org
>https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[MoYo]

Est-ce que celà vous parait bien?


Salut,

Et comment ca se comporte sur les meta recherches (plus rouge) ?

++

Julien



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[David Durieux]

Finalement, j'ai modifié un peu la structure qui me semble un peu mieux 
comme ça :



Array
(
[cols] => Array
(
[0] => Array
(
[name] => Nom
[search_ID] => 1
[datatype] => itemlink
)

[1] => Array
(
[name] => Entité
[search_ID] => 80
[datatype] => dropdown
)

[2] => Array
(
[name] => Statut
[search_ID] => 31
[datatype] => dropdown
)

[3] => Array
(
[name] => Fabricant
[search_ID] => 23
[datatype] => dropdown
)

[4] => Array
(
[name] => Numéro de série
[search_ID] => 5
[datatype] => string
)

[5] => Array
(
[name] => Type
[search_ID] => 4
[datatype] => dropdown
)

[6] => Array
(
[name] => Modèle
[search_ID] => 40
[datatype] => dropdown
)

[7] => Array
(
[name] => Système d'exploitation
[search_ID] => 45
[datatype] => dropdown
)

[8] => Array
(
[name] => Lieu
[search_ID] => 3
[datatype] => dropdown
)

[9] => Array
(
[name] => Dernière modification
[search_ID] => 19
[datatype] => datetime
)

[10] => Array
(
[name] => Usager
[search_ID] => 17
[datatype] => string
)

[11] => Array
(
[name] => FusInv - Last inventory
[search_ID] => 5150
[datatype] => datetime
)

[12] => Array
(
[name] => IP
[search_ID] => 20
[datatype] =>
)

)

[rows] => Array
(
[0] => Array
(
[hidden] => Array
(
[currentuser] => glpi
[id] => 36
)

[visible] => Array
(
[0] => orditest-5290ed
[0_2] => 36
[1] => Entité racine
[2] =>
[3] => innotek GmbH
[4] =>
[5] =>
[6] => VirtualBox
[7] => Microsoft Windows XP Professionnel
[8] =>
[9] => 2012-10-10 21:49:29
[10] => ddurieux@ORDITEST-5290ED
[11] =>
[12] =>
)

)

[1] => Array
(
[hidden] => Array
(
[currentuser] => glpi
[id] => 34
)

[visible] => Array
(
[0] => port004
[0_2] => 34
[1] => Entité racine
[2] =>
[3] => TOSHIBA
[4] => XA201220H
[5] => Notebook
[6] => Satellite R630
[7] => freebsd
[8] =>
[9] => 2012-10-10 06:37:00
[10] => ddurieux
[11] =>
[12] => 
10.0.0.1$$106fe80::1$$103127.0.0.1$$104

)

)

)

)



Est-ce que celà vous parait bien?


David
++



On Thu, 11 Oct 2012 18:33:12 +0200, David DURIEUX wrote:

Je suis en train de reprendre le dev de ce ticket

Je sépare donc en 3 sous fonctions (comme le propose Remi) :

$sql = constructsql(...)
$data = constructdata($sql, ...)
displaydata($data, ...)


A la sortie de constructdata, j'ai un tableau de ce genre :



[...]


Est-ce que la sortie des data vous parait bien comme ça?

Si on valide ça je peux bosser sur l'affichage ;)

David
++

Re: [Glpi-dev] Patch pour le ticket #2476

[David DURIEUX]

Je suis en train de reprendre le dev de ce ticket

Je sépare donc en 3 sous fonctions (comme le propose Remi) : 

$sql = constructsql(...)
$data = constructdata($sql, ...)
displaydata($data, ...)


A la sortie de constructdata, j'ai un tableau de ce genre : 



Array
(
[cols] => Array
(
[0] => Array
(
[name] => Nom
[link]
=> ?itemtype=Computer&sort=1&order=DESC&start=0 [search_ID] => 1
[datatype] => itemlink
[itemtype] => Computer
)

[1] => Array
(
[name] => Entité
[link]
=> ?itemtype=Computer&sort=80&order=DESC&start=0
[search_ID] => 80 [datatype] => dropdown
[itemtype] => Computer
)

[2] => Array
(
[name] => Statut
[link]
=> ?itemtype=Computer&sort=31&order=DESC&start=0
[search_ID] => 31 [datatype] => dropdown
[itemtype] => Computer
)

[3] => Array
(
[name] => Fabricant
[link]
=> ?itemtype=Computer&sort=23&order=DESC&start=0
[search_ID] => 23 [datatype] => dropdown
[itemtype] => Computer
)

[4] => Array
(
[name] => Numéro de série
[link]
=> ?itemtype=Computer&sort=5&order=DESC&start=0 [search_ID]
=> 5 [datatype] => string
[itemtype] => Computer
)

[5] => Array
(
[name] => Type
[link]
=> ?itemtype=Computer&sort=4&order=DESC&start=0 [search_ID]
=> 4 [datatype] => dropdown
[itemtype] => Computer
)

[6] => Array
(
[name] => Modèle
[link]
=> ?itemtype=Computer&sort=40&order=DESC&start=0
[search_ID] => 40 [datatype] => dropdown
[itemtype] => Computer
)

[7] => Array
(
[name] => Système d'exploitation
[link]
=> ?itemtype=Computer&sort=45&order=DESC&start=0
[search_ID] => 45 [datatype] => dropdown
[itemtype] => Computer
)

[8] => Array
(
[name] => Lieu
[link]
=> ?itemtype=Computer&sort=3&order=DESC&start=0 [search_ID]
=> 3 [datatype] => dropdown
[itemtype] => Computer
)

[9] => Array
(
[name] => Dernière modification
[link]
=> ?itemtype=Computer&sort=19&order=DESC&start=0
[search_ID] => 19 [datatype] => datetime
[itemtype] => Computer
)

[10] => Array
(
[name] => Usager
[link]
=> ?itemtype=Computer&sort=17&order=DESC&start=0
[search_ID] => 17 [datatype] => string
[itemtype] => Computer
)

[11] => Array
(
[name] => FusInv - Last inventory
[link]
=> ?itemtype=Computer&sort=5150&order=DESC&start=0
[search_ID] => 5150 [datatype] => datetime
[itemtype] => Computer
)

[12] => Array
(
[name] => IP
[link]
=> ?itemtype=Computer&sort=20&order=DESC&start=0
[search_ID] => 20 [datatype] => 
[itemtype] => Computer
)

)

[rows] => Array
(
[0] => Array
(
[currentuser] => glpi
[ITEM_0] => orditest-5290ed
[ITEM_0_2] => 36
[ITEM_1] => Entité racine
[ITEM_2] => 
[ITEM_3] => innotek GmbH
[ITEM_4] => 
[ITEM_5] => 
[ITEM_6] => VirtualBox
[ITEM_7] => Microsoft Windows XP Professionnel
[ITEM_8] => 
[ITEM_9] => 2012-10-10 21:49:29
[ITEM_10] => ddurieux@ORDITEST-5290ED
[ITEM_11] => 
[ITEM_12] => 
[id] => 36
)

[1] => Array
(
[currentuser] => glpi
[ITEM_0] => port004
[ITEM_0_2] => 34
[ITEM_1] => Entité racine

[Glpi-dev] Patch pour le plugin appliances

[David DURIEUX]

Bonjour,

J'ai fais un patch pour l'INSERM, qui permet d'ajouter un champs de
recherche 'applitif - nom' dans les tickets afin de pouvoir faire une
recherche dessus.

Il est fait pour glpi 0.80.


Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE
Index: hook.php
===
--- hook.php	(revision 200)
+++ hook.php	(working copy)
@@ -256,6 +256,15 @@
array('table'  => 'glpi_plugin_appliances_appliances',
  'joinparams' => $sopt[1210]['joinparams'])));
   }
+  if ($itemtype == 'Ticket') {
+ $sopt[1212]['table'] = 'glpi_plugin_appliances_appliances';
+ $sopt[1212]['field'] = 'name';
+ $sopt[1212]['linkfield'] = 'items_id';
+
+ $sopt[1212]['massiveaction'] = false;
+ $sopt[1212]['name']  = $LANG['plugin_appliances']['title'][1]." - ".
+$LANG['common'][16];
+  }
}
return $sopt;
 }
@@ -471,4 +480,62 @@
 
$INJECTABLE_TYPES['PluginAppliancesApplianceInjection'] = 'appliances';
 }
+
+
+function plugin_appliances_addWhere($link,$nott,$type,$id,$val,$searchtype) {
+
+   $searchopt = &Search::getOptions($type);
+   $table = $searchopt[$id]["table"];
+   $field = $searchopt[$id]["field"];
+   
+   switch ($type) {
+
+  case 'Ticket':
+ if ($table.".".$field == "glpi_plugin_appliances_appliances.name") {
+$out = '';
+switch ($searchtype) {
+   case "contains" :
+  $SEARCH = Search::makeTextSearch($val, $nott);
+  break;
+
+   case "equals" :
+  if ($nott) {
+ $SEARCH = " <> '$val'";
+  } else {
+ $SEARCH = " = '$val'";
+  }
+  break;
+
+   case "notequals" :
+  if ($nott) {
+ $SEARCH = " = '$val'";
+  } else {
+ $SEARCH = " <> '$val'";
+  }
+  break;
+
+}
+if (in_array($searchtype, array('equals', 'notequals'))) {
+   if ($table != getTableForItemType($type) || $type == 'States') {
+  $out = " $link (`glpi_plugin_appliances_appliances_items_id`.`id`".$SEARCH;
+   } else {
+  $out = " $link (`glpi_plugin_appliances_appliances_items_id`.`$field`".$SEARCH;
+   }
+   if ($searchtype=='notequals') {
+  $nott = !$nott;
+   }
+   // Add NULL if $val = 0 and not negative search
+   // Or negative search on real value
+   if ((!$nott && $val==0) || ($nott && $val != 0)) {
+  $out .= " OR `glpi_plugin_appliances_appliances_items_id`.`id` IS NULL";
+   }
+   $out .= ')';
+} else {
+   $out = Search::makeTextCriteria("`glpi_plugin_appliances_appliances_items_id`.".$field,$val,$nott,$link);
+}
+return $out." AND `glpi_tickets`.`itemtype`='PluginAppliancesAppliance'";
+ }
+ break;
+   }
+}
 ?>
\ No newline at end of file
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] [PATCH] block the creation of a ipnetwork with no ipaddress (0.84)

[Gonéri Le Bouder]

This changes block ipnetwork creation if the "network" field
is empty.
---
 inc/ipnetwork.class.php |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/inc/ipnetwork.class.php b/inc/ipnetwork.class.php
index a194978..5eb063e 100644
--- a/inc/ipnetwork.class.php
+++ b/inc/ipnetwork.class.php
@@ -198,7 +198,10 @@ class IPNetwork extends CommonImplicitTreeDropdown {
   // Or if $this->fields["network"] != $input["network"] we a
updating the network
   $address = new IPAddress();
   $netmask = new IPNetmask();
-  if (!isset($this->fields["id"])
+  if (!$input["network"]) {
+ return array('error' => __('Invalid network address'),
+'input' => false);
+  } else if (!isset($this->fields["id"])
   || ($input["network"] != $this->fields["network"])) {
  $network = explode ("/", $input["network"]);
  if (count($network) != 2) {
-- 
1.7.10

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour remplacer les images par du CSS3 dans la box

[Julien Dombre]

Salut,

vu que la proposition a bien été testé sur de nombreux navigateurs, 
j'attends un patch complet pour intégration.


++

Julien



Le 06/04/2012 00:28, Sylvain Briallon a écrit :

Je reviens sur la proposition de remise en forme de la BOX en CSS3.

Voici les patchs. malheureusement ceux ci n'ont pu être testé que sur FF
Si certain voulait bien tester sur d'autre navigateur...!

Dans tout les cas, cela optimise largement cette affichage.

Glooob


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour remplacer les images par du CSS3 dans la box

[Jean-Mathieu Doleans]

Merci pour votre patch.

C'est en revanche ennuyeux qu'il n'ait été testé que sous FF. 90% des soucis ne 
se posent pas sur ce navigateur mais sur un autre tristement célèbre.

L'application de style css3 sur la 0.84 nous a déjà amené à faire plusieurs 
contorsions pour arriver à un résultat satisfaisant.



--
Jean-Mathieu Doléans

Sylvain Briallon  a écrit :

>Je reviens sur la proposition de remise en forme de la BOX en CSS3.
>
>Voici les patchs. malheureusement ceux ci n'ont pu être testé que sur FF
>Si certain voulait bien tester sur d'autre navigateur...!
>
>Dans tout les cas, cela optimise largement cette affichage.
>
>Glooob
>
>___
>Glpi-dev mailing list
>Glpi-dev@gna.org
>https://mail.gna.org/listinfo/glpi-dev
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch for feature #3476

[jmd]

Hi,

On Fri, 13 Apr 2012 13:35:52 +0200, Nahir MOHAMED wrote:

Hi all,

I submit today a patch for this feature
https://forge.indepnet.net/issues/3476



Thank you for you interest in GLPI Project and your contribution.

The patch would be apply ASAP.

Best regards,

--
Jean-Mathieu Doléans
GLPI-PROJECT.ORG

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch for feature #3476

[Nahir MOHAMED]

Hi all,

I submit today a patch for this feature 
https://forge.indepnet.net/issues/3476


Regards
Thanks

--
Nahir MOHAMED
Consultant Technique
Open Source Center
Atos Intégration
nmoha...@portaildulibre.fr
Tél : +33 (0)1.73.26.39.53


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour afficher le nombre de ticket

[Remi Collet]

Le 07/04/2012 08:14, Remi Collet a écrit :
> Je l'ai traité un peu différemment en affichant, p.e. (3 sur 12)
> https://forge.indepnet.net/issues/3452

Je viens d'ajouter la possibilité de demander l'affichage d'aucun
ticket. Dans ce cas on a juste le compteur.

à voir si cela vous semble pertinent avant de l'appliquer en 0.83.1

++


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour afficher le nombre de ticket

[Remi Collet]

Le 05/04/2012 23:53, Sylvain Briallon a écrit :
> Bonjour a tous,
> 
> Suite au message http://www.glpi-project.org/forum/viewtopic.php?pid=141647
> 
> Le patch n'a rien de glorieux... mais il évitera de faire perdre du
> temps a un développeur si celui ci est validé.

Merci pour cette proposition.

> Il ajoute uniquement le nombre de ticket entre parenthèse sur la page
> d'accueil.

Je l'ai traité un peu différemment en affichant, p.e. (3 sur 12)
https://forge.indepnet.net/issues/3452

Remi.

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour remplacer les images par du CSS3 dans la box

[jean-Mathieu Doléans]

Bonjour,

Merci pour votre contribution.

Le 06/04/2012 00:28, Sylvain Briallon a écrit :

Je reviens sur la proposition de remise en forme de la BOX en CSS3.

Voici les patchs. malheureusement ceux ci n'ont pu être testé que sur FF
Si certain voulait bien tester sur d'autre navigateur...!


Il est toutefois dommage que celle-ci n'ait pas été testée sur d'autres 
navigateurs. En effet 90% des problèmes ne se posent pas sur FF mais sur 
un autre navigateur tristement célèbre.


Pour l'intégration de style CSS3 pour certaines partie de la 0.84 nous 
avons été obligés de faire pas mal de contorsions pour arriver à un 
affichage équivalent sur l'ensemble des navigateurs.



Cordialement,

--
Jean-Mathieu Doléans
GLPI-PROJECT

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch pour remplacer les images par du CSS3 dans la box

[Sylvain Briallon]

Je reviens sur la proposition de remise en forme de la BOX en CSS3.

Voici les patchs. malheureusement ceux ci n'ont pu être testé que sur FF
Si certain voulait bien tester sur d'autre navigateur...!

Dans tout les cas, cela optimise largement cette affichage.

Glooob


html.class.php.patch
Description: Binary data


styles.css.patch
Description: Binary data
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch pour afficher le nombre de ticket

[Sylvain Briallon]

Bonjour a tous,

Suite au message http://www.glpi-project.org/forum/viewtopic.php?pid=141647

Le patch n'a rien de glorieux... mais il évitera de faire perdre du temps a
un développeur si celui ci est validé.

Il ajoute uniquement le nombre de ticket entre parenthèse sur la page
d'accueil.

Bonne journée.


ticket.class.php.patch
Description: Binary data
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[Remi Collet]

Le 01/04/2012 08:13, MoYo a écrit :
> Le 01/04/2012 00:00, David DURIEUX a écrit :
>>> par exemple.
>>> Après la grande question sur le sujet c'est est-ce que le retour du
>>> $result SQL est satisfaisant.
>>> Sur le ticket, il est indiqué une fonction qui renvoie un tableau des
>>> données et une autre qui affiche les données.
>> Je me disait que renvoyer le $result serait plus simple que de
>> renvoyer un gros tableau (traitement pour renvoyer un array() au lieu
>> de renvoyer le $result et faire un foreach derrière).
>>
>> Dis moi ce qui te semble le mieux : tableau de donnée ou $result.
> 
> Je ne me base que sur le ticket est c'est un tableau qui est spécifier.
> Après ca mérite surement discussion sur le format et l'organisation de
> celui-ci.

L'idée c'est que le "result" permet de récupérer des données, mais qui
seront particulièrement difficile à traiter (nom des colonnes générées).

Si on veut un truc utilisable et générique, clairement le $result n'est
pas satisfaisant.

Effectivement

1/ on pourrait imaginer un split en 3

$sql = constructsql(...)
$data = constructdata($sql, ...)
displaydata($data, ...)

2/ il faut spécifier le contenu du tableau

première idée :

[cols]
name => description
...
[rows]
[0]
name => value
...
[1]
...

Avec
name => nom dans le résultat (SQL)
description => libellé de la colonne
value => ben... value quoi

Mais c'est probablement insuffisant
- le datatype ? (nécessaire pour l'affichage)
- le mode d'affichage (text, html, nécessaire par exemple quand on a un
lien vers un objet)
- etc (j'en oublie forcément)

à discuter donc.

++

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[MoYo]

Le 01/04/2012 00:00, David DURIEUX a écrit :

par exemple.
Après la grande question sur le sujet c'est est-ce que le retour du
$result SQL est satisfaisant.
Sur le ticket, il est indiqué une fonction qui renvoie un tableau des
données et une autre qui affiche les données.

Je me disait que renvoyer le $result serait plus simple que de
renvoyer un gros tableau (traitement pour renvoyer un array() au lieu
de renvoyer le $result et faire un foreach derrière).

Dis moi ce qui te semble le mieux : tableau de donnée ou $result.


Je ne me base que sur le ticket est c'est un tableau qui est spécifier.
Après ca mérite surement discussion sur le format et l'organisation de 
celui-ci.

Il faut peut-être revoir certaines choses je ne sais pas.

++

Julien



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[David DURIEUX]

Le Sat, 31 Mar 2012 23:14:18 +0200
Julien Dombre  a écrit:

>Le 31/03/2012 22:44, David DURIEUX a écrit :
>> Voici le patch pour le ticket #2476
>>
>>
>> Voici ce que j'ai fait :
>>
>> * Rajouté des options à la fonction 'Search::showGenericSearch' afin
>> de pouvoir l'intégrer dans un formulaire (cf le screenshot)
>>
>> * Scindé lea fonction 'Search::showList' en 2 afin de pouvoir avoir
>> la requete SQL d'un coté, et l'affichage de l'autre. On a toujours la
>>fonction 'Search::showList' mais j'ai rajouté la fonction
>>'Search::constructSQL' qui construit la requête.
>
>Salut,
>
>
>merci pour le contribution.
>
>Une remarque rapide, on en rediscute en direct si tu veux :
>scinder la fonction en 2 pour moi ca voulait dire que la fonction même 
>ne changeait pas mais qu'on appelait 2 fonctions dans cette fonction 
>afin de ne pas changer le prototypage de celle-ci...
>function showList(...) {
>$datas = getDatas();
>displayDatas($datas);
>}

Ah oui en effet, on peut faire comme ça ;)


>par exemple.
>Après la grande question sur le sujet c'est est-ce que le retour du 
>$result SQL est satisfaisant.
>Sur le ticket, il est indiqué une fonction qui renvoie un tableau des 
>données et une autre qui affiche les données.

Je me disait que renvoyer le $result serait plus simple que de
renvoyer un gros tableau (traitement pour renvoyer un array() au lieu
de renvoyer le $result et faire un foreach derrière). 

Dis moi ce qui te semble le mieux : tableau de donnée ou $result.

David
++


>++
>
>Julien
>
>
>
>
>>
>>
>> J'ai testé avec le plugin Monitoring sur la 0.84 et ça permet de
>> faire ce qu'on veut avec le moteur de recherche, cf la capture
>> d'écran pour une 'règle monitoring' se basant sur le moteur de
>> recherche. Celà fonctionne aussi dans ce même plugin avec uniquement
>> l'utilisation de la fonction 'Search::constructSQL' qui se charge de
>> faire la requete, laquelle que j'exploite derrière pour récupérer la
>> liste des items.
>>
>>
>> J'ai fait pas mal de tests, je n'ai pas vu de régression.
>>
>> David
>> ++
>>
>>
>> ___
>> Glpi-dev mailing list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev
>

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour le ticket #2476

[Julien Dombre]

Le 31/03/2012 22:44, David DURIEUX a écrit :

Voici le patch pour le ticket #2476


Voici ce que j'ai fait :

* Rajouté des options à la fonction 'Search::showGenericSearch' afin de
   pouvoir l'intégrer dans un formulaire (cf le screenshot)

* Scindé lea fonction 'Search::showList' en 2 afin de pouvoir avoir la
   requete SQL d'un coté, et l'affichage de l'autre. On a toujours la
   fonction 'Search::showList' mais j'ai rajouté la fonction
   'Search::constructSQL' qui construit la requête.


Salut,


merci pour le contribution.

Une remarque rapide, on en rediscute en direct si tu veux :
scinder la fonction en 2 pour moi ca voulait dire que la fonction même 
ne changeait pas mais qu'on appelait 2 fonctions dans cette fonction 
afin de ne pas changer le prototypage de celle-ci...

function showList(...) {
$datas = getDatas();
displayDatas($datas);
}

par exemple.
Après la grande question sur le sujet c'est est-ce que le retour du 
$result SQL est satisfaisant.
Sur le ticket, il est indiqué une fonction qui renvoie un tableau des 
données et une autre qui affiche les données.


++

Julien







J'ai testé avec le plugin Monitoring sur la 0.84 et ça permet de faire
ce qu'on veut avec le moteur de recherche, cf la capture d'écran pour
une 'règle monitoring' se basant sur le moteur de recherche. Celà
fonctionne aussi dans ce même plugin avec uniquement l'utilisation de
la fonction 'Search::constructSQL' qui se charge de faire la requete,
laquelle que j'exploite derrière pour récupérer la liste des items.


J'ai fait pas mal de tests, je n'ai pas vu de régression.

David
++


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [Patch] Possibilité de modifier les dates dans les cartouches

[Julien Dombre]

Bonjour,

Patch adapté et appliqué en 0.83.

Merci de votre contribution

Cordialement,

Julien Dombre

Le 21/03/2012 09:29, Julien Dombre a écrit :

Bonjour,

désolé pour la réponse tardive.

je viens de déplacer le ticket correspondant (que j'ai découpé en 2).
Je vais étudier votre proposition pour une intégration en 0.83.

Cordialement,

Julien Dombre


Le 08/03/2012 09:31, BRICCHI Jérôme a écrit :

Bonjour,

Pour répondre à un besoin spécifique à notre fonctionnement j'ai du 
modifier les sources de GLPI :


Contexte :
Actuellement lors de la remise de cartouche d'encre à un utilisateur, 
une feuille de papier est renseigné avec la date et la/les modèles de 
cartouches.
La personne qui s'occupe de l'inventaire rassemble ces feuilles 
toutes les fins de mois pour les saisir dans GLPI.


Problème :
La saisie pouvant s'effectuer bien après la date de remise, pour des 
besoins de statistique pertinente, il est impossible d'antidaté une 
opération.


Solution :
Dans Inventaire >Imprimantes :
- Dans Cartouches utilisées, lorsqu'on installe une cartouche 
possibilité de modifier la Date utilisation.
- Dans Cartouches usagées, lorsqu'on passe en Fin de vie une 
cartouche, possibilité de modifier la Date fin.


Screenshot du résultat :
Voir en PJ

Demandes similaire sur le forum :
http://www.glpi-project.org/forum/viewtopic.php?id=4556
http://www.glpi-project.org/forum/viewtopic.php?id=9733
http://www.glpi-project.org/forum/viewtopic.php?id=5740


Un ticket existe mais il parle aussi d'une autre fonctionnalité (tout 
aussi intéressante), je pense qu'il faudrait les séparer :

https://forge.indepnet.net/issues/776


Patch :
Ce patch s'applique à la version 0.80.7 de GLPI, j'espère que c'est 
propre (je suis très loin d'être un expert wink)
Je vous le propose en espérant qu'il soit intégré à GLPI. D'ailleurs 
ce serai une bonne idée que cette fonctionnalité s'étende aux autres 
élément de l'inventaire (exemple : la date d'ajout des consommables) 
au besoin en ajoutant un droit supplémentaire dans les profils.


Bien Cordialement

BRICCHI Jérôme
Service informatique - Mairie de Saint Laurent du Var


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev




___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] [Patch] Possibilité de modifier les dates dans les cartouches

[Julien Dombre]

Bonjour,

désolé pour la réponse tardive.

je viens de déplacer le ticket correspondant (que j'ai découpé en 2).
Je vais étudier votre proposition pour une intégration en 0.83.

Cordialement,

Julien Dombre


Le 08/03/2012 09:31, BRICCHI Jérôme a écrit :

Bonjour,

Pour répondre à un besoin spécifique à notre fonctionnement j'ai du 
modifier les sources de GLPI :


Contexte :
Actuellement lors de la remise de cartouche d'encre à un utilisateur, 
une feuille de papier est renseigné avec la date et la/les modèles de 
cartouches.
La personne qui s'occupe de l'inventaire rassemble ces feuilles toutes 
les fins de mois pour les saisir dans GLPI.


Problème :
La saisie pouvant s'effectuer bien après la date de remise, pour des 
besoins de statistique pertinente, il est impossible d'antidaté une 
opération.


Solution :
Dans Inventaire >Imprimantes :
- Dans Cartouches utilisées, lorsqu'on installe une cartouche 
possibilité de modifier la Date utilisation.
- Dans Cartouches usagées, lorsqu'on passe en Fin de vie une 
cartouche, possibilité de modifier la Date fin.


Screenshot du résultat :
Voir en PJ

Demandes similaire sur le forum :
http://www.glpi-project.org/forum/viewtopic.php?id=4556
http://www.glpi-project.org/forum/viewtopic.php?id=9733
http://www.glpi-project.org/forum/viewtopic.php?id=5740


Un ticket existe mais il parle aussi d'une autre fonctionnalité (tout 
aussi intéressante), je pense qu'il faudrait les séparer :

https://forge.indepnet.net/issues/776


Patch :
Ce patch s'applique à la version 0.80.7 de GLPI, j'espère que c'est 
propre (je suis très loin d'être un expert wink)
Je vous le propose en espérant qu'il soit intégré à GLPI. D'ailleurs 
ce serai une bonne idée que cette fonctionnalité s'étende aux autres 
élément de l'inventaire (exemple : la date d'ajout des consommables) 
au besoin en ajoutant un droit supplémentaire dans les profils.


Bien Cordialement

BRICCHI Jérôme
Service informatique - Mairie de Saint Laurent du Var


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch pour bug cartouche

[Julien Dombre]

Bonjour,

merci pour le patch il vient d'être appliqué.

Cordialement,

Julien Dombre


Le 20/03/2012 03:37, Sylvain Briallon a écrit :
Suite au ticket sur le forum 
 voici le 
patch pour corriger celui ci.


Précision : Aucun rapport avec la modification proposé cette semaine 
pour les cartouches, le bug y était avant.


J'en ai profité pour quelques amélioration en plus
 - ne pas afficher la partie "actions" si uniquement les droits en 
lecture.
 - Meilleur gestion des tableaux au niveau cartouche mais aussi sur la 
partie imprimante.

 - Passage en gras des moyennes... (c'est une suggestion bien sur ;) )

Bonne journée.
Glooob


Le 19 mars 2012 23 :19, MoYo > a écrit :


Le 19/03/2012 06:03, Sylvain Briallon a écrit :

Apres les cartouches d'encre, voici les consommables.

http://postimage.org/image/4bsa0ilut/   (avant)
http://postimage.org/image/dxlugtd0l/   (apres)

Les optimisations,
 - Mise en place du "donner à" en bas, je ne sais pas si vous
apprécierez mais je trouve cela plus parlant.


Salut,

l'intérêt du donner à en haut est sa position fixe. Avec un donner
à en bas, sa position est fonction de la taille de la liste des
consommables. Si vous en avez 100 par exemple, atteindre le donner
à peut être compliqué.

Je regarde tout ca demain.

++

Julien



 - Correction du pluriel dans l’état "utilisé(s)"
 - suppression du "supprimer" si nous n'avons que les droits
en lecture.
 - suppression de la "date d'utilisation" dans "neufs"
 - et quelques minis trucs...

Voila!
A vous de me dire ce que vous en pensez.





___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch pour bug cartouche

[Sylvain Briallon]

Suite au ticket sur le
forum voici
le patch pour corriger celui ci.

Précision : Aucun rapport avec la modification proposé cette semaine pour
les cartouches, le bug y était avant.

J'en ai profité pour quelques amélioration en plus
 - ne pas afficher la partie "actions" si uniquement les droits en lecture.
 - Meilleur gestion des tableaux au niveau cartouche mais aussi sur la
partie imprimante.
 - Passage en gras des moyennes... (c'est une suggestion bien sur ;) )

Bonne journée.
Glooob


Le 19 mars 2012 23:19, MoYo  a écrit :

> Le 19/03/2012 06:03, Sylvain Briallon a écrit :
>
>  Apres les cartouches d'encre, voici les consommables.
>>
>> http://postimage.org/image/**4bsa0ilut/
>>   (avant)
>> http://postimage.org/image/**dxlugtd0l/
>>   (apres)
>>
>> Les optimisations,
>>  - Mise en place du "donner à" en bas, je ne sais pas si vous apprécierez
>> mais je trouve cela plus parlant.
>>
>
> Salut,
>
> l'intérêt du donner à en haut est sa position fixe. Avec un donner à en
> bas, sa position est fonction de la taille de la liste des consommables. Si
> vous en avez 100 par exemple, atteindre le donner à peut être compliqué.
>
> Je regarde tout ca demain.
>
> ++
>
> Julien
>
>
>
>   - Correction du pluriel dans l’état "utilisé(s)"
>>  - suppression du "supprimer" si nous n'avons que les droits en lecture.
>>  - suppression de la "date d'utilisation" dans "neufs"
>>  - et quelques minis trucs...
>>
>> Voila!
>> A vous de me dire ce que vous en pensez.
>>
>
>


cartridge.class.php.diff
Description: Binary data
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch for plugin Customfields

[Alexandre Delaunay]

Thank you for the advice.

I followed this one and got the rights to commit this morning.
So i'll send my changes quickly on the trunk.

Regards.
-- 
Alexandre Delaunay (adelau...@teclib.com)
teclib' - Développeur POO - http://www.teclib.com
tel : 01 79 97 72 90


 Message initial 
De: Julien Dombre 
Reply-to: Liste de diffusion des developpeurs GLPI 
À: glpi-dev@gna.org
Sujet: Re: [Glpi-dev] Patch for plugin Customfields
Date: Tue, 13 Mar 2012 13:01:53 +0100

Le 09/03/2012 15:59, adelaunay a écrit : 
> Is it possible to include my patch into the main branch ?

Hi,

easiest way is to contact the manager of the plugins.
They could give you access to the SVN repository if patch is acceptable.

Regards

Julien Dombre


> 
> Regards.
> 
> 
> 
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] patch a david sur l'ajout des groupes 0

[David DURIEUX]

Le patch de Remi fonctionne bien et mieux que le mien :
https://forge.indepnet.net/projects/glpi/repository/revisions/17849/diff

Merci

David
++

Le Thu, 15 Mar 2012 08:01:17 +0100 (CET)
Remi  a écrit:

>Je pense que le patch va poser des problèmes lors de l'ajout des
>utilisateurs anonyme (id=0 mais email)
>
>Le problème vient, je pense du controle dans CommonDBRelation (ligne
>~133)
>
> // id==0 is used in some relation (tickets_users)
> if ($input[$this->items_id_2]>0
> && !$item2->getFromDB($input[$this->items_id_2])) { return false;
> }
>
>
>ça mériterait une petite correction... (en 0.83 le problème signalé
>par david est bloqué par les contrôles en amont)
>
>Genre un attribut "allow relation to 0" qui serait vrai uniquement
>pour les ticket_user.
>
>
>___
>Glpi-dev mailing list
>Glpi-dev@gna.org
>https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] patch a david sur l'ajout des groupes 0

[Remi]

Je pense que le patch va poser des problèmes lors de l'ajout des utilisateurs 
anonyme (id=0 mais email)

Le problème vient, je pense du controle dans CommonDBRelation (ligne ~133)

 // id==0 is used in some relation (tickets_users)
 if ($input[$this->items_id_2]>0 && 
!$item2->getFromDB($input[$this->items_id_2])) {
return false;
 }


ça mériterait une petite correction... (en 0.83 le problème signalé par david 
est bloqué par les contrôles en amont)

Genre un attribut "allow relation to 0" qui serait vrai uniquement pour les 
ticket_user.


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch for plugin Customfields

[Julien Dombre]

Le 09/03/2012 15:59, adelaunay a écrit :

Is it possible to include my patch into the main branch ?


Hi,

easiest way is to contact the manager of the plugins.
They could give you access to the SVN repository if patch is acceptable.

Regards

Julien Dombre




Regards.



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch pour xhprof

[Remi Collet]

Salut,

Je test actuellement "xhprof",

En P.J. un petit patch qui permet d'ajouter un lien vers les résultats
du "profiling" de la page au début des infos de debug.

J'essaierai de vous donner ici quelques résultats intéressants, si j'en
obtient.

++
Index: inc/html.class.php
===
--- inc/html.class.php	(révision 17689)
+++ inc/html.class.php	(copie de travail)
@@ -522,6 +522,19 @@
  echo "";
  echo "GLPI MODE DEBUG";
 
+ if (defined('XHPROF_PATH')
+&& function_exists('xhprof_enable')) {
+// stop profiler
+$xhprof_data = xhprof_disable();
+include_once XHPROF_PATH."/xhprof_lib/utils/xhprof_lib.php";
+include_once XHPROF_PATH."/xhprof_lib/utils/xhprof_runs.php";
+
+$xhprof_runs = new XHProfRuns_Default();
+$run_id = $xhprof_runs->save_run($xhprof_data, "glpi");
+
+echo "Profiling: XHPROF";
+ }
+
  if ($CFG_GLPI["debug_sql"]) {
 echo "SQL REQUEST : ";
 echo $SQL_TOTAL_REQUEST." Queries ";
@@ -920,6 +933,13 @@
   }
   $HEADER_LOADED = true;
 
+  // mode debug with profiling
+  if ($_SESSION['glpi_use_mode'] == Session::DEBUG_MODE
+ && defined('XHPROF_PATH')
+ && function_exists('xhprof_enable')) {
+ xhprof_enable();
+  }
+
   self::includeHeader($title);
   // Body
   echo "";
@@ -1096,7 +1116,7 @@
  $menu['inventory']['content']['internet']['shortcut'] = '';
  $menu['inventory']['content']['internet']['page'] = '/front/internet.php';
  $menu['inventory']['content']['internet']['links']['search']  = '/front/internet.php';
-  
+
  $menu['inventory']['content']['internet2']['title']= __('Internet2');
  $menu['inventory']['content']['internet2']['shortcut'] = '';
  $menu['inventory']['content']['internet2']['page'] = '/front/internet2.php';
<>
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : Ajout nouvelle option import OCS des moniteurs

[Julien Dombre]

Bonjour,

patch appliqué.

merci

Julien


Le 26/01/2012 17:46, Thierry Barrau a écrit :


Bonjour Moyo,

Merci de ta réponse.

Je ne sais pas si on aura beaucoup de retour, car c'est un problème 
qui ne concerne que les personnes qui travaillent en multi écran (voir 
en multi écran ordinateur portable + écran externe), et ils ne sont 
pas légion ... même si il y en a de plus en plus .


Le fonctionnement actuel permet soit :

-Import unique :

oImporte tous les écrans dont tous les « unknow XXX » qui sont les 
écrans intégrés des ordinateurs portables.


-Import unique sur numéro de série :

oN'importe que si « tous » les écrans ont un numéro de série, si l'un 
d'eux n'en a pas, alors celui qui en a bien un sera ignoré.


Au-delà du problème lui-même, c'est la description de la 
fonctionnalité qui est trompeuse dans la doc :


-« Import unique sur numéro de série : ne s'applique qu'aux moniteurs. 
N'importe l'écran dans GLPI que si le moniteur a un numéro de série. »


De base, on se dit que le comportement désiré n'est l'import que des 
écrans disposants d'un numéro de série et pas des autres (« unknow », 
etc...). D'où le fait je pense aussi d'éclaircir la doc sur le sujet.


Pour rappel mon post à l'époque sur le forum : 
http://www.glpi-project.org/forum/viewtopic.php?id=25074


Et le post de cenid35 qui avait le même problème que moi : 
http://www.glpi-project.org/forum/viewtopic.php?id=25811


Je peux lui proposer de tester le patch pour voir si ça corrige son 
problème ...


Bonne soirée et merci du temps consacré à la lecture de ce mail ;)

--

Thierry BARRAU

*De :*glpi-dev-boun...@gna.org [mailto:glpi-dev-boun...@gna.org] *De 
la part de* MoYo

*Envoyé :* jeudi 26 janvier 2012 17:03
*À :* glpi-dev@gna.org
*Objet :* Re: [Glpi-dev] Patch : Ajout nouvelle option import OCS des 
moniteurs


Bonjour,

désolé pour le délai de la réponse.
Nous allons étudier la proposition.
Ce qui nous intéresserai c'est surtout d'avoir des avis sur la 
fonctionnalité en elle même.

Intéresse t'elle d'autres personnes ou pas ?
Cela impactera sur l'intégration rapide (0.83) ou pas (version 
corrective 0.83).


Cordialement,

Julien Dombre


Le 09/01/2012 18:18, Thierry Barrau a écrit :

Bonjour,

Comme discuté à plusieurs reprises, l'option actuelle « Import sur 
numéro de série » n'importe, dans le cas de multi écran sur un 
ordinateur, que si l'ensemble des écrans de cette machine dispose d'un 
numéro de série.


Remi, ayant développé cette partie, m'a conseillé de partir sur une 
nouvelle option si je souhaitais modifier le comportement pour que 
seuls les écrans disposant d'un numéro de série ne soient traités.


Voici donc les patchs (pour la version 0.83) pour l'ajout d'une 
nouvelle option que nommée « Import unique numéro de série 
uniquement » (je pense qu'il faudrait peut être revoir les 
dénominations des deux intitulés pour que cela soit plus explicite).


Egalement, voici une proposition de modification du paragraphe 
décrivant les imports de la documentation :


*Import unique sur numéro de série *: ne s'applique qu'aux moniteurs. 
N'importe l'écran dans GLPI que si tous les moniteurs ont un numéro de 
série.


*Import unique numéro de série uniquement *: ne s'applique qu'aux 
moniteurs. N'importe dans GLPI que les moniteurs ayant un numéro de série.


Espérant que ça aide.

Cordialement,

--

Thierry BARRAU

  
  
___

Glpi-dev mailing list
Glpi-dev@gna.org  <mailto:Glpi-dev@gna.org>
https://mail.gna.org/listinfo/glpi-dev



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : Ajout nouvelle option import OCS des moniteurs

[Thierry Barrau]

Bonjour Moyo,

Merci de ta réponse.

Je ne sais pas si on aura beaucoup de retour, car c'est un problème qui ne 
concerne que les personnes qui travaillent en multi écran (voir en multi écran 
ordinateur portable + écran externe), et ils ne sont pas légion ... même si il 
y en a de plus en plus .

Le fonctionnement actuel permet soit :

-  Import unique :

o   Importe tous les écrans dont tous les « unknow XXX » qui sont les écrans 
intégrés des ordinateurs portables.

-  Import unique sur numéro de série :

o   N'importe que si « tous » les écrans ont un numéro de série, si l'un d'eux 
n'en a pas, alors celui qui en a bien un sera ignoré.

Au-delà du problème lui-même, c'est la description de la fonctionnalité qui est 
trompeuse dans la doc :

-  « Import unique sur numéro de série : ne s'applique qu'aux 
moniteurs. N'importe l'écran dans GLPI que si le moniteur a un numéro de série. 
»
De base, on se dit que le comportement désiré n'est l'import que des écrans 
disposants d'un numéro de série et pas des autres (« unknow », etc...). D'où le 
fait je pense aussi d'éclaircir la doc sur le sujet.

Pour rappel mon post à l'époque sur le forum : 
http://www.glpi-project.org/forum/viewtopic.php?id=25074
Et le post de cenid35 qui avait le même problème que moi : 
http://www.glpi-project.org/forum/viewtopic.php?id=25811

Je peux lui proposer de tester le patch pour voir si ça corrige son problème ...

Bonne soirée et merci du temps consacré à la lecture de ce mail ;)

--
Thierry BARRAU

De : glpi-dev-boun...@gna.org [mailto:glpi-dev-boun...@gna.org] De la part de 
MoYo
Envoyé : jeudi 26 janvier 2012 17:03
À : glpi-dev@gna.org
Objet : Re: [Glpi-dev] Patch : Ajout nouvelle option import OCS des moniteurs

Bonjour,

désolé pour le délai de la réponse.
Nous allons étudier la proposition.
Ce qui nous intéresserai c'est surtout d'avoir des avis sur la fonctionnalité 
en elle même.
Intéresse t'elle d'autres personnes ou pas ?
Cela impactera sur l'intégration rapide (0.83) ou pas (version corrective 0.83).

Cordialement,

Julien Dombre


Le 09/01/2012 18:18, Thierry Barrau a écrit :
Bonjour,

Comme discuté à plusieurs reprises, l'option actuelle « Import sur numéro de 
série » n'importe, dans le cas de multi écran sur un ordinateur, que si 
l'ensemble des écrans de cette machine dispose d'un numéro de série.

Remi, ayant développé cette partie, m'a conseillé de partir sur une nouvelle 
option si je souhaitais modifier le comportement pour que seuls les écrans 
disposant d'un numéro de série ne soient traités.

Voici donc les patchs (pour la version 0.83) pour l'ajout d'une nouvelle option 
que nommée « Import unique numéro de série uniquement » (je pense qu'il 
faudrait peut être revoir les dénominations des deux intitulés pour que cela 
soit plus explicite).

Egalement, voici une proposition de modification du paragraphe décrivant les 
imports de la documentation :

Import unique sur numéro de série : ne s'applique qu'aux moniteurs. N'importe 
l'écran dans GLPI que si tous les moniteurs ont un numéro de série.

Import unique numéro de série uniquement : ne s'applique qu'aux moniteurs. 
N'importe dans GLPI que les moniteurs ayant un numéro de série.

Espérant que ça aide.

Cordialement,
--
Thierry BARRAU





___

Glpi-dev mailing list

Glpi-dev@gna.org<mailto:Glpi-dev@gna.org>

https://mail.gna.org/listinfo/glpi-dev

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : Ajout nouvelle option import OCS des moniteurs

[MoYo]

Bonjour,

désolé pour le délai de la réponse.
Nous allons étudier la proposition.
Ce qui nous intéresserai c'est surtout d'avoir des avis sur la 
fonctionnalité en elle même.

Intéresse t'elle d'autres personnes ou pas ?
Cela impactera sur l'intégration rapide (0.83) ou pas (version 
corrective 0.83).


Cordialement,

Julien Dombre


Le 09/01/2012 18:18, Thierry Barrau a écrit :


Bonjour,

Comme discuté à plusieurs reprises, l'option actuelle « Import sur 
numéro de série » n'importe, dans le cas de multi écran sur un 
ordinateur, que si l'ensemble des écrans de cette machine dispose d'un 
numéro de série.


Remi, ayant développé cette partie, m'a conseillé de partir sur une 
nouvelle option si je souhaitais modifier le comportement pour que 
seuls les écrans disposant d'un numéro de série ne soient traités.


Voici donc les patchs (pour la version 0.83) pour l'ajout d'une 
nouvelle option que nommée « Import unique numéro de série 
uniquement » (je pense qu'il faudrait peut être revoir les 
dénominations des deux intitulés pour que cela soit plus explicite).


Egalement, voici une proposition de modification du paragraphe 
décrivant les imports de la documentation :


·*Import unique sur numéro de série *: ne s'applique qu'aux moniteurs. 
N'importe l'écran dans GLPI que si tous les moniteurs ont un numéro de 
série.


·*Import unique numéro de série uniquement *: ne s'applique qu'aux 
moniteurs. N'importe dans GLPI que les moniteurs ayant un numéro de série.


Espérant que ça aide.

Cordialement,

--

Thierry BARRAU


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch : Ajout nouvelle option import OCS des moniteurs

[Thierry Barrau]

Bonjour,

Comme discuté à plusieurs reprises, l'option actuelle « Import sur numéro de 
série » n'importe, dans le cas de multi écran sur un ordinateur, que si 
l'ensemble des écrans de cette machine dispose d'un numéro de série.

Remi, ayant développé cette partie, m'a conseillé de partir sur une nouvelle 
option si je souhaitais modifier le comportement pour que seuls les écrans 
disposant d'un numéro de série ne soient traités.

Voici donc les patchs (pour la version 0.83) pour l'ajout d'une nouvelle option 
que nommée « Import unique numéro de série uniquement » (je pense qu'il 
faudrait peut être revoir les dénominations des deux intitulés pour que cela 
soit plus explicite).

Egalement, voici une proposition de modification du paragraphe décrivant les 
imports de la documentation :

· Import unique sur numéro de série : ne s'applique qu'aux moniteurs. 
N'importe l'écran dans GLPI que si tous les moniteurs ont un numéro de série.

· Import unique numéro de série uniquement : ne s'applique qu'aux 
moniteurs. N'importe dans GLPI que les moniteurs ayant un numéro de série.

Espérant que ça aide.

Cordialement,
--
Thierry BARRAU


en_GB.patch
Description: en_GB.patch


fr_FR.patch
Description: fr_FR.patch


ocsserver.class.patch
Description: ocsserver.class.patch
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] patch pour le nombre de composants d'un ordinateur

[MoYo]

Salut,

patch appliqué en 0.80 et 0.83.

++

Julien

Le 03/01/2012 14:15, David DURIEUX a écrit :

Bonjour,

Voici un patch pour augmenter le nombre d'éléments à afficher. J'ai le
cas de machines de stockage qui ont plus de 100 disques dur et donc ça
restait à '0'.

Le patch est fait sur la branche 0.80


Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] patch pour le nombre de composants d'un ordinateur

[David DURIEUX]

Bonjour,

Voici un patch pour augmenter le nombre d'éléments à afficher. J'ai le
cas de machines de stockage qui ont plus de 100 disques dur et donc ça
restait à '0'.

Le patch est fait sur la branche 0.80


Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE
Index: inc/computer_device.class.php
===
--- inc/computer_device.class.php	(revision 16337)
+++ inc/computer_device.class.php	(working copy)
@@ -239,7 +239,7 @@
 if ($device->getFromDB($data[$fk])) {
echo "";
echo "";
-   Dropdown::showInteger("quantity_".$itemtype."_".$data['id'], $data['NB']);
+   Dropdown::showInteger("quantity_".$itemtype."_".$data['id'], $data['NB'],0,200);
echo "";
if ($device->canCreate()) {
   echo "".$device->getTypeName()."";
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch

[Julien Dombre]

Bonjour,

patch appliqué.

Cordialement,

Julien Dombre


Le 10/12/2011 22:11, David DURIEUX a écrit :

Bonjour,

J'ai fait un patch pour la fonction rundb() et qui prend en compte
les réels ";" de fin de ligne. Sans le patch ça peut foirer sur les
insert de notifications dont les lignes se finissent par :

*>
* 160;


Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[Julien Dombre]

Le 12/12/2011 10:15, David DURIEUX a écrit :

Le voici, donc on n'a plus que l'affichage des catégories liée au
template + lien vers la search page des catégories de ticket.



Patch appliqué.

Julien


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[MAILLARD Xavier]

> >Mais si un jour on veut faire des export CSV, PDF... ca sera plus 
> >compliqué
> >
> On n'a pas moyen d'avoir ça uniquement à l'affichage dans GLPI?

Avec le media Type (http://www.w3.org/TR/CSS2/media.html) CSS pour chaque types 
de media ça devrais être bon...
Ensuite, il faut maintenir les 2 ou séparer les parties communes des parties 
propres à chaque type de média
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[David DURIEUX]

>Mais si un jour on veut faire des export CSV, PDF... ca sera plus
>compliqué
>
On n'a pas moyen d'avoir ça uniquement à l'affichage dans GLPI?

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[MoYo]

Le 12/12/2011 11:01, David DURIEUX a écrit :

Je remarque que tu affiches une image à la place des traditionnelles
valeurs oui/non.

C'est le but que ça soit visible d'un coup, parce que oui/non faut lire
alors que là non ;)


Mais si un jour on veut faire des export CSV, PDF... ca sera plus compliqué

++

Julien


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[David DURIEUX]

Le Mon, 12 Dec 2011 10:53:27 +0100
Remi Collet  a écrit:

>Le 11/12/2011 00:36, David DURIEUX a écrit :
>> Je joins une capture d'écran du résultat.
>
>Je remarque que tu affiches une image à la place des traditionnelles 
>valeurs oui/non.

C'est le but que ça soit visible d'un coup, parce que oui/non faut lire
alors que là non ;)

>
>Cela me semble en effet plus lisible.
>
>Si vous trouvez aussi cela plus lisible, on pourrait l'appliquer à 
>d'autres endroit, notamment sur la liste des membres d'un groupe
>(rôles)
>

Ca me semble une bonne idée, on peut également optimiser l'affichage
dans cette liste.

>
>Pour avis.
>

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[Remi Collet]

Le 11/12/2011 00:36, David DURIEUX a écrit :

Je joins une capture d'écran du résultat.


Je remarque que tu affiches une image à la place des traditionnelles 
valeurs oui/non.


Cela me semble en effet plus lisible.

Si vous trouvez aussi cela plus lisible, on pourrait l'appliquer à 
d'autres endroit, notamment sur la liste des membres d'un groupe (rôles)



Pour avis.

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[David DURIEUX]

Le voici, donc on n'a plus que l'affichage des catégories liée au
template + lien vers la search page des catégories de ticket.

David
++

Le Mon, 12 Dec 2011 09:55:27 +0100 MoYo  a écrit:

>Le 12/12/2011 09:38, David DURIEUX a écrit :
>> Le Mon, 12 Dec 2011 09:19:51 +0100
>> MoYo  a écrit:
>>
>>> Le 11/12/2011 00:36, David DURIEUX a écrit :
 Bonjour,

 Il manque un onglet afin d'assigner un template de ticket à une
 catégorie, ceci à partir du form de templates de ticket. J'ai donc
 codé cet ajout qui permet de gagner du temps de gestion.

 Je joins une capture d'écran du résultat.


>>> Bonjour,
>>>
>>> avoir un état récapitulatif me semble une bonne idée. Faire de
>>> l'association directement à ce niveau me semble dangereux.
>>>
>>> On associe des catégories à un gabarit mais sans aucune information
>>> sur le fait que celles-ci sont déjà associées ou pas à un autre
>>> gabarit.
>>> Ce genre de modifications est réalisable via les modifications
>>> massives du moteur de recherche qui permet d'afficher les
>>> informations existantes, de filtrer sur celles-ci...
>>>
>>> ++
>>>
>>> Julien
>>>
>> Oui en effet pour l'association, par contre il faut mettre un lien
>> vers la search page des catégories de tickets (pour éviter de faire
>> menu>
>> configuration>  intitulé>  catégorie de ticket qui est fastidieux)
>>
>> Tu veux que je modifie le patch du coup ?
>>
>Oui avec plaisir.
>
>++
>
>Julien
>
>
>> David
>> ++
>>
>> ___
>> Glpi-dev mailing list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev
>
>
>___
>Glpi-dev mailing list
>Glpi-dev@gna.org
>https://mail.gna.org/listinfo/glpi-dev
Index: inc/itilcategory.class.php
===
--- inc/itilcategory.class.php	(revision 16416)
+++ inc/itilcategory.class.php	(working copy)
@@ -212,7 +212,93 @@
function cleanDBonPurge() {
   Rule::cleanForItemCriteria($this);
}
+   
+   
+   function getTabNameForItem(CommonGLPI $item, $withtemplate=0) {
+  global $LANG;
 
+  if (Session::haveRight("entity_dropdown","r")) {
+ switch ($item->getType()) {
+case 'TicketTemplate' :
+   $ong[1] = $this->getTypeName();
+   return $ong;
+ }
+  }
+  return '';
+   }
+   
+   
+   static function displayTabContentForItem(CommonGLPI $item, $tabnum=1, $withtemplate=0) {
+
+  self::showForTicketTemplate($item, $withtemplate);
+  return true;
+   }
+   
+   
+   static function showForTicketTemplate(TicketTemplate $tt, $withtemplate='') {
+  global $DB, $LANG, $CFG_GLPI;
+  
+  $itilcategory = new self();
+  $ID = $tt->fields['id'];
+
+  if (!$tt->getFromDB($ID) || !$tt->can($ID, "r")) {
+ return false;
+  }
+  $ttm = new self();
+
+  $rand= mt_rand();
+
+  echo "";
+
+  $query = "SELECT `glpi_itilcategories`.*
+FROM `glpi_itilcategories`
+WHERE (`tickettemplates_id_incident` = '$ID')
+ OR (`tickettemplates_id_demand` = '$ID')
+ORDER BY `name`";
+
+  if ($result=$DB->query($query)) {
+ echo "";
+ echo "";
+ echo "";
+ echo self::getTypeName($DB->numrows($result));
+ echo "";
+ echo "";
+ $used_incident = array();
+ $used_demand = array();
+ if ($DB->numrows($result)) {
+echo "".$LANG['common'][16]."";
+echo "".$LANG['job'][1]."";
+echo "".$LANG['job'][2]."";
+echo "";
+
+while ($data=$DB->fetch_assoc($result)) {
+   echo "";
+   $itilcategory->getFromDB($data['id']);
+   echo "".$itilcategory->getLink(1)."";
+   if ($data['tickettemplates_id_incident'] == $ID) {
+  echo "
+ ";
+  $used_incident[] = $data["id"];
+   } else {
+  echo " ";
+   }
+   if ($data['tickettemplates_id_demand'] == $ID) {
+  echo "
+ ";
+  $used_demand[] = $data["id"];
+   } else {
+  echo " ";
+   }
+}
+
+ } else {
+echo "".$LANG['search'][15]."";
+ }
+
+ echo "";
+  }
+   }
+
 }
 
 ?>
Index: inc/tickettemplate.class.php
===
--- inc/tickettemplate.class.php	(revision 16416)
+++ inc/tickettemplate.class.php	(working copy)
@@ -229,6 +229,7 @@
   $this->addStandardTab('TicketTemplatePredefinedField', $ong, $options);
   $this->addStandardTab('TicketTemplateHiddenField', $ong, $options);
   $this->addStandardTab('TicketTemplate', $ong, $options);
+  $this->addStandardTab('ITILCategory', $ong, $options);
   $this->ad

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[MoYo]

Le 12/12/2011 09:38, David DURIEUX a écrit :

Le Mon, 12 Dec 2011 09:19:51 +0100
MoYo  a écrit:


Le 11/12/2011 00:36, David DURIEUX a écrit :

Bonjour,

Il manque un onglet afin d'assigner un template de ticket à une
catégorie, ceci à partir du form de templates de ticket. J'ai donc
codé cet ajout qui permet de gagner du temps de gestion.

Je joins une capture d'écran du résultat.



Bonjour,

avoir un état récapitulatif me semble une bonne idée. Faire de
l'association directement à ce niveau me semble dangereux.

On associe des catégories à un gabarit mais sans aucune information
sur le fait que celles-ci sont déjà associées ou pas à un autre
gabarit.
Ce genre de modifications est réalisable via les modifications
massives du moteur de recherche qui permet d'afficher les informations
existantes, de filtrer sur celles-ci...

++

Julien


Oui en effet pour l'association, par contre il faut mettre un lien vers
la search page des catégories de tickets (pour éviter de faire menu>
configuration>  intitulé>  catégorie de ticket qui est fastidieux)

Tu veux que je modifie le patch du coup ?


Oui avec plaisir.

++

Julien



David
++

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev



___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[David DURIEUX]

Le Mon, 12 Dec 2011 09:19:51 +0100
MoYo  a écrit:

>Le 11/12/2011 00:36, David DURIEUX a écrit :
>> Bonjour,
>>
>> Il manque un onglet afin d'assigner un template de ticket à une
>> catégorie, ceci à partir du form de templates de ticket. J'ai donc
>> codé cet ajout qui permet de gagner du temps de gestion.
>>
>> Je joins une capture d'écran du résultat.
>>
>>
>Bonjour,
>
>avoir un état récapitulatif me semble une bonne idée. Faire de 
>l'association directement à ce niveau me semble dangereux.
>
>On associe des catégories à un gabarit mais sans aucune information
>sur le fait que celles-ci sont déjà associées ou pas à un autre
>gabarit.
>Ce genre de modifications est réalisable via les modifications
>massives du moteur de recherche qui permet d'afficher les informations 
>existantes, de filtrer sur celles-ci...
>
>++
>
>Julien
>

Oui en effet pour l'association, par contre il faut mettre un lien vers
la search page des catégories de tickets (pour éviter de faire menu >
configuration > intitulé > catégorie de ticket qui est fastidieux)

Tu veux que je modifie le patch du coup ?

David
++

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[MoYo]

Le 11/12/2011 00:36, David DURIEUX a écrit :

Bonjour,

Il manque un onglet afin d'assigner un template de ticket à une
catégorie, ceci à partir du form de templates de ticket. J'ai donc codé
cet ajout qui permet de gagner du temps de gestion.

Je joins une capture d'écran du résultat.



Bonjour,

avoir un état récapitulatif me semble une bonne idée. Faire de 
l'association directement à ce niveau me semble dangereux.


On associe des catégories à un gabarit mais sans aucune information sur 
le fait que celles-ci sont déjà associées ou pas à un autre

gabarit.
Ce genre de modifications est réalisable via les modifications massives 
du moteur de recherche qui permet d'afficher les informations 
existantes, de filtrer sur celles-ci...


++

Julien





Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch : ajout d'un onglet categorie dans le form des templates de tickets

[David DURIEUX]

Bonjour,

Il manque un onglet afin d'assigner un template de ticket à une
catégorie, ceci à partir du form de templates de ticket. J'ai donc codé
cet ajout qui permet de gagner du temps de gestion.

Je joins une capture d'écran du résultat.


Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE
Index: front/itilcategory.form.php
===
--- front/itilcategory.form.php	(revision 16403)
+++ front/itilcategory.form.php	(working copy)
@@ -37,5 +37,22 @@
 include (GLPI_ROOT . "/inc/includes.php");
 
 $dropdown = new ITILCategory();
+
+if (isset($_POST['add_demand'])) {
+   $dropdown->check($_POST['itilcategories_id_demand'], 'w');
+   $input = array();
+   $input['id'] = $_POST['itilcategories_id_demand'];
+   $input['tickettemplates_id_demand'] = $_POST['tickettemplates_id'];
+   $dropdown->update($input);
+   Html::back();
+} else if (isset($_POST['add_incident'])) {
+   $dropdown->check($_POST['itilcategories_id_incident'], 'w');
+   $input = array();
+   $input['id'] = $_POST['itilcategories_id_incident'];
+   $input['tickettemplates_id_incident'] = $_POST['tickettemplates_id'];
+   $dropdown->update($input);
+   Html::back();
+}
+
 include (GLPI_ROOT . "/front/dropdown.common.form.php");
 ?>
Index: inc/itilcategory.class.php
===
--- inc/itilcategory.class.php	(revision 16403)
+++ inc/itilcategory.class.php	(working copy)
@@ -212,7 +212,123 @@
function cleanDBonPurge() {
   Rule::cleanForItemCriteria($this);
}
+   
+   
+   function getTabNameForItem(CommonGLPI $item, $withtemplate=0) {
+  global $LANG;
 
+  if (Session::haveRight("entity_dropdown","r")) {
+ switch ($item->getType()) {
+case 'TicketTemplate' :
+   $ong[1] = $this->getTypeName();
+   return $ong;
+ }
+  }
+  return '';
+   }
+   
+   
+   static function displayTabContentForItem(CommonGLPI $item, $tabnum=1, $withtemplate=0) {
+
+  self::showForTicketTemplate($item, $withtemplate);
+  return true;
+   }
+   
+   
+   static function showForTicketTemplate(TicketTemplate $tt, $withtemplate='') {
+  global $DB, $LANG, $CFG_GLPI;
+  
+  $itilcategory = new self();
+  $ID = $tt->fields['id'];
+
+  if (!$tt->getFromDB($ID) || !$tt->can($ID, "r")) {
+ return false;
+  }
+  $ttm = new self();
+
+  $canedit = $tt->can($ID, "w");
+  $rand= mt_rand();
+  echo "";
+
+  echo "";
+
+  $query = "SELECT `glpi_itilcategories`.*
+FROM `glpi_itilcategories`
+WHERE (`tickettemplates_id_incident` = '$ID')
+ OR (`tickettemplates_id_demand` = '$ID')
+ORDER BY `name`";
+
+  if ($result=$DB->query($query)) {
+ echo "";
+ echo "";
+ echo self::getTypeName($DB->numrows($result));
+ echo "";
+ $used_incident = array();
+ $used_demand = array();
+ if ($DB->numrows($result)) {
+echo " ";
+echo "".$LANG['common'][16]."";
+echo "".$LANG['job'][1]."";
+echo "".$LANG['job'][2]."";
+echo "";
+
+while ($data=$DB->fetch_assoc($result)) {
+   echo "";
+   if ($canedit) {
+  echo "";
+   } else {
+  echo " ";
+   }
+   $itilcategory->getFromDB($data['id']);
+   echo "".$itilcategory->getLink(1)."";
+   if ($data['tickettemplates_id_incident'] == $ID) {
+  echo "
+ ";
+  $used_incident[] = $data["id"];
+   } else {
+  echo " ";
+   }
+   if ($data['tickettemplates_id_demand'] == $ID) {
+  echo "
+ ";
+  $used_demand[] = $data["id"];
+   } else {
+  echo " ";
+   }
+}
+
+ } else {
+echo "".$LANG['search'][15]."";
+ }
+
+ if ($canedit) {
+echo "";
+echo "";
+echo "";
+dropdown::show("ITILCategory", array('name' => 'itilcategories_id_incident',
+ 'used' => $used_incident));
+echo " ";
+echo "";
+dropdown::show("ITILCategory", array('name' => 'itilcategories_id_demand',
+ 'used' => $used_demand));
+echo " ";
+echo "";
+ }
+ echo "";
+
+// if ($canedit) {
+//Html::openArrowMassives("itilcategories_form$rand", true);
+//Html::closeArrowMassives(array('delete' => $LANG['buttons'][6]));
+// }
+ 

[Glpi-dev] Patch

[David DURIEUX]

Bonjour,

J'ai fait un patch pour la fonction rundb() et qui prend en compte
les réels ";" de fin de ligne. Sans le patch ça peut foirer sur les
insert de notifications dont les lignes se finissent par : 

* >
* 160;


Cordialement,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE
Index: inc/dbmysql.class.php
===
--- inc/dbmysql.class.php	(revision 16403)
+++ inc/dbmysql.class.php	(working copy)
@@ -482,7 +482,9 @@
 
  // do not strip comments due to problems when # in begin of a data line
  $formattedQuery .= $buffer;
- if (substr(rtrim($formattedQuery),-1) == ";") {
+ if (substr(rtrim($formattedQuery),-1) == ";"
+ AND substr(rtrim($formattedQuery),-4) != ">"
+ AND substr(rtrim($formattedQuery),-4) != "160;") {
 
 if (Toolbox::get_magic_quotes_runtime()) {
$formattedQuerytorun = stripslashes($formattedQuery);
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] patch d'évolution du NetworkPort

[Damien Touraine]

Bonjour,

On 05/12/2011 15:50, David DURIEUX wrote:

j'ai commencé à regardé ce que tu as mis sur le SVN pour la 0.84

J'ai quelques remarques :

  * On devrait séparer les noms reseau des IP; en effet, un port peut
   avoir plusieurs IP et pas de nom reseau. par exemple pour un port
   d'ordinateur ou pour l'IP/les IP d'un switch
En effet, il n'y a pas de bijection entre les noms réseaux et les 
adresses IP. Un nom réseau peut être affecté à plusieurs adresses IP 
(cas du load balancing), et une adresse IP peut avoir plusieurs noms 
réseau différents (alias dans les DNS).
Mais, en règle générale et traditionnellement, on associe un nom 
principal à une adresse IP donnée. D'une part, c'est beaucoup plus 
pratique que de saisir l'adresse (surtout en IPv6 ...). D'autre part, 
certaines applications (ssh, ...) utilisent la résolution inverse des 
adresses IP pour s'assurer de la conformité de la demande de connexion. 
C'est, également, utilisé pour les "logs" de connexion.
Pour le moment, il FAUT saisir un nom réseau non vide. Sinon, le 
NetworkName n'est pas ajouté/modifié. Ce comportement peut, 
effectivement, poser problème. Dès que la bascule 0.84->trunk aura eu 
lieu, je le supprimerai.

  * Il faudrait un champs unique pour chaque IP et pas une textarea,
ceci permettra de fair eune recherche plus rapide dans la DB et ça
sera plus clair dans l'interface (une ligne par IP par exemple pour
l'affichage)
Dans le cadre de l'IPv6, un même nom doit être résolu en IPv4, en IPv6 
link-local et en IPv6 link-global. C'est la même connexion (le même 
nom), mais vue selon des versions d'IP différentes et de lieux 
différents. Cela va avoir tendance à se généraliser avec l'émergeance 
d'IPv6.
C'est pour cela que l'adresse IP, dans le NetworkName, est un textarea 
permettant la saisie de plusieurs adresses.
Mais, lors de la validation, le NetworkName sépare et valide chacune des 
adresses séparément. Les nouvelles adresses sont ajoutées dans la base 
de données glpi_ipaddresses (et les anciennes supprimées). Lors des 
requêtes pour trouver une adresse, c'est cette dernière qui est 
interrogée. Le champs `ip_addresses` de glpi_networknames n'est là 
qu'entant que cache des adresses. Il sert, notamment, lors de 
l'affichage des adresses du nom réseau par Search::show.


Cordialement
Damien

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] patch d'évolution du NetworkPort

[David DURIEUX]

j'ai commencé à regardé ce que tu as mis sur le SVN pour la 0.84

J'ai quelques remarques : 

 * On devrait séparer les noms reseau des IP; en effet, un port peut
  avoir plusieurs IP et pas de nom reseau. par exemple pour un port
  d'ordinateur ou pour l'IP/les IP d'un switch 

 * Il faudrait un champs unique pour chaque IP et pas une textarea,
   ceci permettra de fair eune recherche plus rapide dans la DB et ça
   sera plus clair dans l'interface (une ligne par IP par exemple pour
   l'affichage)


David Durieux
++


Le Thu, 15 Sep 2011 08:36:49 +0200
Damien Touraine  a écrit:

>Bonjour,
>
>Ce boulot est largement facilité par la programmation orientée objet
>et les bases de GLPI qui me semblent très saines. Mais il ne faut pas
>se fier à la taille des patchs : il y a du ménage à faire dedans
>(ie. : mélange de deux conceptions des NetworkPort différentes).
>
>Le report à la version 0.84 me semble d'autant plus justifié que le 
>chantier de la 0.83 est déjà bien avancé. De plus, l'intégration de
>cela sera l'occasion de réfléchir à son articulation avec, notamment,
>le système d'import OCS. Deux choix me semblent possibles :
>1°) solution actuelle : une adresse IP <=> un port réseau (et une 
>adresses IP <=> un équippement réseau) ;
>2°) solution plus proche de la réalité : une carte réseau <= > un port 
>réseau sur lequel peut être attaché plusieurs adresses IP.
>
>Le parrainage est nécessaire. En effet, je ne connais pas assez GLPI 
>(notamment les us et coutumes) pour être laissé libre dans la 
>publication directe dans le SVN.
>
>Cordialement
> Damien
>On 09/14/11 23:46, jmd wrote:
>> Bonsoir,
>>
>> Une remarque préalable : un boulot impressionnant !
>>
>> Ensuite, une remarque globale par rapport à l'ampleur du chantier, 
>> nous sommes tentés de vous proposer le plan suivant :
>>
>> - Report de l'implémentation sur la version 0.84 de façon à
>> travailler de façon plus sereine. La cible initiale (0.83) nous
>> semble difficilement tenable.
>>
>> - Découpage du chantier en différents tickets (étapes)
>>
>> - Ouverture d'un accés sur le SVN et attribution d'un parrain qui 
>> vérifiera les comits. Le travail par le biais de patchs nous
>> semblent difficile et peu efficace vu l'impact des modifications
>> envisagées.
>>
>>
>> Bien cordialement,
>>
>>
>> -- 
>> Jean-Mathieu Doléans
>> GLPI-PROJECT.ORG
>>
>> ___
>> Glpi-dev mailing list
>> Glpi-dev@gna.org
>> https://mail.gna.org/listinfo/glpi-dev
>>
>
>

___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

Re: [Glpi-dev] Patch for Virtualmachines

[Remi Collet]

Le 26/09/2011 16:57, David DURIEUX a écrit :
> Hello,
> 
> This is a patch for VirtualMachine.
> 
> There is a problem on Host computer want search a VM with the OID. But
> in SQL request, it search with Computer id != virtualmachine id. So if
> computer have same id than the virtualmachine, it will never find it.
> 
> With some investigation, this id may not be used here 

Thanks, applied.

> 
> 
> Best regards,
> --
> David DURIEUX
> Tel : +33 (0)4.82.53.30.53
> Port : +33 (0)6.34.99.45.18
> Mail : d.duri...@siprossii.com
> Site Web : http://www.siprossii.com/
> 
> SIPROSSII
> Les Lafôrets
> 69430 Beaujeu
> FRANCE
> 
> 
> 
> ___
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev


___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev

[Glpi-dev] Patch for Virtualmachines

[David DURIEUX]

Hello,

This is a patch for VirtualMachine.

There is a problem on Host computer want search a VM with the OID. But
in SQL request, it search with Computer id != virtualmachine id. So if
computer have same id than the virtualmachine, it will never find it.

With some investigation, this id may not be used here 


Best regards,
--
David DURIEUX
Tel : +33 (0)4.82.53.30.53
Port : +33 (0)6.34.99.45.18
Mail : d.duri...@siprossii.com
Site Web : http://www.siprossii.com/

SIPROSSII
Les Lafôrets
69430 Beaujeu
FRANCE
Index: computervirtualmachine.class.php
===
--- computervirtualmachine.class.php	(revision 15527)
+++ computervirtualmachine.class.php	(working copy)
@@ -425,8 +425,7 @@
 
   $query = "SELECT `id`
 FROM `glpi_computers`
-WHERE `id` NOT IN ('".$fields['id']."')
-  AND LOWER(`uuid`) ".self::getUUIDRestrictRequest($fields['uuid']);
+WHERE LOWER(`uuid`) ".self::getUUIDRestrictRequest($fields['uuid']);
   $result = $DB->query($query);
 
   //Virtual machine found, return ID
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev