Hello,

The function to add a new dashboard (as seem in GLPI-Inventory plug-in and on GLPI-core itself) seems to assign the "name" in English, but on GLPI Core, it seems to assign the Dashboard name based on the current GLPI user language during install into ``glpi_dashboards_dashboards`` DB.

It would be great if GLPI could provide a way for plug-in and core classes to create translatable Dashboard names. I was able to translate a name if it's in English by adding ``$dashboard['name'] = __($dashboard['name']);`` into the foreach loop of ``getAll()`` function of ``Dashboard`` class, but it would require that the name of the Dashboard is saved in English on DB and to provide a way to ensure that the translation would be gathered by Transiflex since the translation happens on the fly instead of hardcoded, and as since the Transiflex bot doesn't extract those kind of strings, it would not detect the current Dashboard names as translatable as it is.

É possível criar mais de um quadro Kanban para o GLPI? 

I would like to have the option to set the status to pending and then select a pending reason and it's attributes from a Followup Template, like you can do when you manualy add a Followup.

This would help with automation. I can check with a rule if a ticket needs to be set to pending (it needs validaton that is outside of our control), then a Folowup is added from a template. 

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

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