User-based filtering for webhook activation
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
Contribution description
Description : Currently, when a webhook is configured in GLPI, it is triggered on every creation or modification of an object, regardless of who performs the action (end user, technician, or automated process). This becomes an issue when an external system updates an asset via the API (e.g., a PATCH request to add a reconciliation key): such an update triggers the webhook again, which sends a new event to the external system, potentially creating infinite event loops.
It would be very useful to add a filter based on the user who performed the last modification, in order to better control when the webhook is triggered.
Use cases:
- Prevent a webhook from being triggered if the modification is made by an end user.
- Trigger the webhook only if the modification is made by a technician or a technical account.
- Exclude specific profiles/actors from triggers to avoid unnecessary events or loops with external integrations.
Benefits:
- Prevent event loops when integrating with external systems.
- Reduce noise by avoiding unnecessary webhook calls.
- Provide more flexibility and granularity in integrations with third-party tools.
Steps to reproduce:
- Create a webhook in GLPI.
- Do not set any filter → every object modification generates an event.
- Go to the Filter tab and create a filter: currently, you can filter by last modification author, but only for notes.
- Missing feature: ability to filter by last modification author of the asset or object itself.
@cedric-anne Hello, I noticed that this issue has been removed from the list of pending tasks. Does this mean that the idea has been abandoned? I'm following up just to get a sense of its future and whether this is of interest to you, and if it's likely to be implemented in the short or medium term. Thank you in advance for your reply.
Hello @Yann843 imo, this is a feature request, I've flagged it as his so we can discuss it later for it's implementation in the next version of GLPI.