[Feature suggestion] Time-based ticket visibility per profile (NIS2 / least-privilege)

[sk-123-beep]

Problem

Ticket visibility in GLPI is currently controlled only by profile rights (see my tickets / group tickets / all tickets / assigned) and by entity.

There is no way to limit how far back in time a profile or group can see tickets.

In regard to the European NIS2 directive and its national transpositions, which require organizations to implement access control policies based on least privilege and need-to-know (art. 21), access to ticket history should be limited to what each person needs for their work.

For example, a newly arrived technician in an organization (in our case, an MSP) should not be able to consult tickets older than a defined age (e.g. 1 year) within the entities they are assigned to, while "senior" technicians keep access to the full history.

Risk scenario: a technician joins the company and, from day one, has access to the complete ticket history of every client entity they are assigned to. Years of tickets often contain sensitive information: infrastructure details, network diagrams, security incident reports, personal data. A malicious newcomer, or an attacker using that newcomer's compromised account, could export this entire history through the search engine (or the API) within minutes, long before any trust has been established or any anomaly detected. With an age limit on the profile, the exposure would be reduced to the recent tickets actually needed for daily work, which greatly limits the impact of such an incident.

Current workaround and limit

• Transferring old tickets to an "archive" entity: works as a real access boundary but will affect linked items.

Proposed solution

Add an optional setting on the profile, for example:
"Maximum age of visible tickets: [unlimited | N days/months/years]"

• Reference date configurable or fixed: opening date, closing date or last update.
• Applied in the search engine, in direct access to the ticket form,
  and in the API.
• Possibly only applied to closed/solved tickets, so that long-running
  open tickets remain visible.
• Ideally also available for Changes and Problems.