Re: [Glpi-dev] GLPI 0.84dev : autoload avec des dossiers dans inc/

2011-12-05 Thread jmd
Bonsoir,

Le 05/12/2011 18:42, David DURIEUX a écrit :
(...)
> en commençant a travailler sur le plugin FusionInventory pour la 0.84
> (on merge les différents plugin en 1 seul), on s'est rendu compte qu'on
> risque d'avoir un très grand nombre de classes dans le dossier inc.
(...)
> Donc on pourrait avoir la structure suivante : 
> 
> inc/computer.class.php (class Computer)
> inc/computer/disk.class.php (class ComputerDisk)
()
> Qu'en pensez-vous?

Je ne vois pas bien l'intérêt. A part se balader de dossier en dossier
pour trouver la bonne classe, qu'est ce que ça apporte en terme de
développement ?

Pour mémoire, nous avions cette structure dans les premières versions de
GLPI et c'était pénible au possible...

@+

JMD

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


[Glpi-dev] Re : GLPI 0.84dev : autoload avec des dossiers dans inc/

2011-12-05 Thread MoYo
Salut,

Perso, je ne vois pas l'intérêt à part complexifier encore le truc...
On a deja énormément de classes dans inc et ca ne gène en rien.

Julien



- Reply message -
De : "David DURIEUX" 
Pour : "glpi-dev@gna.org" 
Objet : [Glpi-dev] GLPI 0.84dev : autoload avec des dossiers dans inc/
Date : lun., déc. 5, 2011 18:42


Bonjour,

en commençant a travailler sur le plugin FusionInventory pour la 0.84
(on merge les différents plugin en 1 seul), on s'est rendu compte qu'on
risque d'avoir un très grand nombre de classes dans le dossier inc.

On en a discuté et on s'est dit que ca serait pratique et il me semble
que c'était prévu un peu plus tard, mais quitte à tout péter maintenant
pour la 0.84, on peut le faire de suite.


Donc on pourrait avoir la structure suivante : 

inc/computer.class.php (class Computer)
inc/computer/disk.class.php (class ComputerDisk)
...


Je joins un premier patch qui permet de charger les fichiers dans le
bon dossier (fonction __autoload).


Qu'en pensez-vous?

Je peux bosser sur ce chantier cette semaine si on se met d'accord
(création des dossier, déplacement et renommage des fichiers de
classes...)

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


[Glpi-dev] GLPI 0.84dev : autoload avec des dossiers dans inc/

2011-12-05 Thread David DURIEUX
Bonjour,

en commençant a travailler sur le plugin FusionInventory pour la 0.84
(on merge les différents plugin en 1 seul), on s'est rendu compte qu'on
risque d'avoir un très grand nombre de classes dans le dossier inc.

On en a discuté et on s'est dit que ca serait pratique et il me semble
que c'était prévu un peu plus tard, mais quitte à tout péter maintenant
pour la 0.84, on peut le faire de suite.


Donc on pourrait avoir la structure suivante : 

inc/computer.class.php (class Computer)
inc/computer/disk.class.php (class ComputerDisk)
...


Je joins un premier patch qui permet de charger les fichiers dans le
bon dossier (fonction __autoload).


Qu'en pensez-vous?

Je peux bosser sur ce chantier cette semaine si on se met d'accord
(création des dossier, déplacement et renommage des fichiers de
classes...)

David Durieux 
++
Index: inc/autoload.function.php
===
--- inc/autoload.function.php	(revision 16265)
+++ inc/autoload.function.php	(working copy)
@@ -112,10 +112,17 @@
}
 
