[Feature] Establish the canonical Ticket service and Case escalation boundary #1

Open
opened 2026-07-29 15:44:36 +02:00 by zemion · 0 comments
Owner

Outcome

Provide canonical operational tickets without duplicating formal case records or helpdesk queue behavior.

Boundary

  • A Ticket is an operational request, incident, problem, or report with status, assignment, queue references, service targets, communication, and resolution.
  • A Case is an authoritative formal procedure with parties, evidence, decisions, statutory deadlines, retention, and record obligations.
  • Helpdesk supplies service profiles, queues, routing, escalation clocks, and channels over Tickets; it does not own a second ticket store.
  • Escalating a Ticket creates or links a Case through a stable external reference. Ticket and Case histories remain separately authoritative and linked rather than copied or silently transformed.

Acceptance criteria

  • Tenant-safe ticket CRUD, status lifecycle, assignment, participants, links, attachments, comments, and immutable history.
  • Optional queue/SLA capability hooks work with and without Helpdesk installed.
  • Optional Case escalation is idempotent and records source/target references, actor, timestamp, and outcome.
  • Permissions distinguish reading, reporting, triage, assignment, resolution, and administration.
  • Ticket search resources and change events can be announced without importing Search.
  • API and WebUI explain unavailable optional behavior instead of failing when Cases, Helpdesk, Projects, Wiki, Files, or Search are absent.
## Outcome Provide canonical operational tickets without duplicating formal case records or helpdesk queue behavior. ## Boundary - A **Ticket** is an operational request, incident, problem, or report with status, assignment, queue references, service targets, communication, and resolution. - A **Case** is an authoritative formal procedure with parties, evidence, decisions, statutory deadlines, retention, and record obligations. - Helpdesk supplies service profiles, queues, routing, escalation clocks, and channels over Tickets; it does not own a second ticket store. - Escalating a Ticket creates or links a Case through a stable external reference. Ticket and Case histories remain separately authoritative and linked rather than copied or silently transformed. ## Acceptance criteria - Tenant-safe ticket CRUD, status lifecycle, assignment, participants, links, attachments, comments, and immutable history. - Optional queue/SLA capability hooks work with and without Helpdesk installed. - Optional Case escalation is idempotent and records source/target references, actor, timestamp, and outcome. - Permissions distinguish reading, reporting, triage, assignment, resolution, and administration. - Ticket search resources and change events can be announced without importing Search. - API and WebUI explain unavailable optional behavior instead of failing when Cases, Helpdesk, Projects, Wiki, Files, or Search are absent.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-tickets#1
No description provided.