GenericObject

Réflexions autour de l'implémentation d'objets génériques d'inventaire dans GLPI.

L'existant : le plugin Generic Object

Analyse et commentaires
(qualités, défauts, limites, roadmap... )

Hypothèse 1 : Faire évoluer le plugin et en faciliter l'évolution par des adaptations du coeur

Principe : adapter le plugin à de nouveaux besoins non spécifiques à l'informatique (exemple : intégrer la gestion de bâtiments ou de véhicules, importer des données liées aux consommations de fluides : EDF, chauffage/clim...)

Avantages : Evolution "indépendamment" du coeur de GLPI donc potentiellement plus rapide, plus facile (?)

Inconvénients : Comment s'assurer de la pérennité du plugin avec l'évolution de GLPI ? (aspect développeur plus que "contributeur-financier")

Hypothèse 2 : Modifier et adapter le coeur pour qu'il offre nativement les fonctionnalités de Generic object de façon ISO fonctionnelle.

Principe : Implémenter les fonctionnalités du plugin dans le coeur.

Avantages : Homogénéisation de l'accès aux différents éléments de l'inventaire (à travers le menu inventaire au lieu de Plugin->GenericObject->...)
Meilleur suivi de ces fonctionnalités dans le temps / moins de risque d'abandon de ces fonctionnalités

Inconvénients : Délais avant l'intégration de ces fonctionnalités dans le coeur de GLPI. Comment assurer l'implémentation de fonctionnalités supplémentaires (cf principes hypothèse 1)

Hypothèse 3 : Redéfinir un périmètre fonctionnel de zero et modifier et adapter le coeur en conséquence

Principe : Sur la base d'un cahier des charges définir les fonctionnalités attendues et les implémenter dans le coeur.

Avantages : Optimisation/adéquation du coeur avec de nouvelles fonctionnalités au-delà de ce que propose actuellement le plugin.

Inconvénients : Lourdeur du redéveloppement du coeur en conséquence