$dir = GLPI_ROOT . "/inc/";
+   $dirinc = array();
+   $filename = '';
+   preg_match_all('/([A-Z])([a-z]+([_][A-Z]([a-z]+))?)/', $classname, $dirinc);
if ($plug=isPluginItemType($classname)) {
   $plugname = strtolower($plug['plugin']);
   $dir  = GLPI_ROOT . "/plugins/$plugname/inc/";
   $item = strtolower($plug['class']);
+  if(isset($dirinc[0][0])
+  AND $dirinc[0][0] == 'Plugin') {
+ unset($dirinc[0][0]);
+  }
   // Is the plugin activate ?
   // Command line usage of GLPI : need to do a real check plugin activation
   if (isCommandLine()) {
@@ -153,8 +160,8 @@
 
// No errors for missing classes due to implementation
if (!in_array($item,$CFG_GLPI['missingclasses'])){
-  if (file_exists("$dir$item.class.php")) {
- include_once ("$dir$item.class.php");
+  if (file_exists("$dir".strtolower(implode("/", $dirinc[0])).".class.php")) {
+ include_once ("$dir".strtolower(implode("/", $dirinc[0])).".class.php");
  if (isset($_SESSION['glpi_use_mode'])
  && $_SESSION['glpi_use_mode'] == Session::DEBUG_MODE) {
 $DEBUG_AUTOLOAD[] = $classname;
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


[Glpi-dev] Ajout colone statut dans différent listing

2011-12-05 Thread Thierry Barrau
Bonjour,

Pour différents besoins, nous avons modifié le code GLPI afin que le champs 
"statut" des équipements apparaissent dans la liste des équipements des 
contrats (permet par exemple d'un visuel sur un contrat de distinguer le 
matériel déjà rendu à celui restant à rendre...), ainsi que dans la liste des 
équipements des utilisateurs (vu qu'on utilise pas encore item_uninstall, cela 
permet de distingué le matériel actuellement utilisé).

Voici les modifications apportées sur les fichiers en version 0.80.5:
Listing équipements par contrats : ".\inc\contract.class.php "
Modification 1 :
Remplacer :
 echo "".$LANG['common'][20]."";
Par:
 echo "".$LANG['common'][20]."";
 echo "".$LANG['state'][0]."";

Modification 2 :
Après:
 echo "".
  (isset($data["otherserial"])? "".$data["otherserial"]."" :"-")."";
 echo "";
Ajouter:
 echo "";
 if (isset($data["states_id"]) && !empty($data["states_id"])) {
  echo Dropdown::getDropdownName("glpi_states",$data['states_id']);
 } else {
 echo '-';
 }

Listing équipements par utilisateurs: ".\inc\user.class.php"
Modification 1 :
Après :
 echo "".$LANG['common'][20]."";
Ajouter:
 echo "".$LANG['state'][0]."";
Modification 2 :
Après:
 echo "";
 if (isset($data["otherserial"]) && !empty($data["otherserial"])) {
echo $data["otherserial"];
 } else {
echo '  ';
 }
Ajouter:
 echo "";
 if (isset($data["states_id"]) && !empty($data["states_id"])) {
  echo Dropdown::getDropdownName("glpi_states",$data['states_id']);
 } else {
  echo '-';
 }

Est-il possible de rajouter ces modifcations dans le code direct de GLPI ?

Merci d'avance.

Cordialement,
--
Thierry BARRAU (berserker)
___
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev


Re: [Glpi-dev] CommonDBChild et date_mod

2011-12-05 Thread MoYo

Le 05/12/2011 14:52, Remi Collet a écrit :

Salut,

Est-ce que la mise à jour du date_mod d'un objet (Commputer, Ticket,
...) ne devrait pas être géré par les CommonDBChild, lors d'un ajout ou
d'une purge ?


Salut,

ca me semble logique effectivement.
Quitte à mettre une option pour désactiver le comportement si besoin 
(variable auto_update_father_date_mod par exemple).



Même question pour les CommonDBRelation (ça peut paraitre mon évident).
Effectivement moins évident car suivant les cas on veux mettre à jour 
d'un côté mais pas de l'autre ou les deux.
Des options via variables dans les classes du genre : 
auto_update_date_mod_for_itemtype[1|2] ca peut le faire (par défaut à 
false).


++

Julien



A discuter,
Remi.

___
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 d'évolution du NetworkPort

2011-12-05 Thread 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


[Glpi-dev] CommonDBChild et date_mod

2011-12-05 Thread Remi Collet
Salut,

Est-ce que la mise à jour du date_mod d'un objet (Commputer, Ticket,
...) ne devrait pas être géré par les CommonDBChild, lors d'un ajout ou
d'une purge ?

Même question pour les CommonDBRelation (ça peut paraitre mon évident).

A discuter,
Remi.

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


Re: [Glpi-dev] function set_magic_quotes_runtime deprecated

2011-12-05 Thread David DURIEUX
le ini_set peut etre utilsié à la place quand même, non? 

David
++

Le Mon, 05 Dec 2011 11:20:38 +0100
Remi Collet  a écrit:

>Le 02/12/2011 20:20, David DURIEUX a écrit :
>> Hello
>> 
>> In front/link.send.php file, we use deprecated function since PHP
>> 5.3.0 : "@set_magic_quotes_runtime(0);" and
>> "@set_magic_quotes_runtime($mc);"
>
>Cette fonction est dépréciée en php 5.3.0 et supprimée en 5.4.0
>Le code est uniquement appellé lorsque la config est moisie (le get
>renvoie une valeur != 0)
>
>Donc le "deprecated" est pertinent
>
>Après, on pourrait renforcer la check lors de l'installation.
>
>++
>
>> 
>> We can modify it by "ini_set('magic_quotes_runtime', 0);" and
>> "ini_set('magic_quotes_runtime', $mc);"
>> 
>> 
>> Best regards
>> David Durieux
>> ++
>> 
>> ___
>> 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] Nouveau paramètre CommonTreeDropdown

2011-12-05 Thread Remi Collet
Le 02/11/2011 12:03, Tsmr a écrit :

> Une option serait intéressante et vraiment pas trés compliqué à coder
> serait d'interdire la sélection d'un enregistrement père dans un
> dropdown arborescent.

Pour info, cela existe déjà pour les groupes et les catégories

Groupe : si tu met tous les attributs à "non", il pourra contenir
d'autres groupes, mais ne sera jamais proposé dans les choix ailleurs.

Catégories : idem, si tu désactives les attributs (Indident, Demande et
Problème) tu obtient exactement ce que tu as décrit.

Cette astuce pourrait être ajoutée dans la doc..


On pourrait faire le même genre de chose pour les lieux (matériels,
utilisateurs, ...)


+


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


Re: [Glpi-dev] function set_magic_quotes_runtime deprecated

2011-12-05 Thread Remi Collet
Le 02/12/2011 20:20, David DURIEUX a écrit :
> Hello
> 
> In front/link.send.php file, we use deprecated function since PHP
> 5.3.0 : "@set_magic_quotes_runtime(0);" and "@set_magic_quotes_runtime($mc);"

Cette fonction est dépréciée en php 5.3.0 et supprimée en 5.4.0
Le code est uniquement appellé lorsque la config est moisie (le get
renvoie une valeur != 0)

Donc le "deprecated" est pertinent

Après, on pourrait renforcer la check lors de l'installation.

++

> 
> We can modify it by "ini_set('magic_quotes_runtime', 0);" and
> "ini_set('magic_quotes_runtime', $mc);"
> 
> 
> Best regards
> David Durieux
> ++
> 
> ___
> 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