crear un formulario dentro de un ticket generado que genere un pdf editable para dar solucion a un diagnostico de un equipo 

The "Global search" ist not really global yet.

It should be extended to search global as per its name. It should list all items that contain the search-text. For example i search for "ABC" and I expect to get a list of all items (assets, tickets, projects) where this text was used. It does not matter if the ticket is closed or open, the project is completed or not. I want to get ALL items as it is labeled as "Global search". I even want to get tickets included if the text was used only in a comment.

This is how a normal global search works in any other ITSM-Tool. Hope GLPI gets soon also this improvement.

It could be nice to make it possible to change values from the custom field plugin with business rules for tickets.

Hi,

After all the recent CVE for previous GLPI versions, I'd like to update our GLPI instance used for running FusionInventory to 10.0.17. FusionInventory plugin has been discontinued since 10.0.6 if I'm right and the recommanded alternative is to switch to GlpiInventory. But checking the GlpiInventory web site, it seems to support GLPI up to 10.0.11...

Is this new plugin really maintained? What is the plan to have a version supporting the recent GLPI versions?

Thanks in advance. Best regards,

Michel

Currently the Escalade plugin use the "simple" groupe name for:

- display of group modifications

- task generation of Escalade.

There could be an option to use the "full" (*) group names instead of the "simple" ones.

Rk*: "full" group name = [/parent groups name]/group name

Olá a todos!

Estou enfrentando um problema no GLPi relacionado à atribuição automática de chamados ao criar novos serviços. Vou detalhar a situação:

1. No órgão onde trabalho, dois setores tratam dos mesmos serviços.
2. No GLPi, mantivemos os mesmos formulários para esses serviços, mas configuramos regras para atribuir os chamados automaticamente:
   • Chamados abertos por usuários do setor "A" devem ser atribuídos ao GT do setor "A".
   • Chamados abertos por usuários do setor "B" devem ser atribuídos ao GT do setor "B".
3. Atualmente, há dois tipos de regras configuradas:
   • Regras por serviço, aplicadas para cada serviço individualmente.
   • Regras por entidade, aplicadas ao setor "B".
4. Não configuramos "Ações" para atribuir diretamente os chamados a um GT nas regras por serviço ou por entidade.
5. Existe uma regra que utiliza o critério "Código representando a categoria do chamado". Essa regra atua como uma espécie de "guarda-chuva" e, em suas "Ações", atribui os chamados ao GT do setor "A".

O que está funcionando bem:
Os serviços existentes estão sendo atribuídos corretamente, de acordo com o setor do usuário que abre o chamado.

O problema:
Ao criar um novo serviço (clonando uma regra existente), os chamados desse novo serviço apresentam o seguinte comportamento:

• Se o usuário é do setor "B", a atribuição ao GT do setor "B" ocorre corretamente (com base nas regras por entidade).
• Se o usuário é do setor "A", o chamado não é atribuído a nenhum GT.

O que já verifiquei:

• As configurações das regras clonadas parecem iguais às originais.
• Não configuramos ações nas regras por serviço ou entidade para atribuir diretamente a um GT, confiando na regra geral ("guarda-chuva") que utiliza o critério "Código representando a categoria do chamado" (me mantive utilizando o mesmo padrão de regras já existentes).

Pergunta:
Por que os chamados de novos serviços, criados clonando uma regra existente, não estão sendo atribuídos ao GT do setor "A" para usuários desse setor, considerando que a regra "guarda-chuva" atribui corretamente aos serviços já existentes?

Agradeço desde já por qualquer orientação

Deployment using the P2P option: The agent scans every host in every available network:

[Tue Nov 12 17:38:41 2024][info] running task Deploy
[Tue Nov 12 17:38:41 2024][info] looking for a peer in the network
[Tue Nov 12 17:43:59 2024][error] [http client] internal response: 500 Can't connect to 192.168.56.89:62354 ...
[Tue Nov 12 17:44:00 2024][error] [http client] internal response: 500 Can't connect to 192.168.0.247:62354 ...
[Tue Nov 12 17:44:01 2024][error] [http client] internal response: 500 Can't connect to 192.168.188.178:62354 ...
[Tue Nov 12 17:44:02 2024][error] [http client] internal response: 500 Can't connect to 192.168.191.109:62354 ...

There should be a way to tell the agent to only scan specific networks.

Hello,

Some of my clients want to benchmark team members and do count of resolution by technician statistics.

They want to have the number of tickets resolved by the technicians for a specific period.

Could you please add the ability to add a column name "Resolved by technician" filed with the name of the technician who add the solution on tickets view and statistics in the default reports ?

Regards,

When using custom anydesk msi installation for technician, the "anydesk:XXXXXX" doesn't work.

In this case, the link must be like : anydesk:AnyDesk-_msi:XXXXXXXX

It would be nice to be able to configure that

Currently in GPLI all assistance types have a numerical sequential number. 

Example:

Ticket: 1

Change: 1

Problem: 1

Task: 1

The problem here is that different assistance items can have an identical number. Quick differentiation is hard. Most ITSM tools allow for customization of these numbers per ITIL type:

Example:

INC0000001 >> or even better INC-1024-0001 (INC for Incident, mmYY for the date of creation - 0001 sequential numerical number.

PRB000001 or even better PRB10-24-0001

CHG000001 or PRB10-24-0001

INC000001-TSK01 < for task related to the above mentioned incident.

It would be brilliant if this could be implemented in the core product. It doesnt even have to replace the tables primary key. It could simply be an extra field in the table.