Repository navigation
Native Ticket Details
Open a ticket from Home or My Work. Its linked infrastructure appears with the record, followed by expandable information sections.
| View | Information |
|---|---|
| Configuration items and services | Primary and affected CIs, impacted services, class, environment, status, IP, hardware and physical location |
| Rack placement | Site, rack, U position, height and face; open the exact rack with the linked device highlighted |
| Record information | Caller, contact type, impact, urgency, service offering, notification preference and permitted tracking fields |
| Governance and reviews | Change plans, schedule, risk, approval revision, post-implementation and major-incident reviews |
| Operational evidence | SLAs, approval decisions, work tasks, related records, incident status updates and event history |
Comments and attachments retain their existing dedicated views. Expand a section to read its fields. Blank values mean Not recorded; a CI without a rack remains visible. A missing or forbidden relationship is never inferred from a device name.
GET /api/v1/tickets/{number} includes configuration_items and versioned details. Ticket lists remain compact. GET /api/v1/tickets/{number}/details returns the detail document alone; /api/v1/mobile/tickets/{number}/details is an alias. The documented OpenAPI schemas describe each section, entry, field and rack location.
GET /api/v1/mobile/tickets/{number}/rack-placements supplies the native rack preview and direct destination. It requires a mobile session, tickets:read, an agent role and visibility of the ticket. It returns primary CIs first, deduplicates devices, and preserves unknown U positions.
All routes enforce ticket visibility, tenant ownership and CI-class read permissions. Requesters receive public record information, service commitments and visible related records; internal history, governance and topology remain staff information. Related records are checked independently. The iOS state picker uses the server's allowed transitions and disables saving for read-only tickets.
Older ticket responses still decode. Their missing detail capability is explained in the app. New detail contracts remain present after an incident is created or a ticket is updated.
Backend regression and MicroK8s acceptance evidence is recorded with the implementation plan. Simulator builds and decoder checks do not establish physical-device acceptance.
Ticket comments from GET /api/v1/tickets/{number}/comments include deleted_attachments: filename, reason, deletion time and actor. The original comment body stays intact.
New comments expose source_platform (iOS for an authenticated iOS mobile session) and ai_assisted separately. Event history exposes a Source field. Web request headers alone cannot set a mobile origin.