Developers:Ocsreports
From OCS Inventory NG
Translation in progress
Documentation Développeurs
The version 2.0 of the OCS Web interface has been rethought to allow anyone to bring its development by a system of module. So, the base of the OCS Web interface is separated from additional modules.
In this version, you can entirely configure your web interface. You can add, remove or modify fonctionnalities. You can also using external application to control the connexions right (like LDAP or SSO for exemple).
Finally, you can manage your own profiles and so add or delete rights for it. For example, you can add the teledeploy to a limited user (even if it is strongly disadvised).
Devel a modules to OCS web interface
From the version 2.0 of the HCI of OCSInventory-ng, it is possible to create easily its own additional modules (plugins) and they can become integrated totally into the environment alreadyin production. For it certain rules of development were organized.
Architectural rules of code
Dans un premier temps, il est important de respecter l'architecture de fichiers. Il est nécessaire de créer une nouvelle section dans le répertoire /plugins/main_sections et de nommer votre nouveau répertoire « ms_<nom_de_votre_module> »
Les icônes de l'interface se trouvent dans le répertoire /plugins/main_sections/img. Si vous désirez ajouter un icône avec votre module, vous devrez le faire dans ce répertoire. Le nom du nouvel icône devra être sous la forme : « ms_<nom_de_votre_module>.png » pour l'icône inactive et « ms_<nom_de_votre_module>_a.png » pour l'icône active. Ajouter un icône n'est pas une obligation, car vous pouvez ajouter votre module dans un menu déjà en place ou même créer un menu sur un icône.
Votre module doit ensuite être composé d'une page PHP principale ayant le même nom que votre répertoire. Les pages annexes doivent toutes commencer par « ms_ ».
Si vous avez des fonctions particulières, vous devez créer un répertoire « require » dans votre module et créer vos fichiers de fonctions dedans. Aucune norme de nommage n'est donnée.
Si vous avez des fonctions javascripts à charger dans le header, vous devez créer un répertoire « js » dans votre module et créer un ou plusieurs fichiers dedant en « .js ». Aucune norme de nommage des fichiers javascript n'est donnée.
Votre module doit obligatoirement contenir un fichier info.txt qui donne les informations de votre module.
Dans vos développements, tenez compte que le header et footer php sont déjà géré par l'interface OCS.
La structure de votre module doit donc ressembler à l'exemple ci-dessous.
Intégrer votre module à l'interface OCSREPORTS
L'intégration du module à l'interface se fait en éditant le fichier « 4all_config.txt ». Ce fichier est composé de différentes sections :
ORDER_FIRST_TABLE
Cette partie permet de définir les icônes présentes en haut à gauche à l'affichage. Les noms présents ici sont les noms des fichiers présents dans /plugins/main_sections/img
ORDER_SECOND_TABLE
Cette partie permet de définir les icônes présentes en haut à gauche à l'affichage. Les noms présents ici sont les noms des fichiers présents dans /plugins/main_sections/img
LBL
Ici sont définis les noms à l'affichage des modules. Pour une icône, le texte apparaîtra en label. Nous devons toujours utiliser les fichiers de langue pour les libellés
URL
Cette partie est utile uniquement pour l'affichage dans l'url de la page . Il sera sous la forme : <nom_du_module> : <nom_url_du_module>
DIRECTORY
Dans cette partie, vous devez indiquer l'emplacement des pages que vous avez créé. Vous aurez donc : <nom_de_ma_page> : <repertoire_de_mon_module> Si vous avez plusieurs pages, vous rajouterez ensuite :
<nom_de_ma_page_1> : <repertoire_de_mon_module> <nom_de_ma_page_2> : <repertoire_de_mon_module>
MENU
Là, sont définis les pages appartenant au menu de l'affichage. Nous avons donc : <nom_du_module> : <nom_du_menu> Le nom du module est défini par le nom de l'icône.
MENU_NAME
Chaque menu doit être défini ici. La convention de nommage est à respecter : <nom_du_menu> : <nom>_smenu
MENU_TITLE
Titre du menu. Il est important d'utiliser les fichiers de langue. <nom_du_menu> : g(<numéro_dans_le_fichier_de_langue>)
JAVASCRIPT
Si vous avez créé des javascripts à charger dans le header, il faut l'indiquer dans cette partie : <nom_page_javascript>.js : <répertoire_ou_se_trouve_le_fichier>
Une fois que vous avez fini de déclaré votre module, il ne reste plus qu'à définir les profils ayant les droits d'y accéder.
Accès au module par un profil
Les profils sont définis dans le répertoire /plugins/main_sections. Ils sont configurés dans des fichiers texte nommés XXX_config.txt (hors 4all_config.txt qui sert à la configuration générale des modules). Par défaut, vous avez la liste ci-dessous:
Si vous désirez donner accès à votre module au profil « sadmin », il vous suffit d'éditer le fichier sadmin_config.txt et de rajouter vos noms de page dans la section <PAGE_PROFIL> Si votre module doit être visible par tous, il vous faudra éditer chaque fichier de configuration des profils.
Attention : si votre module contient plusieurs pages visibles par l'utilisateur, vous devez toutes les déclarer.
Une fois cela effectué, votre module sera actif à la prochaine ouverture de session.
Créer un profil particulier de connexion
A partir de la version 2.0 de l'interface web d'OCSInventory-ng, vous pouvez créer et modifier n'importe quel profil.
Tout les profils sont définis dans le répertoire /plugins/main_sections. Ils sont configurés dans des fichiers texte nommés XXX_config.txt (hors 4all_config.txt qui sert à la configuration générale des modules) Si vous créez vos profils, vous devez ABSOLUMENT respecter l'architecture d'un fichier de base.
L'architecture d'un fichier de configuration d'un profil
Plusieurs sections sont présentes dans chaque profil et plusieurs variables appartiennent à ces sections. Ces données sont chargées en variables de session sous la forme :
$_SESSION['OCS'][<SECTION>][<VARIABLE>]=<VALEUR>
Vous pouvez donc en rajouter à votre convenance pour vos développements.
Description des sections:
<RESTRICTION>
Cette section permet de définir les restrictions éventuelles qu'aura la profil. Par défaut, nous avons les valeurs suivante :
GUI : Variable qui défini si le profil a accès à toutes les machines ou s'il est restreint à des TAG de machines. Valeurs possible : YES/NO
TELEDIFF_WK : Variable qui précise si le profil à une visibilité restreinte des demandes de télédiff. Valeurs possible :
LOGIN (Le profil ne verra que les demandes faites par lui),
USER_GROUP (le profil ne verra que les demandes faites par son groupe et par lui-même),
NO (Le profil verra toutes les demandes)
TELEDIFF_WK_FIELDS : Certains champs des demandes de télédiff peuvent être limités en écriture ou rendu invisibles. Valeurs possible : YES/NO
<ADMIN_BLACKLIST>
Cette section permet de donner les droits à un profil sur l'administration des valeurs de Blacklist.
SERIAL : Administration de blacklist des numéros de série. Valeurs possible : YES/NO
MACADD : Administration de blacklist des adresses macs. Valeurs possible : YES/NO
<CONFIGURATION>
Cette section permet de donner au profil certaines configurations de l'interface.
TELEDIFF : Donne accès à la télédistribution. Valeurs possible : YES/NO
CONFIG : Permet de gérer la configuration du serveur OCS. Valeurs possible : YES/NO
GROUPS : Donne la possibilité de gérer les groupes de machines. Valeurs possible : YES/NO
CONSOLE : Donne la gestion de la console qui s'affiche à la connexion. Valeurs possible : YES/NO
IPDISCOVER : Donne la gestion des sous-réseaux et des types de périphériques découvert. Valeurs possible : YES/NO
TELEDIFF_WK : Donne la possibilité de configurer le workflow des demandes de télédiff. Valeurs possible : YES/NO
ALERTE_MSG : Affiche ou pas les messages dans le bandeau de l'interface. Valeurs possible : YES/NO
<PAGE_PROFIL>
Cette section sert a définir les pages auquel le profil aura accès. La liste des pages disponibles se trouve dans le fichier 4all_config.txt
Toutes modification sur un profil ou l'ajout d'un nouveau profil, ne sera visible dans la gestion des utilisateurs que lors de la prochaine ouverture de session.
Ajouter une nouvelle section aux détails d'une machine
Les différentes sections des détails d'une machine sont gérés sous forme de modules indépendants.
Règles d'architecture du code
Il est important de respecter l'architecture de fichiers. Il est nécessaire de créer une nouvelle section dans le répertoire /plugins/computer_detail et de nommer votre nouveau répertoire « cd_<nom_de_votre_module> »
Les icônes correspondantes aux sections des détails d'une machine sont présents dans le répertoire /plugins/computer_detail/img . Le format de ces icônes respecte le format standard des icônes OCS.
Les fichiers de fonctions communes à plusieurs modules doivent être placés dans le repertoire /plugins/computer_detail/require. Dans les cas de fonctions propres au module, elles doivent être placées dans un repertoire /require au sein du module.
Le répertoire du module doit obligatoirement contenir une page PHP principale portant le même nom.
Fichier de configuration des modules
Le fichier de configuration est le fichier /plugins/computer_detail/config.txt. Il se compose de plusieurs sections. Les 2 premières sont obligatoires et doivent donc être complétés si vous ajoutez votre propre module. Tout changement dans le fichier de configuration ne sera visible qu'à la prochaine ouverture de session.
<ORDER>
Cette partie défini dans quel ordre va s'afficher les modules.
<LBL>
Cette partie défini les bulles-libellés qui seront affichés lors du passage de la souris sur l'icône. Il est important d'utiliser les fichiers de langue et donc de respecter la structure : <nom_module>:g(<numéro de ligne>)
<ISAVAIL>
Cette partie est facultative. Elle permet de griser ou non un icône, en fonction de la présence de la donnée en base de donnée. Pour que cela soit opérationnel, il est nécessaire d'avoir les deux formats d'icône : <nom_module>.png et <nom_module>_a.png dans le répertoire /plugins/computer_detail/img Vous devez obligatoirement respecter le format : <nom_module>:<table_presence_hardware_id>
Déléguer les droits d'identification à une application tiers
A partir de la version 2.0 de l'interface web d'OCSInventory, il est possible de gérer les connexions sous forme de modules. Il faut bien différencier l'authentification et l'identification. L'authentification permet de donner accès à OCSREPORTS, l'identification permet de calculer les droits de la personne venant de se connecter
Présentation de l'architecture du code
Toute la partie authentification se trouve dans le répertoire /backend/AUTH
La page auth.php permet de gérer les différentes méthodes qui seront appelés lors de l'authentification.
La liste des méthodes disponibles sont présentes dans le répertoire /backend/AUTH/methode. Par défaut, 3 méthodes sont disponibles :
always_ok : accepte toute connexion à l'interface OCS ldap : délègue les connexions à un annuaire LDAP (Gestion des paramètres à travers l'interface) local : l'authentification se fait à partir de la base local OCS.
Chaque méthode complète 3 variables :
$login_successful : renvoi OK si la personne est authentifiée $user_group : défini le groupe de l'utilisateur (essentiellement pour le module de workflow de télédéploiement) $cnx_origine : renvoi le type de méthode qui a validé l'authentification de l'utilisateur
Si vous créez votre propre méthode pour déléguer les droits d'authentification à une application tiers, il est important de respecter le remplissage de ces 3 variables.
configuration de l'authentification
Pour le moment, la configuration de l'authentification ne peut se faire que par l'édition du code de auth.php
Présentation des différentes parties
Il est possible d'avoir une authentification
html : $affich_method='HTML'; popup. $affich_method='SSO';
Pour définir la méthode d'authentification, il faut éditer la variable $list_methode. Vous pouvez donc lui donner le nom de la page qui servira d'authentification.
Par défaut, l'authentification se fait avec le fichier local.php.
Astuce : il est possible de cumuler les méthodes d'authentification. Vous pouvez donc donner plusieurs valeurs à la variable $list_methode.
Exemple : $list_methode=array(0=>"ldap.php",1=>"local.php") Ainsi, l'authentification commencera par une authentification LDAP et si l'utilisateur est inconnu, l'authentification continuera sur la base locale OCS.
Si vous utiliser un SSO pour l'authentification, il est nécessaire que ce dernier remplisse les variables $_SERVER['PHP_AUTH_USER'] et $_SERVER['PHP_AUTH_PW'] pour qu'aucune demande d'authentification ne soit affiché par l'interface OCS.
Déléguer le calcul de droits du profil à une application tiers
Cette partie du code permet de gérer les droits sur l'application sous forme de module. Par défaut, la gestion des droits se fait sur la base locale ocs.
Présentation de l'architecture du code
Toute la partie d'identification se trouve dans le répertoire /backend/identity
Une page identity.php gère les différentes méthodes disponibles pour l'identification.
Chaque méthode doit obligatoirement gérer et renvoyer 3 variables :
$restriction : variable récupéré dans le fichier de configuration du profil et qui permet de savoir si l'utilisateur
qui se connecte à le droit de voir toutes les machines présentes dans OCS
$list_tag : Si la variable $restriction a pour valeur « YES », cette variable de type tableau doit être complétée
par la liste des TAG sur lequel l'utilisateur à une visibilité.
$ERROR : variable d'erreur qui va s'afficher si une erreur est rencontrée
Configuration de l'identification
Pour le moment, la gestion de l'identification doit se faire en éditant le fichier identity.php
Vous pouvez modifier la variable $list_methode qui défini la méthode qui va être utiliser pour faire l'identification. Cette variable est de type tableau.
Astuce : Vous pouvez cumuler les droits à partir de plusieurs méthode.
Par exemple : $list_methode=array(0=>"local.php",1=>"ldap.php") ;
permet de commencer par rechercher les droits de la personne connectée en local,
puis de rechercher les autres droits à partir de la page ldap.php.
Déléguer la configuration des sous-réseaux ipdiscover à une application tiers
Il est possible de gérer la liste des sous-réseaux sous forme de module pour déléguer ce calcul à une application tiers.
Présentation de l'architecture du code
Toute la partie d'identification se trouve dans le répertoire /backend/ipdiscover. Le principe est le même pour les modules précédent.
La page ipdiscover.php gère les différentes méthodes présentes dans le répertoire /backend/ipdiscover/methode.
Chaque méthode doit générer un tableau
$list_ip[$id][$ipsubnet]=$name
La valeur $id doit représenter l'ID du réseau. La valeur $ipsubnet doit être l'adresse du sous-réseaux la valeur $name doit être le libellé du sous-réseaux
Configuration de l'ipdiscover
Pour le moment cette configuration ne peut se faire qu'en éditant le fichier
/backend/ipdiscover/ipdiscover.php
En modifiant la variable $list_methode, qui est de type tableau, vous allez pouvoir appeler vos propres méthodes.
Il est là aussi possible de cumuler les méthodes de calcul de l'ipdiscover.
Remarque : si le calcul de l'ipdiscover ne se fait plus en local, vous n'aurez plus moyen d'ajouter/supprimer/modifier
les sous-réseaux par l'interface Web, puisque cela sera géré à partir d'une base tiers.
