Bonjour,

Dans le cadre d'un développement d'architecture, je dois lier plusieurs serveurs GLPI entre eux. "Existe t-il un plugin qui pourrai répondre à mes attentes, ou une manipulation ?" Le but étant d'avoir 1 GLPI regroupant toutes les BDDs afin de gérer en temps réel la réception, le contrôle et l'envoie des tickets. Ainsi, les serveurs GLPI sont à l'image des entreprises destinataires, et le GLPI principal gère les autres. (idée de Client/Serveur). 

En vous remerciant, 

Cordialement,

M.L

Hello,

As part of an architectural development, GLPI them. "Is there a plugin that can meet my expectations, or manipulation?" GLPI Grouping all the BDDs to manage the reception, the control and the sending of the notes. Thus, the GLPI servers are in the image of the recipient companies, and the main GLPI manages the others. (client / server idea).

Thanking you, 

Regards,

M.L

Bonjour,

Je viens vers vous concernant un soucis ou plus particulièrement une fonction que je n'arrive pas à réaliser concernant notre projet.

Explication : Nous avons installés et paramétrés GLPI pour pouvoir envoyer/recevoir et régler des demandes (outil de ticketing/gestion des demandes), tout fonctionne nous recevons les notifications, tout est pour le mieux à ce niveau là.

Problème : nous avons besoins de recevoir des demandes sur 2 Unités et +. Pour cela nous souhaitons donc créer plusieurs formulaires, un formulaire pour chaque unité.

J'ai donc paramétré le formulaire de la version standard comme il nous conviens (car la version simplifié est trop juste), ce formulaire nous conviens donc parfaitement pour réponde à 1 Unité.

J'ai donc commencé à utiliser le plugin "FormCreator" pour une de nos autres unité. Cela à également bien fonctionné. Venons au problème, quand je créer un ticket et l'envoie, le formulaire du plugin se converti et remplis le formulaire standard que j'ai paramétré, hors nous pensions que le formulaire du plugin serai représenté exactement de la même manière que lorsqu'on l'a remplis (Les champs restent et le réalisateur vois les champs remplis avec le contenue du demandeur, les info se mettent dans la partie description du formulaire GLPI lors de la visualisation de mon ticket et non pas dans des cases). Donc mauvaise solution, du moins ce n'est pas ce que nous cherchons.

Ce que j'ai donc essayé par la suite c'est de rajouter des champs dans notre formulaire standard de GLPI. Cela fonctionne bien également, mis appart que lorsque je change de "Gabarits de tickets" et que je passe sur l'autre Unité (je vois bien mon formulaire changer et s'adapter à mon unité celons mon paramétrage) en revanche, les champs que j'ai ajouter avec le plugin GLPI-FIELDS restent , peut importe le gabarit de tickets, je ne peux pas choisir quand les faire apparaître ou non.

Auriez vous une solution à mon problème s'il vous plait ? Ou une idée comment le faire, pour que j'ai deux formulaires bien distincts et également une présentation ergonomique et non comme pour le plugin FormCreator (ou mes informations lors de l'envoie les informations entrée dans le formulaire du plugin se mettent dans la partie description lors de la visualisation de mon ticket et non pas dans des cases).

Je vous remercie de l'attention que vous portez à ma demande.

En vous souhaitant bonne réception.

Matthieu Muller

OPM-MPSI

RATP Infrastructures

12, avenue du Val de Fontenay —LAC VJ60

94724 Fontenay-sous-Bois CEDEX

ratp.fr

If we want to set the requesting client on the ticket notification, everything is fine,

and we can also choose: Administrator, Supervisor, etc.

But when we want to do the same thing for contract notifications, we can't.

There is only the profile: * and the group: * the group supervisor: * etc.

Because the choice is relative to the context of the element: Ticket, Contract, Problem etc.

Not good at least for me.

When a notification for a contract is sent, all users of the entity receive it, simply because we can only choose Profile: Applicant.

As a contract is tied to a machine (a printer in our case), we simply want the user of this printer to be notified, not all other users of the entity.

I created another profile for those who manage the entity and if I have to send contract notifications to them, I put it in the contract notice.

To make things simpler:

I think we need all the features of the recipients regardless of the notifications.

We have a lot of feedback from customers who do not understand why they receive a notification that does not concern them.

Thanks

Hello friends, I am a GLPI user with inventory of equipment from the fusion agent but I had a theft of hardware parts more specifically RAM memory, but we never knew when this happened and with this case I want to ask if there is a notification for it to alert on the change hardware of a PC. Example: my PC was reported with 4 Gb in RAM for the first time and the next time the agent was reported and had only 2 Gb in RAM, this means that 2 Gb were extracted and at this time GLPI generates a notification warning about the change.

it may be possible to add a differentiation between the virtualization levels (LDOM'S and ZONES) in solaris 11 in order to gather more information about the serial number and the different zfs or zpool associated with the main system.

I would like to contribute with these proposals

May you considerate CMDB, CHAT, REMOTE DESKTOP?

Bonjour

Je possède un GLPI 9.3.3 pour gérer les incidents informatiques chez nos clients.

Est il possible d'empêcher l'ouverture et la saisie d'un ticket dans le cas ou le contrat du client dépassé, annulé ou expiré.

Merci pour vos réponses.

It would be great, to have the count of inventory items in on the overview page, when there a more than one of the same type/name:

I am looking for customize the asset fields 

Hello everyone,
I would have a suggestion for improvement for GLPI, I miss it very much in the area of the followups something similar to the solution model.
Where would you record the followups with the standard text.

For example:
I have to ask the user to contact the service center because we can not get in touch with the user. This text could already be registered in the tool that standardizes the communication of the technicians with the users.