Feature request: target the requester's **personal manager** (users_id_supervisor) in Notifications and Business Rules

[Smiley-k]

Version

11.0.8

---

Feature request: target the requester's personal manager (users_id_supervisor) in Notifications and Business Rules

Summary

GLPI stores a "Manager" (Руководитель) on each User card (glpi_users.users_id_supervisor), and this field is filled in and actively used. However, neither Notifications nor Business Rules can target that specific person:

• Notification recipients for ITIL objects only support group managers: Requester group manager, Observer group manager, Manager of the group in charge (and their "except manager users" counterparts). There is no "Requester's manager" recipient (the personal supervisor of the requester user).
• Business Rules for Tickets expose 0 criteria based on the supervisor (checked all 45 criteria) and only 3 supervisor-related actions, all of type add_validation (approval requests):
  • responsible_id_validate — "Send an approval request - Supervisor of the requester"
  • users_id_validate_requester_supervisor — "Send an approval request to requester group manager"
  • users_id_validate_assign_supervisor — "Send an approval request to technician group manager"

There is no Business Rule action to notify the requester's manager (e.g., on ticket creation), and no criterion to branch on the requester's supervisor.

Why a system-wide setting is NOT an acceptable workaround

The only way to get "managers involved" today is to enable manager-type recipients/actions globally (e.g., notify all group managers). We deliberately do not want to do this, because:

1. Notification spam / alert fatigue. With a system-wide setting, every group manager receives notifications for every ticket in every group — including tickets from departments they have nothing to do with. In an organisation with many groups, this floods managers with irrelevant mail and trains them to ignore notifications entirely.
2. Wrong audience. The business need is targeted: only the direct manager of the specific requester should be informed (e.g., "employee X opened a ticket about Y"). Group managers are often not the requester's personal manager (users_id_supervisor is the actual hierarchy link).
3. Cross-department noise. Group manager targets follow group membership, not the reporting line. The personal manager may not even belong to the requester's group.
4. Privacy / least privilege. Broadcasting ticket details to all managers who happen to manage any group exposes ticket content to people who should not see it.

This is a real regression vs. the legacy engine where the supervisor field was at least present in the data model (search option supervisor, field 60) and reachable via apirest.php.

Expected behavior

• Notifications: add a recipient target "Requester's manager" in NotificationTargetCommonITILObject that resolves users_id_supervisor of the requester user (mirroring how SUPERVISOR_REQUESTER_GROUP resolves the group manager).
• Business Rules: add an action to notify the requester's manager (e.g., send notification - Requester's manager) and/or a criterion based on the requester's supervisor, so a rule can target the personal manager without affecting all group managers system-wide.

Steps to reproduce

1. On GLPI 11.0.x, set a Manager on a user (User form → "Manager").
2. Create a ticket with that user as requester.
3. Configure a Notification or Business Rule for the "new ticket" event.
4. Observe the recipient/action lists: only group manager options exist; the requester's personal manager cannot be selected.

Environment

• GLPI version: 11.0.8
• Verified against live instance: Business Rules (/Rule/Collection/Ticket/CriteriaCriteria, /ActionField) — 45 criteria / 45 actions, no supervisor criterion, no notify-manager action.
• Notification targets checked in src/NotificationTargetCommonITILObject.php (11.0 branch).

Related

• #25229 — users_id_supervisor not exposed in High-Level API User schema (API-side counterpart; PR #25230 adds supervisor to User schema for HL API v2.4).