79 lines
2.7 KiB
Markdown
79 lines
2.7 KiB
Markdown
# 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.
|