You are not logged in.
Bonjour,
Il nous semble que le comportement des verrous de champs a changé dans la dernière version, sans que nous comprenions vraiment quelle est la nouvelle règle :
Nous avons depuis le tout début des verrous sur les champs ordinateur Modèle, Type, numéro inventaire et statut. Lorsque nous mettions un ordinateur au stock, nous renommions le pc avec un _old et nous enlevions l'utilisateur courant. Lorsque le PC était remis dans le parc, ces 2 champs étaient automatiquement mis à jour avec les bonnes valeurs (nouvel utilisateur et nouveau nom).
Cependant, depuis la dernière version, il semble qu'un verrou se mette sur tous les champs sur lesquels nous intervenons manuellement. Le nom et l'utilisateur ne se remettent donc pas à jour par inventaire automatique si nous n'allons pas faire sauter le verrou au préalable.
Plus étrange encore, sur la page verrou, il y a des valeurs dans la colonne "Valeurs du dernier inventaire" qui correspondent à des valeurs saisies manuellement (le statut par exemple qui est une valeur spécifique chez nous et qui n'est pas remontée par FI).
De plus, lorsque nous ôtons l'un des verrous, la valeur GLPI est aussitôt écrasée avec la valeur indiquée dans "valeurs du dernier inventaire", même s'il n'y a plus d'agent FI associé à cet ordinateur.
Exemple de fonctionnement que nous avions en version précédente :
Nos PC sont nommés "PC-[ID utilisateur]". Lorsque nous changeons un PC, nous le renommons en "PC-[ID utilisateur]-OLD" pour éviter les doublons de nom. Lorsque nous réaffectons le PC, il est automatiquement renommé "PC-[ID nouvel utilisateur] dans GLPI lors du premier inventaire.
Maintenant, lorsque nous renommons le PC, le nom est automatiquement verrouillé et ne sera pas changé automatiquement lors de la réaffectation. Pour que cela fonctionne il faut enlever le verrou (mais pas trop tôt, sinon nous avons un doublon de nom et des alertes).
Cela ajoute des actions supplémentaires à des techniciens qui passent maintenant bcp de temps à faire des actions dans GLPI ou à corriger des oublis provoquant des états de parc incorrects.
Est-ce une régression ou le nouveau comportement souhaité ?
Merci d'avance
Last edited by hasop (2020-09-17 09:22:24)
GLPI v9.5.1
FusionInventory 9.5
Offline
Bonjour,
Ce que j'ai observé de mon côté sur les anciennes versions de GLPI, c'est que un champ était bien automatiquement verrouillé après sa modification manuelle. Ce qui est logique si on considère que la valeur de ce champ est forcée par l'utilisateur, elle ne doit donc pas être écrasée lors du passage suivant de la remontée d'inventaire par FusionInventory ou OCS-ng. Et si on déverrouille un champ cela ne modifie pas la valeur de ce champ. Elle sera tout simplement mise à jour à l'occasion de la prochaine remontée d'inventaire. Ce fonctionnement me va bien.
Par contre depuis GLPI 9.5.x j'observe comme vous que le fait de déverrouiller un champ force immédiatement sa valeur à celle donnée par la dernière remontée d'inventaire, ce qui est problématique.
Et pire que cela : lors du passage de GLPI 9.4.3 à 9.5.1 (je suis actuellement en 9.5.2) tous les champs modifiés manuellement se sont déverrouillés, ce qui pourrit mes données à chaque remontée d'inventaire.
Je ne sais pas si ces deux bugs ont déjà été signalés, mais je n'en trouve pas trace sur ce forum.
Je ne sais pas non plus s'il est possible de faire une recherche et une action de masse sur les verrous pour les rétablir.
[Edit] comme je ne penses pas que ce problème soit spécifique au plugin FusionInventory, j'ai posté un nouveau message dans la section des Bugs de GLPI.
Last edited by servain-m (2020-10-13 16:08:09)
Debian 11 + Apache 2.4.56 + PHP 8.2.15 + MariaDB 10.11.6
GLPI 10.0.12 + manufacturersimports 3.0.5 + datainjection 2.13.4 + pdf 3.0.0 + reports 1.16.0
Offline
Bonjour,
"Je ne sais pas non plus s'il est possible de faire une recherche et une action de masse sur les verrous pour les rétablir."
Pour la recherche, non, je ne pense pas que ce soit possible. Par contre pour l'action de masse :
- tu peux verrouiller des champs par défaut au niveau des options d'administration FusionInventory (Configuration Générale > Verrous)
- tu peux modifier des verrous en masse (mais pas rétablir la valeur entrée manuellement). Une fois que tu as sélectionné tes actifs, tu cliques sur "Actions", puis "Verrous (champs)". De mon côté lorsque je fais du déverrouillage de masse, la valeur remontée par FusionInventory écrase automatiquement la valeur entrée manuellement (je suis sous GLPI 9.4.5)
Bonne journée.
Offline
- tu peux modifier des verrous en masse (mais pas rétablir la valeur entrée manuellement). Une fois que tu as sélectionné tes actifs, tu cliques sur "Actions", puis "Verrous (champs)". De mon côté lorsque je fais du déverrouillage de masse, la valeur remontée par FusionInventory écrase automatiquement la valeur entrée manuellement (je suis sous GLPI 9.4.5)
Merci David_G pour la description de cette fonction. Même si elle ne m'est que moyennement utile si je ne peux pas la coupler avec une opération de recherche.
J'ai remarqué ceci dit que curieusement je ne peux pas supprimer les verrous d'un champ en masse sur une sélection d'ordinateurs pour lesquels ce champ n'est pas toujours verrouillé. Il faut d'abord forcer l'ajout de ces verrous sur tous les ordinateurs de la sélection avant de les supprimer.
Debian 11 + Apache 2.4.56 + PHP 8.2.15 + MariaDB 10.11.6
GLPI 10.0.12 + manufacturersimports 3.0.5 + datainjection 2.13.4 + pdf 3.0.0 + reports 1.16.0
Offline