ComputerBuilderMapping

[f2cmb]

Création d’une nouvelle classe ComputerBuilderMapping

Étapes de développement

1. Adaptation de la classe SyncFilter

• Ajouter deux nouveaux champs à SyncFilter :

  • builder_itemtype
  • builder_items_id

• Lors de la création d’un SyncFilter :

  • Renseigner le bon builder en fonction de l’itemtype synchronisé.
  • Créer une ligne dans la table glpi_plugin_advancedldap_computerbuildermappings pour permettre la saisie du items_id (avec les colonnes par défaut voir section Table SQL).

2. Gestion du nouvel onglet Mapping

La classe ComputerBuilderMapping sera responsable de la création d’un nouvel onglet Mapping sur les SyncFilter concernés.

2.1. Section « Nom de l’actif synchronisé » (Device)

• Permettre à l’utilisateur de sélectionner le champ LDAP correspondant au nom de l’actif.
• Générer automatiquement le JSON suivant :

{
    "action": "inventory",
    "content": {
        "versionclient": "AdvanceLdap_versionplugin"
    },
    "deviceid": "{{ ldap.sAMAccountName }}",
    "itemtype": "{{ SyncFilter.itemtype }}",
    "partial": true,
    "tag": "value"
}

Remarques :

• itemtype dépend du champ itemtype du SyncFilter.
• deviceid dépend du champ LDAP sélectionné par l’utilisateur.

2.2. Section « Hardware »

• Afficher un éditeur JSON (Monaco) pour permettre l’édition des informations hardware.
• Exemple de JSON minimal :

{
    "chassis_type": "Notebook",
    "defaultgateway": "192.168.10.254",
    "dns": "127.0.0.53",
    "memory": 31394,
    "name": "stanislas-Inspiron-16-5645",
    "swap": 4095,
    "uuid": "4c4c4544-0057-3410-8052-c8c04f4e3734",
    "vmsystem": "Physical",
    "workgroup": "box.freepro.com"
}

• L’éditeur devra proposer :

  • Une liste de tags représentant les champs LDAP disponibles (natif et éventuellement personnalisés si possible).
  • La possibilité de saisie libre si certains champs ne sont pas détectés dans l’annuaire.

• Chaque champ doit être accompagné d’une brève description ou d’une alerte expliquant son utilité.
  Exemples :

  • chassis_type → Type de l’actif (ordinateur, serveur…)
  • workgroup → Domaine de l’ordinateur

• Génération finale du JSON minimal pour GLPI :

{
    "action": "inventory",
    "content": {
        "versionclient": "AdvanceLdap_version_plugin",
        "hardware": {
            "chassis_type": "Notebook",
            "defaultgateway": "192.168.10.254",
            "dns": "127.0.0.53",
            "memory": 31394,
            "name": "stanislas-Inspiron-16-5645",
            "swap": 4095,
            "uuid": "4c4c4544-0057-3410-8052-c8c04f4e3734",
            "vmsystem": "Physical",
            "workgroup": "box.freepro.com"
        }
    },
    "deviceid": "deviceid",
    "itemtype": "Computer",
    "partial": true
}

2.4. Table SQL

$query = "CREATE TABLE `{$table}` (
                `id` int {$default_key_sign} NOT NULL AUTO_INCREMENT,
                `deviceid` varchar(255) NOT NULL DEFAULT '',
                `hardware` text,
                `operatingsystem` text,
                `bios` text,
                `date_creation` timestamp NULL DEFAULT NULL,
                `date_mod` timestamp NULL DEFAULT NULL,
                PRIMARY KEY (`id`),
                KEY `date_creation` (`date_creation`),
                KEY `date_mod` (`date_mod`)
            ) ENGINE=InnoDB DEFAULT CHARSET={$default_charset} COLLATE={$default_collation} ROW_FORMAT=DYNAMIC";

• Les colonnes destinées à contenir du JSON doivent être automatiquement pré-remplies avec un JSON par défaut.
• Ce JSON servira de structure minimale pour l’intégration dans GLPI et pourra ensuite être modifié par l’utilisateur via l’éditeur JSON de l’onglet Mapping.

Stockage des JSON pour le plugin ComputerBuilderMapping

• Les fichiers JSON correspondant aux différentes sections doivent être stockés dans le plugin afin de permettre la restauration (reset) depuis l’interface utilisateur.
• Chemins recommandés pour le stockage :

/builder/computer/data/main.json       → JSON principal (device)
/builder/computer/data/hardware.json   → Section hardware
/builder/computer/data/bios.json       → Section BIOS

Lorsqu’un utilisateur clique sur le bouton Reset dans l’onglet Mapping, le contenu de la section correspondante doit être réinitialisé à partir de ces fichiers JSON.

3. Fonctionnalités additionnelles de l’onglet Mapping

• Bouton Sauvegarder pour enregistrer les modifications.
• Bouton Reset pour restaurer le JSON par défaut (pour chaque section : Hardware, etc.).
• Documentation contextuelle (alertes) pour chaque champ, basée sur l’inventaire natif de GLPI et l’usage de ces champs dans l’application.