Tickets Domain Boundary

Purpose

Queue-oriented operational work: public or internal reports, service requests, incidents, problems, triage, routing, assignment, service-level tracking, and auditable resolution.

Owns

ticket identity, type, category, priority, state, and queue
public and internal intake profiles
reporter/requester and affected-object references
triage, routing, assignment, escalation, and service-level facts
discussion and resolution evidence references
stable links to tasks, projects, assets, facilities, and cases

Does Not Own

formal administrative case identity, parties, evidence, decisions, and retention
project plans, milestones, and portfolios
asset lifecycle management
workflow definitions and task execution

Integration Candidates

cases
projects
wiki
assets
facilities
forms_runtime
portal
files
workflow
tasks
mail
notifications
search

Ticket Versus Case

A ticket is the operational record of work entering and moving through a queue. It can be reported with incomplete information, assigned and reassigned, discussed, resolved, reopened, or linked to another work object. Its lifecycle answers: what needs attention, who owns the next action, and was it resolved?

A case is the authoritative procedural record for an administrative matter. It has formal parties, evidence, decisions, procedural deadlines, access rules, retention obligations, and a durable case history. Its lifecycle answers: what matter is being administered, under which procedure, and what formal outcome was reached?

Escalation does not convert or duplicate records. It creates an auditable relation containing the ticket reference, case reference, relation type, actor, timestamp, and optional handoff note. The ticket remains the intake and service history; the case becomes authoritative for the formal procedure.

The former Issue Reporting and Helpdesk concepts become ticket type, intake, queue, and policy profiles. They do not need separate persistence models.

Implemented Vertical Slice

Tickets is now a native authoritative operational store with:

tenant-isolated ticket identity and current state
replay-safe reporting and guarded revision mutations
distinct reporting, triage, assignment, resolution, and administration scopes
reporter, requester, assignee, and typed participant references
related-work and attachment references without copying owner-module content
internal and reporter-visible comments
immutable lifecycle history with actor, time, reason, revision, and request digest
soft deletion that removes ordinary discovery while retaining evidence
Search backfill, authorization rechecks, and event-driven index changes
bounded data-subject export with manual retention review

The /tickets WebUI and /api/v1/tickets routes expose this lifecycle. All mutations carry an expected revision and an idempotency key. Resolved and closed tickets require a resolution summary; reopening continues the same operational record.

Optional Providers

Core contracts keep integrations optional and implementation-independent:

tickets.routing may supply a queue, service target, and routing explanation. Without it, authorized users set queue and target manually.
tickets.case_escalation may create a replay-safe formal Case and return its stable reference. Without it, the ticket can still be resolved but the escalation action is unavailable.

Cases owns every created Case and its procedure. Helpdesk owns service profiles, queue semantics, routing, and escalation-clock policy. Tickets stores only the applied queue/target facts and the stable Case relation.

Remaining Provider Work

Helpdesk-owned configurable service profiles and routing provider
Cases-owned concrete tickets.case_escalation provider
connector-owned external service-desk transport and governed synchronization

3.8 KiB Raw Blame History