Suivi des actions à réaliser pour sortir OCS du core

tâche comment quand par qui realisation
1 Créer le plugin et y inclure les pages du core Reprendre les pages du core et les normaliser pour un plugin
(noms des fichiers, des fonctions et des appels de fonction
Tâche N° 1 Xavier Terminée
2 Adapter les corrections/evolutions/modification du core reporter les commits afférents à OCS sur le plugin lors du CS Nelly Au fil de l'eau
3 Créer la procédure de fresh install du plugin écriture de la fonction d'installation
et de désinstallation du plugin
après étape 1 Xavier Terminée
4 Ecrire la procédure de migration core->plugin
Cette procédure ne doit pas se contenter de reprendre les
informations du core dans le plugin mais également de nettoyer le core
Il faut bien entendu prendre en compte les personnes n'utilisant pas
le mode OCS dans GLPI
La table du core est reprise intégralement par le plugin :
le core : renomme cette table en OCS_nomdelatable
le plugin : récupère cette table et la normalise pour un plugin
(nom de la table et des champs qu'elle contient)
Seuls certains champs de la table du core sont repris par le plugin :
le core : => renomme cette table en OCS_nomdelatable
=> suppression des champs lors de la migration
le plugin : => récupère les valeurs des champs dans la table glpi pour les injecter dans sa propre table
Bien entendu il faut également modifier les form du core pour
supprimer l'affichage des champs paramétrables repris par le plugin
Il faut également revoir les pages du plugin pour adaptation si besoin
Après étape 1 Nelly En cours
5 Passer le plugin en gettext Supprimer les $LANG Après étape 1 Nelly Terminé
6 Le verrouillage des champs doit être géré par le plugin
Le verrouillage des objets doit être géré par le core
Actuellement, cela est géré dans le table ocslink
qui est reprise intégralement dans le plugin.
Pour le verrouillage des objets :
suppression des champs concernés dans la table ocslinks du plugin
ajout d'un champ is_dynamic dans la table de l'objet dans GLPI
après étape 1 Walid En cours
7 Affichage des informations spécifiques OCS Reprendre les informations supprimés du form de l'objet
Ajout d'un hook dans l'ordinateur pour ajouter ces informations gérées par le plugin
après étape 1 MoYo Terminé
8 Moteur de règles Implémenter les hooks Après le ticket du core #3421 Walid Terminé
9 Transfert Déporter le code OCS dans le plugin A faire

Points sortis du core et mis dans le plugin

points fait le vérifié le
droits ocsng sortis du profil
(partie Outils de l'onglet Inventaire)
29-03-2012 NL
onglet "mode OCS" affiché par le plugin 15/05/2012 NL
onglet "base de registre" affiché par le plugin 16/05/2012 NL
gestion des historiques par le plugin
(HISTORY_OCS...
24/05/2012 RC

Points du core à voir pour sortie en plugin

Les points en suspend sont identifiés dans le core en //TODO OCS

  • $CFG_GLPI['use_ocs_mode'] => créer un hook pour dire que ce plugin est un plugin d'import ?
    Nelly : non
  • HISTORY_OCS... => gestion de l'historisation passée et future ? Cf https://forge.indepnet.net/issues/3423
    Nelly : fait par Remi
  • actions de masse à reprendre dans le plugin
    Nelly : fait
  • Clés base de registre => basées sur droits OCS, donc devrait aussi être dans le plugin ?
    ou alors on reprend le droit computer ou on créé un droit spécifique
    Nelly : uniquement utilisé par OCS donc mis dans plugin OCS
  • GetCriterias et getActions pour ruleImportComputer

OCSplugin

But : sortir toute la partie OCS dans un plugin

Ticket #976

Les grands axes

  • Définir les parties à garder dans le coeur et celle à sortir
  • Fusionner ces parties sorties avec le plugin massocsimport

Parties à garder dans le coeur

  • gestion des verrous
  • TAG représentant l'entité (dans le form de l'entité)
    • Walid : cette information n'est pas spécifique à OCS
  • Walid : doit-on stocker l'information du client qui a remonté l'inventaire quelque part ?

parties à sortir du coeur

  • Configuration du plugin
    Nelly : fait
  • Règles d'affectation d'un ordinateur à une entité
    • Walid : doit-on sortir les règles ? ou juste la récupération des critères ? parce qu'un autre outil d'inventaire pourrait utiliser le même mécanisme
  • Informations OCS qui sont dans le form de Computer à mettre dans un onglet spécifique au plugin
    • Walid : Onglet spécifique ou sous partie dans le form principal ?
  • Onglet OCSNG
    Nelly : maintenant géré par le plugin
  • Traductions (LANG)
    Nelly : passage en gettext fait et récupération des chaines du core (fait par Julien)
  • Outils de synchro (voir l'intégration avec la synchro de massocsimport vue que le comportement n'est pas le même)
    • Walid : donc tu proposes quoi ?
  • Actions automatiques OCSNG (synchro)
  • le champs de configurationgénérale "inventaire" (Activer le mode OCSNG oui/non)
    Nelly : n'a pas lieu d'être. Se baser si besoin sur l'activation ou non du plugin

Walid : et donc ? comment renommer les tables ? quelles sont les informations qui restent dans le coeur de la DB ?
Nelly : tables renommées en OCS_ancienNom et utilisées par le plugin lors de son installation
les tickets existent sur la roadmap de GLPI pour les renommages

Synchronisation

Actuellement la synchro du coeur n'est pas tout à fait la même que dans le plugin massocsimport.
Le passage de 2 mode de synchro à un seul me semble une bonne chose.
Donc on a 2 choix :

  1. Mode de synchro du coeur
  2. mode de synchro de massocsimport

David : je penche pour la 2ème
Walid : les 2 comportements ont 2 objectifs distincts. Pourquoi en éliminer un ?