You are not logged in.
Pages: 1
Topic closed
Bonjour,
je cherche, via requête SQL, à verrouiller en masse le champ Utilisateur des fiches materiels. J'ai vu dans le forum que tout semblait se situer au niveau de la table glpi_ocs_link et plus précisant dans le champ computer_update.
Je n'arrive pas à modifier ce champ pour lui ajouter la valeur correspondant au nom du champ Utilisateur (FK_user je crois).
voici ma requête SQL:
UPDATE `glpi_ocs_link` SET `computer_update` = `computer_update` & (SELECT CONVERT ('FK_USER',CHAR))
WHERE `ocs_deviceid` LIKE '%2p2612%'
FK_user étant de type int, je le converti en chaine.
Le resultat que j'obtient: le champ computer_update passe à 0.
J'utilise PHPMyadmin.
Si quelqu'un à une idée.... merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Perso, faire ce type de manip directement dans la base est franchement casse-gueule
> le champ computer_update passe à 0.
Normal, c'est ce que tu lui a demandé
+
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Je sais que ca fait un peu bidouillard mais voilà:
Le champ utilisateur est utilisé chez nous pour identifier le propriétaire d'un matériel. Le champ contact, lui, renseigne le dernier utilisateur s'étant connecté. Or, si pas verrouiller, le champ utilisateur se calque sur la valeur du champ contact. Dans notre logique de gestion de parc, seul le service informatique doit pourvoir modifier l'appartenance d'un materiel à un utilisateur.
Pour respecter cette logique, la seul solution est de verrouiller le champ utilisateur. Comme je n'ai pas envi de le faire materiel par materiel et qu'il n'existe pas de modifiation en masse pour faire cela sous GLPI (une idée pour une nouvelle fonctionnalité !), je ne vois pas d'autre solution que passé par SQL.
Je ne comprend pas ta conclusion. Je ne lui demande pas de se mettre à 0 (en tout cas c'est pas mon intention). Je demande à ce que le champ computer_update reprenne sa valeur + Fk_users. Ca ne doit pas être la conne syntax... c'est sur, d'où mon appel à l'aide.
Merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Bonjour j'ai le même problème que toi.
Si je veux les verrouiller ordi par ordi dans glpi comment dois-je faire ?
Merci
Offline
Il s'uffit de modifier le champ manuellement pour que GLPI le verrouille et empêche ainsi OCS de l'écraser à la prochaine syncronisation.
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Pour respecter cette logique, la seul solution est de verrouiller le champ utilisateur. Comme je n'ai pas envi de le faire materiel par materiel et qu'il n'existe pas de modifiation en masse pour faire cela sous GLPI (une idée pour une nouvelle fonctionnalité !), je ne vois pas d'autre solution que passé par SQL.
Il existe une modification en masse : dans inventaire/ordinateurs tu peux cocher la case de tous les pc que tu veux modifier puis tout en bas de la page tu vas sur la liste déroulante modifier / Utilisateur / NonAffecté VALIDER.
Tous les ordi selectionnés auront pour utilisateur NonAffecté (En plus de l'import LDAP, j'ai créé un utilisateur dans glpi qui s'appelle NonAffecté).
Last edited by free (2009-06-15 12:25:03)
Offline
Sauf que moi je veux que le champ utilisateur soit renseigné. Pour une bonne partie de mon parc, ce champ est bien renseigné. Ta solution impose de repasser sur chaque machine pour le renseigné comme voulu.
Pas une solution pour moi donc.
Merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Bonjour,
ça ne marche pas j'ai des pc qui sont affectés à des utilisateurs et glpi continue de les affecter à administrateur ou à des utilisateurs qui se connectent à la machine.
N'y a-t-il donc pas moyen de supprimer cette modification ?
Last edited by free (2009-06-15 14:40:14)
Offline
Quand tu modifies l'utilisateur et que tu appliques cette modif, tu dois voir, dans l'onglet OCS le champ utilisateur qui apparait dans la liste des champs verrouillés. Sinon, ya un pb dans le fonctionnement de ton GLPI.
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
OK j'ai vérifié ça et effectivement quelques PC n'avaient pas ce champs verrouillé.
Ca marche.
Offline
Parfait. Je ferme.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Pages: 1
Topic closed