Feature #4366

Feature #170: Inventaire des périphériques internes

Review components management

Added by webmyster over 6 years ago. Updated about 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:webmyster% Done:

100%

Category:Inventory
Target version:0.85

Description

Je propose d'attaquer petit à petit le ticket #170.
Ce ticket se concentre sur la Refonte de la gestion des composants:

  • Rendre les objets inventoriables
    • Pour chaque type de composant avoir une gestion du même type que les cartouches : un type de composant (CommonDevice avec tous les Device...) avec des caractéristiques standard (fabricant, nom, ...) et des composants (Item_Devices avec tous les Item_Device...) avec des caractéristiques spécifiques (numéro de série, caractéristiques spécifiques). Chaque composant étant lié ou pas à un objet d'inventaire.
    • Les éléments en stock correspondent aux composants non liés à un matériel.
    • A la suppression d'un matériel, alerte disant que les composants seront supprimés en laissant le choix : réintégrer dans le stock ou destruction. Mais attention lors de la destruction "massive" de matériel. Sur la page des composants permettre la suppression des composants ou leur intégration dans le stock. Pour conserver des composants à la suppression d'un matériel, on les réintègre dans le stock avant la suppression du matériel.
    • On peut donc lier des infocoms, des documents (contrats ?) aux composants ainsi que des infocoms (comme template) et des documents aux types de composant.
      • Possibilité de voir les documents du type de composant dans les documents du composant
  • Les impacts sur le moteur de recherche seront minimes (ajout des nouvelles caractéristiques et types de composants)
  • Les tickets ne pourront pas être ouverts sur des composants.
  • Affichage des composants en stock et associés dans les types de composant
  • Sur un élément l'ajout d'un composant peut se faire dans le stock ou via une création d'un nouvel élément (choix : type de composant puis Créer un nouveau composant ou choisir un élément du stock)
  • Un type de composant peut être associé à une entité et récursif (un stock particulier). Un composant est associable aux éléments visibles par le type de composant. Possibilité de fusionner des stocks.
  • Éléments à compléter :
    • types de composant manquants : cartes sims, ventilateurs, alimentations, batterie (pour les portables), GBIC... Mais il reste la question de leur gestion par rapport à l'import OSC. Nous pourrions intégrer des composants depuis des plugins (cartes spécifiques : GPIB, HID ...) à la manière des NetworkPortInstantiation.
    • caractéristiques manquantes :
      • numéro de série, part number, model (c'est en partie réalisé) ;
      • deviceID : identifiant du composant : USB ID ou PCI ID, attaché au composant en lui-même
      • busID : identifiant de connexion du périphérique sur le bus, attaché aux composants du stock
      • à compléter...
    • Il faut pouvoir lier ces composants à tout type d'équipement selon les affinités. Pour cela, je propose que chaque Device... définisse ses affinités dans une méthode qui renvoie un tableau. Exemple d'association :
      • matos réseau : mémoire / alimentation / GBIC
      • imprimantes : mémoire / carte réseau
      • périphériques : mémoire, carte réseau (exemple : onduleurs)
      • moniteurs : haut-parleur, switch USB ?
      • téléphones :

Liste de questions :

Lorsque l'on détruit un item, il faut savoir ce que l'on fait des composants attachés. Une première solution serait d'afficher une boite de dialogue demandant ce que l'on souhaite en faire, Mais cela deviendra vite fastidieux, surtout dans les actions massives.
Nous pourrions également avoir un comportement par défaut défini dans les paramêtres de configuration (glpi_configs).
En effet, dans certaines sociétés, on ne s'embête pas à récupérer les anciens composants, alors que dans d'autres on fait de la récup.

Si nous transformons les item_devices en templates, alors il faut savoir ce que nous faisons lorsque nous instantion un Item depuis son template : prenons-nous dans le pool des Item_Devices non affectés, ou créons-nous de nouveau Item_Device* ?

Le plugin OCS a ses propres identifiants pour type de périphériques (1 => carte mère, 2 => processeur ...). Est-ce encore d'actualité ?
Pour le moment, ces mappings sont conservés. Mais ne peut-on inclure ce "mapping" dans le plugin en question, afin de s'abstraire complètement des identifiants ?


Related issues

Related to GLPI-PROJECT - Feature #3065: add core / thread to device CPU Closed 08/18/2011
Related to GLPI Documentation - Task #4788: Review components management Resolved 02/12/2014

Associated revisions

Revision 21100
Added by webmyster over 6 years ago

See #4366 : manage Item_Devices and allow several kind of items (Phone, Printer ...) to use Item_Devices

Revision 21130
Added by webmyster over 6 years ago

[0.85] Fix previous: allow massive action also for Device (see #4366)

Revision 21146
Added by webmyster over 6 years ago

[0.85] Massive action: remove item but not its devices (see #4366)

Revision 21147
Added by webmyster over 6 years ago

[0.85] Allow keeping the devices when deleting an item (see #4366)

Revision 22174
Added by webmyster about 6 years ago

Allow reaffectation of devices (see #4366)

Revision 22192
Added by webmyster about 6 years ago

Organize getDeviceTypes for ComponDevice and Item_Devices: prepare components added by plugins (see #4366)

Revision 22193
Added by webmyster about 6 years ago

Add document to CommonDevice (see #4366)

Revision 22194
Added by webmyster about 6 years ago

Allow devices from plugins (see #4366)

Revision 22195
Added by webmyster about 6 years ago

Allow to add components that already exists are that are new (see #4366)

Revision 22197
Added by webmyster about 6 years ago

Add missing fields for devices and manufacturers (see #4366)

Revision 22339
Added by webmyster about 6 years ago

Beginning of adding item_device forms (see #4366)

Revision 22340
Added by webmyster about 6 years ago

Clear table of components from item tab (see #4366)

Revision 22401
Added by webmyster about 6 years ago

Add infocom and document tabs to Item_Devices (see #4366)

Revision 22402
Added by webmyster about 6 years ago

Add entities to components (see #4366). Moyo, can you check ?
Best wishes !

Revision 22510
Added by moyo almost 6 years ago

fix for component : see #4366

Revision 22884
Added by moyo almost 6 years ago

device transfer see #4366

Revision 22886
Added by moyo almost 6 years ago

canUnrecurs for devices see #4366

History

#1 Updated by moyo over 6 years ago

Point préalable : mettre au clair les specs déjà écrite car la c'est un fourre tout difficilement lissible. Peut-être recréer une nouvelle page dans laquelle on extrait les éléments sur lesquels ce ticket porte.

#2 Updated by webmyster over 6 years ago

Ajout de complément dans le corps du ticket depuis la page Refonte de la gestion des composants.

#3 Updated by webmyster over 6 years ago

  • % Done changed from 0 to 20

#4 Updated by webmyster over 6 years ago

  • % Done changed from 20 to 50

#5 Updated by webmyster about 6 years ago

J'ai un petit soucis concernant la normalisation des devices : la mémoire et le processeur ont des champs frequence. Pour le processeur, en plus, il y a le champs frequency_default. C'est un long héritage (au moins 0.80.3).
Quelle distinction faites-vous entre frequence et frequency_default pour le CPU ? Ne peut-on pas uniformiser tout cela en mettant uniquement frequency_default ?

#6 Updated by webmyster about 6 years ago

  • % Done changed from 50 to 70

Added missing fields, infocoms, documents ...

#7 Updated by ddurieux about 6 years ago

De mémoire, le frequency_default est la frequence réelle du processeur et l'autre est la frequence actuelle (on peut modifier la frequence (+ ou -) dans le bios)

#8 Updated by webmyster about 6 years ago

ddurieux wrote:

De mémoire, le frequency_default est la frequence réelle du processeur et l'autre est la frequence actuelle (on peut modifier la frequence (+ ou -) dans le bios)

Ok, frequency_default est celle indiquée sur la boîte pour tous les processeur de même modèle. Mais c'est elle qui est mise par défaut lors de la création du Item_DeviceProcessor. Ensuite, la valeur en "tunning" est mise dans l'instanciation du processeur en question, donc, dans le champs frequency du Item_DeviceProcessor.
En résumé : lorsqu'il n'y a pas tunning, $deviceprocessor->fields['frequency_default'] == $item_deviceprocessor->fields['frequency'] et lorsqu'on joue avec la fréquence par défaut, $deviceprocessor->fields['frequency_default'] != $item_deviceprocessor->fields['frequency'].

#9 Updated by moyo about 6 years ago

Oui c'est bien cela.
Mais effectivement le champ frequence doit être historique (plus la mémoire du pourquoi) car il ne sert à pas grand chose.

En terme d'uniformisation on pourrait peut-être regrouper les 2 en un champ frequency qui reprendrait le comportement du _default

#10 Updated by moyo about 6 years ago

Pour ne pas oublier : ajout des nouveaux elements dans report.infocom.php

#11 Updated by moyo about 6 years ago

Manque la gestion des entités pour les types de composants et les composants. Là on a un stock global.

#12 Updated by moyo about 6 years ago

Revoir bigdump pour ajouter nouveaux champs pour avoir une DB utilisable

#13 Updated by webmyster about 6 years ago

  • Status changed from New to Assigned

#14 Updated by webmyster about 6 years ago

Comme le souligne Moyo, créer un formulaire spécifique par Item_Device* permettrait de simplifier les choses.
Cependant, cela va multiplier les fichier (front/item_devicememory.form.php, front/item_deviceprocessor.form.php ...). Il y a déjà un fichier front/item_devices.form.php. Est-il possible d'utiliser celui-là pour tous les Item_Device... ? Pour cela je pense qu'il "suffit" de surcharger la méthode Item_Devices::getLinkURL(). En plus de l'identifiant de l'item, nous passerions devicetype contenant le type du device (Processor, Memory ...).

#15 Updated by webmyster about 6 years ago

moyo wrote:

Manque la gestion des entités pour les types de composants et les composants. Là on a un stock global.

Première version de précision sur les spec :
  • Lorsque l'Item_Device* n'est attaché à rien, il rejoint l'entité de son CommonDevice ;
  • Il prend l'entité de l'Item lorsqu'il est attaché à un item (ordinateur, imprimante, switch ...) ;
  • Lorsqu'on le détache de l'Item, on le repasse dans l'entité de CommonDevice.

Mais j'ai un problème : que se passe-t-il pour un Item_Device* si on change l'entité de son item pour une entitée non "visible" du CommonDevice ? Cela ne pose-t-il pas de problème de vue ? Doit-on rattacher l'Item_Device à un CommonDevice équivalent d'une entité visible ? Pour cela, on pourrait se servir des champs USBID et PCIID. Mais tous les CommonDevice n'en sont pas dôtés.

Ne faut-il pas appliquer les entités uniquement aux Item_Devices et non au CommonDevice, Ces derniers étant des abstractions (classe) des premiers (instance ou objet) ?

#16 Updated by moyo about 6 years ago

Dans la logique de visibilité tu ne peux affecter un item_device que sur un item qui est dans une entité visible du CommonDevice.

Si le commondevice est dans l'entité X ses item_device ne seront associables que sur l'entité X.
Dans le cas d'un commondevice recursif, les item_device ne seront associables que sur l'entité et ses filles.

Les commondevice ont besoin d'être associés à une entité pour pouvoir gérer des cas de stocks différents dans des entités différentes qui ne vont pas gérer les même matériels de la même façon.

#17 Updated by webmyster about 6 years ago

Que se passe-t-il si on déplace un équipement (ordinateur, switch, imprimante ...) dans une entité qui n'est plus visible du le CommonDevice ?

#18 Updated by moyo about 6 years ago

Là il faut gérer le transfert pour savoir ce qui est conservé et ce qui ne l'est pas. Et donc peut-être faire évoluer cette partie transfert.

#19 Updated by moyo about 6 years ago

  • % Done changed from 0 to 70

#20 Updated by moyo almost 6 years ago

  • Subject changed from Refonte de la gestion des composants to Review components management

#21 Updated by moyo over 5 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 70 to 100

#22 Updated by moyo about 5 years ago

  • Blocked by deleted (Task #4788: Review components management)

#23 Updated by moyo about 5 years ago

  • Related to Task #4788: Review components management added

#24 Updated by moyo about 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF