Problématique

Affecter automatiquement une machine à une entité, lors de sa remontée depuis OCS.
Un ensemble de règles régit l'affectation des machines aux entités. Cette affectation est automatique et découle d'une analyse des données OCS.

Droits sur la multi entités

Il convient de créer un nouveau droit, celui d'affecter une machine à une entité.
Cette affectation pourra s'opérer depuis un profil.

Condition d'affectation d'une machine à une entité

Il y a plusieurs possibilités :
  • affectation par le TAG : contient / ne contient pas / commence par / fini par
  • affectation par serveur OCS : toutes les machines d'un serveur sont affectés à une entité
  • affectation par le serveur OCS ET par le TAG : toutes les machines d'un serveur avec un certain type de TAG

Propositions

proposition fdu
  • affectation par domaine
    proposition de Remi
  • affectation par Réseau
  • affectation par TAG
  • affectation mixte (ex TAG = entité principale, Réseau = sous-entité)
Walid :
Il faut voir comment on définit la liste des champs qui peuvent être utilisés pour l'affectation.
  • On fait une liste statique ?
  • on fait une table qui stocke nom de la table, nom du champs ?
  • comment on sélectionne les champs sur lesquels on va faire du matching ?

Dans un premier temps je propose de faire simple : on fait le matching sur le TAG ou le serveur OCS.

Moyo :
  • Pour la liste des champs : statique suffira amplement je pense. Le nombre de champs est borné, on peut les lister quasiment tous si besoin.
  • Pour la sélection : le critère utilisé serait a priori stocké dans un champ. Soit on fait un lien ID/champ, soit on stocke directement le critère dans un champ texte.

Ce qui a été implémenté

Principe de fonctionnement

Les règles d'affectation d'une machine à une entité sont directement basées sur le moteur générique de traitement des règles.
Ces règles sont du type RULE_OCS_AFFECT_COMPUTER. Elles sont composées de :
  • 1 description : le type RULE_OCS_AFFECT_COMPUTER est donné par défaut
  • de 0 à n critères. Si aucun critère n'est défini, la règle ne pourra jamais être vérifiée
  • 1 action : une seule action est possible pour l'affectation. Celle-ci est toujours de type "assign" et s'applique toujours sur le champ "FK_entities" d'un ordinateur (table glpi_computers)

Lors d'une installation ou d'une mise à jour depuis une version antérieure de GLPI, une règle est créée par défaut :

Cette règle permet de placer toutes les machines dans l'entité racine. Dans le cas d'une utilisation de GLPI sans gestion d'entités, cette entité générique permet de garder un import qui fonctionne.

Si aucune règle n'est définie, ou si *aucune règle n'est vérifiée*, la machine n'est *pas importée*.

L'ordre de définition des règles est très important. Celui-ci est défini par un classement (champs ranking dans glpi_rules_descriptions). 
** Le moteur charge les règles les unes après les autres par ordre croissant suivant le rang (ranking)
** Tant que la règle courante n'est pas vérifiée, le moteur charge la suivante
** Dès que le moteur trouve une règle qui correspond aux propriétés de la machine chargée, il exécute l'action qui lui est associée et ne charge pas les règles suivantes

Il est possible de changer l'ordre d'exécution des règles depuis la page "Administration->Règles". 

h2. Critères d'importation

Une règle peut possèder de 0 à n critères. Chacun est composé d'une des conditions suivantes :
** TAG
** Domaine Windows : 
** Serveur OCS : il faut préciser le nom du serveur OCS, et pas sur ID
** IP
** Sous-réseau IP
** Nom de la machine

Les critères peuvent se combiner de 2 manières :
** AND : pour que la règle soit vérifiée, on doit avoir A & B & C
** OR : pour que la règle soit vérifiée, on doit avoir A | B | C

On peut composer une règle à partir d'un ou plusieurs de ces élèments :
** TAG = XXX et IP = YYY.YYY.YYY.YYY
ou :
** Serveur OCS = XX ou IP contient 192.168

h2. Ajout de critères

Il y a 2 types de critères : 
** champs à vérifier depuis la base d'OCS : par exemple le TAG, l'adresse IP
** valeurs provenant de GLPI : par exemple le nom serveur OCS

L'ajout de critères supplémentaires pour les règles d'affectation s'opère en  :
** rajoutant une entrée pour un critère dans le fichier inc/rules.constant.php (c'est tout pour les critères provenant d'OCS)
** modifier du code dans le cas de valeurs provenant de GLPI

<pre>
RULES_CRITERIAS[RULE_OCS_AFFECT_COMPUTER]r1['ID']='TAG'; <- l'ID du TAG (nom arbitraire, traité en interne du moteur)
$RULES_CRITERIAS[RULE_OCS_AFFECT_COMPUTER]r1['table']='accountinfo'; <- table d'OCS dans laquelle se trouve l'information
$RULES_CRITERIAS[RULE_OCS_AFFECT_COMPUTER]r1['field']='TAG'; <- nom du champs de la table OCS qui contient l'information
$RULES_CRITERIAS[RULE_OCS_AFFECT_COMPUTER]r1['name']=$LANG[[ocsconfig]]; <- nom du champ tel qu'il sera affiché dans l'interface de règles de GLPI
$RULES_CRITERIAS[RULE_OCS_AFFECT_COMPUTER]r1['linkfield']='HARDWARE_ID'; <- indique le nom du champ de la table qui sera utilisé pour la clause WHERE. La table de référence est hardware. Si le champ est dans hardware, il ne faut pas indiquer de linkfield    
</pre>

//TODO : ajouter un exemple montrant les valeurs à ajouter dans le fichier constant.php