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

GLPI 10 have the reservation function native, but very simple and is not possible to costum them.
I would like to suggest some improvements to add more potential to this function.

1º option to require reservation approval (Anyone can make a reservation at the moment, without it being validated.)

2º Create the option to limit reservation time (Corrent the user can reserve a item forever) add option like 1 day, 7 days, 2 weeks, etc.

3º Add a field with terms and conditions for equipment reservations, which must be accepted by the applicant at the time of reservation.

Thanks and my best regards

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

English:

Title: Implementation of Proximity Search Criteria in GLPI

Description: Taking advantage of the geolocation capabilities in GLPI and its integration with the OpenStreetMap API, I suggest analyzing the feasibility of implementing a search criterion that allows identifying tickets within a radius or road distance of X km from a selected location or the current location determined by GPS. This feature would be extremely useful to optimize technicians' time, especially when they are traveling to remote areas to resolve incidents. By enabling the advancement of other tickets in the region, the efficiency and utilization of time would be significantly improved.

Benefits:

1. Time Optimization: Technicians can anticipate services while traveling.

2. Efficiency in Service: Reduction of idle time and increase in completed tickets.

3. Improvement in Ticket Management: Better resource allocation and ticket prioritization.

4. Customer Satisfaction: Reduction in waiting time for problem resolution.

Sugestão de Melhoria para o GLPI: Critério de Busca por Proximidade

Português:

Título: Implementação de Critério de Busca por Proximidade no GLPI

Descrição: Com a possibilidade de geolocalização das localizações no GLPI e a integração da API do OpenStreetMap, sugiro analisar a viabilidade de implementar um critério de busca que permita identificar chamados dentro de um raio ou distância rodoviária de X km de uma localidade selecionada ou da localização atual determinada por GPS. Essa funcionalidade seria extremamente útil para otimizar o tempo dos técnicos, principalmente quando estão se deslocando para áreas remotas para resolver incidentes. Ao possibilitar o adiantamento do atendimento de outros chamados na região, a eficiência e a utilização do tempo seriam significativamente melhoradas.

Benefícios:

1. **Otimização do Tempo**: Técnicos podem antecipar atendimentos enquanto estão em deslocamento.

2. **Eficiência no Atendimento**: Redução de tempo ocioso e aumento de atendimentos concluídos.

3. **Melhoria na Gestão de Chamados**: Melhora na alocação de recursos e priorização de chamados.

4. **Satisfação do Cliente**: Redução do tempo de espera para resolução dos problemas.

---

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.

read only field in tickets using template
the template editor selects the fields that should be read only 
should be something like the ability to select hidden fields and mendatory fields 
it can be populated by business rules,

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