When you try to close a ticket and you missed to fill a mandatory field (eg category), the response field you took time to fill is TOTALLY EMPTY after clicking on save...

I would like in the future version to glpi a ipam

Dear GLPI Team,

I hope this message finds you well.

As a regular user of GLPI, I’d like to suggest an enhancement to the notification template system. Currently, the variable ##lang.ticket.content## includes the full HTML content of a ticket, including tags. While this is useful in some contexts, it can be problematic in email notifications where embedded images may disrupt formatting or aren't necessary.

Would it be possible to introduce an alternative variable—such as ##lang.ticket.content_raw## or ##lang.ticket.content_text##—that provides a plain-text version of the ticket content, stripped of HTML tags and especially image elements?

This would not only improve readability and flexibility when designing cleaner notifications, but also help reduce the size of outgoing emails—saving valuable space on mail servers and improving overall delivery performance.

Thank you for considering this request. I’d be happy to provide further context or examples if needed.

Best regards,

Zouheir

Hi everyone,

Currently, when customizing list views (e.g. in tickets or asset inventory), it's possible to define:

• a global view (shared by all users),

• a personal view (specific to the individual),and in each case, choose which columns to display.

I believe a very useful improvement would be to introduce the concept of thematic (or custom-named) views.

Why? Because depending on the context or the user profile, the required information can vary greatly.

For example, when I’m looking at the list of computers in the inventory, my needs are not always the same:

• Sometimes, I want a technical view (OS, hardware components, network info, etc.).

• Other times, I need a financial or administrative view (purchase date, warranty, cost, depreciation).

• Or perhaps a view focused on support or ticket-related data.

Being able to create and save multiple views for different use cases would greatly enhance flexibility. Users could quickly switch between views based on their current needs.

Ideally, each view could:

• Be set as personal or shared/public,

• Be assigned to specific user profiles (e.g. Technician, Manager, Self-Service user),

• Be named (e.g. “Technical View”, “Finance View”, etc.) for clarity.

I’m not sure if this has already been discussed, but such a feature would be extremely helpful for many organizations, especially those with diverse user roles accessing GLPI.

What do you think?

In the XML file returned by GLPI Agent on Android, at the very bottom, there is a field called ‘modem’ which contains, among other things, the “IMEI” field for the phone in question. It seems that this field is no longer used anywhere in GLPI. It would be useful to be able to retrieve this element so that it can be entered directly into the serial number field for ‘phone’ type items. Currently, the glpi agent field that is transferred to the telephone box is the UUID, which is already in the UUID box. This is not useful. Would it be possible to map the ‘IMEI’ element of the ‘Modem’ to the serial number of the phone device in GLPI?

Nowadays the rule engine, in case apllied to an update of a ticket, manages only values of fileds that has been just changed and not all the fields. this limit a lot the usage of the rule engine for tickets as it cannot consider fields that didn't change.

Hello

Is it possible to manage assets from GLPI 11 using Real VNC?

Regards

Currently, when viewing the ticket list, users have to open each ticket individually, which can be time-consuming when managing multiple tickets.

It would be great to have an option to open several selected tickets at once in separate browser tabs.

Proposed behavior:

1. The user selects multiple tickets in the list view.

2. The user clicks on the “Actions” button.

3. A new option appears, for example: “Open all in new tabs”.

4. Each selected ticket opens in its own browser tab.

Benefits:

• Saves time for technicians who need to consult or update multiple tickets quickly.

• Improves workflow efficiency for support teams handling large volumes of tickets.

Example use case:
A technician reviewing 10 recent tickets could select them all and open them simultaneously, instead of repeatedly right-clicking and opening each ticket manually.

Olá a todos,

Estou tentando criar uma regra no GLPI para evitar que um tíquete seja fechado se não houver nenhum artigo da Base de Conhecimento vinculado a ele , mas notei que nem o Business Rules nem o plugin Behaviors parecem incluir esse campo como uma condição ou ação.

Alguém conseguiu implementar algo semelhante (talvez usando um gatilho, um gancho ou personalização de código)?
O objetivo é garantir que os tickets só possam ser fechados após a associação de um artigo da Base de Conhecimento, garantindo a documentação adequada do conhecimento antes do encerramento.

Sugestões ou exemplos são bem-vindos. Agradecemos antecipadamente!