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.

Seed State

The current repository state is intentionally small:

module manifest and entry point
tenant-level permission definitions
manager and viewer role templates
documentation topic describing the module boundary
Gitea issue workflow templates
manifest contract test

No runtime API, database model, migration, WebUI route, or navigation item is registered yet. The first implementation slice should preserve the boundary above and only add user-visible surfaces once the workflow model is clear.

First Implementation Slice

Define ticket identity, intake profiles, queues, triage, assignment, resolution, and stable escalation links to cases.

2.7 KiB Raw Permalink Blame History