Allow me to suggest improvements?

It is about the tasks that are included in the tickets, problems and more.

Currently when we add a task with the To Do status and we need to close it later, just click the checkbox to complete the item. This action does not record any record of the date, time, and who did it. Nor in the history of the ticket.

We are directing analysts to add a comment, even though it may occur that the analyst clicks the button by mistake or just to be able to terminate the call (we use the plugins behaviors to block the call solution if there are pending tasks).

My suggestion would be to allow the task to close so only if the analyst includes a description.

The comment would be added in the timeline of actions with reference to the task and would record the name, date and hour that conslusion.

Bonjour je voudrais savoir quel version de generic object est compatible avec glpi 0.85.3

Ticket to be closed automatically only on business days based on the entity's calendar configuration (Assistance).

Prezados, sou deficiente visual, utilizo o leitor de telas (NVDA), na empreza estamos com a verção 9.1.2 do glpi; estou estudando sobre as novas versões para atualizar, porém, encontrei algumas inacessibilidades do sistema, como por exemplo ao criar um novo ticket, ao selecionar a localização, o leitor de telas não consegue ler as opções da caixa de seleção, dentre outras condições; este mesmo exemplo dado, na versão que uso atual 9.1.2 o leitor faz a leitura normalmente. embora não saiba programar, estou disposto a contribuir para a acessibilidade do sistema, e gostaria de poder contar com a colaboração dos programadores.

I have the GLPI 9.3.3 deployed in a company of 170 employees.

Eventually, some employees do not register the ticket, and the technician has to register the ticket by placing the user as the requester and changing the "Helpdesk" source to "direct / skype / phone".

Is there any way via business rules or otherwise, for when a ticket is registered and the source is not helpdesk, I set up a template informing the user that the technician needed to open the call on his behalf and becoming aware of the need to register the ticket.

Thankful!

(Note: I already opened an issue on official issue tracker but was asked to post on Userecho to see if it worth it. So here it is)

When the entity transfer wizard is cloning objets, an explicit "Cloning from object x" event should be added to clone object's logs.

I got into this when transferring a computer to another entity. That computer was attached to documents (and contracts) which where cloned into the destination entity.

Steps to reproduce (my experience, variations may also works)

• - Have the following entities:
  • Entity E1
  • Entity E2 (as a sub-entity of E1)
• Create computer C1 into entity E1
• Create computer C2 into entity E1
• Create document D into entity E1 (ID=726, used below)
• Attach document D to computers C1 and C2
• Transfer C1 to entity E2

Actual result

Computer C1 is now into entity E2.
A new document D' is created into entity E2 as a copy/clone of document D (the latter stays in E1) with ID=727 (in my example)
While cloning the document D, GLPI clones D_'s logs: it creates new events rows with new IDs keeping the original dates and other informations, but it alos adds two new events "Add the item" and "Change Entity E1 (0) by Entity E1 > Entity E2 (1)" timestamped at the date the transfer was performed.

Logs of D:

8641    2016-03-09 10:54    User (8)    Computer    Add a link with an item: Test computer2 for entity transfer (409)
8625    2016-03-09 10:46    User (8)    Computer    Add a link with an item: Test computer1 for entity transfer (408)
8624    2016-03-09 10:45    User (8)    -   Add the item

Logs of D':

9320    2016-03-09 11:00    User (8)    Entity  Change Entité racine (0) by Entité racine > FooBar (1)
9319    2016-03-09 10:54    User (8)    Computer    Add a link with an item: Test computer2 for entity transfer (409)
9316    2016-03-09 10:46    User (8)    Computer    Add a link with an item: Test computer1 for entity transfer (408)
9315    2016-03-09 10:45    User (8)    -   Add the item
9314    2016-03-09 11:00    User (8)    -   Add the item

We see that events 8624, 8625 and 8641 gets copied to D' as-is (respectively as 9315, 9316 and 9319) and that events 9314 and 9320 are added.

Proposition

I suggest that logs of that D' object states it was created as a clone of D.
The Event 9314's label should be "Create the item as a clone of Document 726" or something similar.

Context informations

GLPI version: 0.90.1

Print to pdf pdf 1.3.2 GPLv3 + Not installed Remi Collet, Nelly Mahu-Lasson https://forge.glpi-project.org/projects/pdf
This add-on requires GLPI> = 9.2 and <9.3. in version 9.4 it is impossible to install Print To PDF

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