Rémontée d'informations administratives à partir d'OCS

Le but de ce chantier est de remonter les informations administratives comme par exemple :
  • Numéro d'inventaire
  • Lieu
  • Réseau
  • Contact numéro
  • Groupe

Le but de ce chantier est de permettre à l'administrateur GLPI de remplir ces champs à partir des informations disponibles dans la base OCS.

Dans OCS, par défaut, seul le champ Tag est disponible, d'autres champs peuvent être ajoutés manuellement. La liste des champs sur les informations administratives dans OCS est donc une liste dynamique.

Dans la partie Configuration du module d'import, il est donc nécessaire de créer une ligne par champs GLPI avec une combo box où l'administrateur GLPI peut choisir parmi tous les champs sur les informations administratives disponibles dans OCS. Cette combo box sera rempli de manière dynamique avec la liste des champs récupérés dans la table 'accountinfo'.

Problème 1 : Que se passe-t-il si un pointeur d'un champ ocs -> champ glpi a été créé et que le champ ocs est supprimé ? Le pointeur est supprimé ? Le champ est simplement laissé à vide, mais les synchronisations suivantes continuent à lire le champ ?

Moyo : pointeur supprimé et plus d'importation : avantage simple a gérer.

Probléme 2 : Comment gérer le fait qu'un champ soit importé par un module mais aussi par le module informations administratives ? Soit on le permet, et on gère la merde (dixit MoYoo) soit on le permet pas. MoYoo est pour la seconde solution et moi aussi.

Stockage dans la base

Il faut stocker la relation champ OCS -> champ GLPI

Deux choix sont possibles :
  • on créé un table avec la structure suivante : serveur_ocs_id, champ_glpi, champ_ocs
  • pour chaque champ de glpi, on créé un champ dans 'glpi_ocs_config'. La valeur de ce champ contiendra le champ OCS.

Je suis pour essayer avec la première solution.

Moyo : Vendu pour le champ_GLPI il est possible de coder cela avec un entier refererencant l'entrée de SEARCH_OPTION (search.constant.php)