Add filtering conditions for Webhook triggers (group, actor, object attributes)

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.