I need to classify tickets using the source form filter (service catalog); however, the current version does not allow this filter to be applied.

The purpose of this is to know which service catalog the case originated from.

Hello there!

I tried to select several users to change setting "Enable notifications" massively so I could disable all notifications for them. Sadly, when selecting several users and try to change this setting by using "Actions > Update" menu, "Enable notifications" is not shown in the dropdown, so I must change this setting individually.

Could you add this massive action for editing users?

Thanks!

I have GLPI 11.0.4 and I am setting up two-factor authentication (2FA) for my users. Everything works fine in testing, but I cannot find a way to add the device I used to log in via 2FA as a trusted device, so that it does not ask for it again at the next login, assuming it is the same device, of course.

It would be useful to consider this option and allow users to manage their trusted devices.

As for assets, i think it could be usefull to associate actors to contract ( technicians in charge of contract, group in charge) and add these actors to notifications recipients list.

Actually, contract notifications can be send to profile or group, whatever the contract.

When using Ops tools such as Ansible to install/manage GLPI we can use the Console (`bin/console`) to perform some actions.

But the output (stdou or stderr) of those actions is dependent of the `language` setting (in `glpi_configs` SQL table).

For example when trying to reset an user's password, when language is set to en_GB the success message is

Reset password successful.

but, when language is fr_FR, message is:

Mot de passe modifié avec succès.

It's annoying for processing those outputs.

I suggest adding an option to the console that:

• (Variant A) Sets the outputs to be returned in plain English
• (Variant B) Set the specific language outputs should be returned in

Something like:

Variant A:

bin/console --no-language user:reset_password --password foo normal

Variant B:

bin/console --language=en_GB user:reset_password --password foo normal

Description

Currently, in GLPI 11, webhooks are triggered unconditionally on object creation or modification, based only on Itemtype and Event.

There is no supported way to filter webhook execution based on:

• Assigned group

• Entity

• Category

• Priority

• Actor (end user vs technician vs technical account)

This makes it impossible to implement common and critical use cases such as:

• Sending alerts only for tickets assigned to a specific group (e.g. Security / SOC)

• Preventing event loops when GLPI is integrated with external systems via API

• Reducing noise in external systems like Microsoft Teams, SIEMs, or SOAR platforms

Unlike email notifications, webhooks do not currently support any equivalent of criteria/conditions.

Concrete problem

Example scenario:

• A webhook is configured to send new tickets to Microsoft Teams

• The intention is to notify only the “Segurança” group

• In practice, every ticket triggers the webhook

• There is no way to restrict this to:

  • Assigned group = Segurança

  • Priority ≥ High

  • Entity = SOC

  • Actor = technician or technical account

This makes webhooks unusable for targeted operational workflows.

Related integration issue (API loops)

Additionally, when GLPI is integrated with external systems:

• An external system updates an object via the REST API (e.g. PATCH on Ticket or Asset)

• That update triggers the webhook

• The webhook sends data back to the external system

• This can create infinite event loops

There is currently no way to exclude:

• Changes made by specific users

• Changes made by API/technical accounts

• Changes initiated by external integrations

Proposed improvement

Introduce filtering conditions for webhooks, similar in spirit to notification criteria, allowing administrators to define when a webhook should fire.

Suggested filter dimensions:

• Assigned group

• Entity

• Category

• Priority / Urgency / Impact

• Actor (last modification author)

• Profile or account type (end user / technician / technical account)

These filters should apply to:

• Object creation

• Object update

• Both

Use cases

• Send Microsoft Teams alerts only for Security/SOC tickets

• Trigger SOAR playbooks only for high-severity incidents

• Prevent webhook loops in bi-directional API integrations

• Reduce alert fatigue in external tools

• Enable enterprise-grade integrations without custom plugins or database hacks

Benefits

• Makes webhooks usable for real operational workflows

• Prevents integration loops and noise

• Aligns webhook capabilities with notification logic

• Reduces need for unsupported database manipulation

• Improves GLPI’s position as an integration-friendly ITSM platform

Steps to reproduce current limitation

1. Create a webhook in GLPI

2. Configure it for Ticket → New

3. Create tickets for different groups

4. Observe that the webhook fires for all tickets, with no filtering option

5. No configuration option exists to restrict webhook execution by group, actor, or object attributes

Additional notes

Currently, the only workaround is:

• Creating external filtering logic outside GLPI

• Or modifying the database directly (unsupported)

• Or writing a custom plugin

All of these add unnecessary complexity for a common requirement.

Currently, it is not possible to view the history of reminder validations and follow-ups directly within the Validation tab of a ticket.

It would be useful for this tab to display a history, including the date of the last reminder, or alternatively, add a follow-up in the ticket to indicate that a reminder has been sent.
The displayed information should include at least:

• Date and time of each validation

• Email of the recipient

Permitir associar objetos a um chamado

It would be great to have a language selector directly on the login page.
Currently, users can only change their language after logging in.

Having a dropdown or buttons for installed languages would really help multilingual environments and first-time users.

Thanks

**Problem:**

In the legacy Formcreator plugin, it was possible to map GLPI TTR (time_to_resolve) variables as form fields. This functionality is currently missing in the native forms feature of GLPI 11.

**Use case:**

We need to display the TTR return date in forms, for example: "Return date: [time_to_resolve]", similar to how other GLPI fields like departure date can be mapped.

**Expected behavior:**

The native forms in GLPI 11 should allow mapping the time_to_resolve field as a form variable to:

- Display the TTR deadline

- Use it in calculations or conditional logic

- Reference it in form field mappings

**Current situation:**

The time_to_resolve field is not available as a mappable variable in native forms.

This would help maintain feature parity with Formcreator and support ticket management workflows requiring TTR date visibility.