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.

OWASP recommends adding a Clear-Site-Data header to logout pages, to suggest browsers should clear the site's data. See https://owasp.org/www-project-secure-headers/#clear-site-data

This could be implemented pretty easily in `front/logout.php` by adding a single line:

header('Clear-Site-Data: "cache", "cookies", "storage"');

(We'll be doing this modification on our local install due to a pentest report which recommends it, and apache makes adding the header difficult due to the 302 redirect)

Problem description

GLPI network discovery and SNMP inventory currently rely on a fixed, generic set of OID definitions and parsing logic maintained in core.

While this works well for common switches and printers, it does not scale well to modern environments that contain many other network-connected, non-agent devices, such as:

• IP cameras

• Access control / biometric devices

• Wireless access points

• IoT / OT equipment

• Vendor-specific or rebranded hardware

As a result:

• Devices are often detected but poorly identified

• Vendor-specific SNMP data is not parsed

• Administrators cannot extend or customize discovery behavior

• Community knowledge about device SNMP structures cannot be reused

Proposed enhancement (scoped MVP)

Introduce extensible, vendor-based discovery profiles that allow GLPI to apply targeted SNMP queries after basic device identification, without changing the existing discovery workflow.

This proposal is intentionally limited to enhancing discovery data, not automatic asset creation.

Minimal viable design

1. Vendor identification hints (non-authoritative)

During discovery, GLPI may already collect:

• MAC address

• sysObjectID

• sysDescr

Use these existing values to derive a vendor hint (best-effort), for example:

• MAC OUI lookup

• sysObjectID prefix match

• Simple sysDescr pattern match

No single signal must be authoritative.

2. Discovery profiles (read-only definitions)

A Discovery Profile defines:

• One or more vendor/device identification hints

• A list of additional SNMP OIDs to query

• Optional parsing rules for returned values

Profiles:

• Are applied only if identification hints match

• Fall back safely to generic discovery if unsupported

• Do not change existing SNMP logic unless explicitly matched

3. Extensibility (initially admin-managed)

For initial scope, profiles could be:

• Stored as configuration files

• Loaded at discovery time

• Enabled/disabled by administrators

This avoids:

• UI complexity

• Security concerns

• Runtime plugin execution

Out of scope (explicitly)

To keep this proposal feasible, the following are not requested:

• Automatic asset creation or conversion

• Changes to the asset model

• Replacement of existing SNMP discovery logic

• Vendor-specific UI elements

• Complex fingerprinting heuristics

Benefits

• Improved identification of non-agent devices

• Richer SNMP data for supported vendors

• Reduced number of poorly classified unmanaged devices

• Community-contributed discovery knowledge becomes reusable

• Future-proof foundation for modern networks

Why this is safe

• Discovery remains non-destructive

• Profiles are opt-in and additive

• Generic discovery behavior remains unchanged

• No assumptions or guesses are required

Example use cases

• IP cameras exposing limited but useful SNMP data

• Wireless access points without a central controller

• Access control devices reporting status via vendor OIDs

• Network devices using non-standard MIB layouts

Closing notes

This proposal aims to extend GLPI’s discovery capabilities without increasing risk or complexity in the core workflow.

By introducing a small, controlled abstraction layer, GLPI can better adapt to modern network environments while remaining backward-compatible and conservative by default.

Problem description

GLPI currently allows converting unmanaged devices only into a limited set of core asset types (Computer, Network Equipment, Printer, Phone) via the Convert feature.

However, modern environments contain a rapidly growing number of business-owned, network-connected devices that:

• Cannot run agents

• Are not well represented by existing core asset types

• Still must be inventoried and managed

Examples include (non-exhaustive):

• IP cameras

• Biometric readers

• Door/access controllers

• Wireless access points

• IoT / OT devices

• Environmental sensors

• AV equipment

At present, administrators must:

• Manually create custom asset types

• Manually recreate assets discovered as unmanaged devices

• Manually correlate MAC/IP/ports after the fact

This results in:

• Duplicate effort

• Inconsistent workflows (Convert exists for some types but not others)

• Increased risk of data inconsistency

• Poor scalability in environments with large numbers of non-agent devices

Proposed solution

Introduce a generic, user-defined conversion framework that allows administrators to explicitly define how unmanaged device discovery data can be converted into custom asset types, while preserving GLPI’s existing data-integrity guarantees.

High-level concept

1. Administrator creates a custom asset type (e.g. Camera)

2. Administrator defines a conversion template that maps:

   • Unmanaged device fields → asset fields
     (e.g. MAC, IP, name, network port, location)

3. GLPI validates the mapping:

   • Required fields present

   • No ambiguous or invalid mappings

4. Only after validation, GLPI enables:

   • Convert → <Custom Asset Type>
     for unmanaged devices matching the mapping

Conversion remains:

• Explicit

• Opt-in

• Deterministic

• Auditable

No automatic or heuristic guessing is introduced.

Why this is safe

This approach maintains the same (or stronger) safeguards as the existing Convert feature:

• No implicit field guessing

• No automatic promotion of discovery data

• Explicit administrator approval via mappings

• Required-field enforcement before conversion

• Clear lineage from discovery → inventory

In many cases, this would be safer than today’s manual recreation, which occurs outside GLPI’s visibility.

Use cases

• IP cameras discovered via network scans

• Access control and biometric devices

• Wireless access points not managed by a controller

• IoT / OT devices in enterprise environments

• Any business-owned network-connected device that cannot run an agent

Benefits

• Reduces manual inventory effort

• Improves CMDB accuracy and consistency

• Scales to modern network environments

• Avoids misuse of existing core asset types

• Aligns GLPI with current enterprise CMDB practices

Additional notes

This proposal is intentionally generic and extensible, not specific to any device category.
It replaces hard-coded conversion logic with a controlled framework while remaining fully backward-compatible with existing Convert functionality.

In ITSM / Release Management workflows, it is necessary to:

• Create a Release from a form

• Standardize release creation

• Avoid manual creation in Change / Project modules

The glpi-agent does not support notifying relevant personnel through webhooks only when CPU, memory, or hard disk changes