IncidentOps

Role: Sole developer · University project · IT355 · Year: 2026 · Status: technical implementation complete

tldr: A role-based incident response system built as a React client and a Spring Boot API. Responders work the queue, update incidents, add notes, and escalate. Administrators manage teams, services, and SLA policies.

Problem

During an incident the history ends up everywhere: chat threads, tickets, someone’s notes. IncidentOps keeps it in one record. Each incident has an owner, a managed service, a priority, a controlled status, an SLA state, notes, and manual escalations, and the timeline records who changed what and when.

Constraints

• One lifecycle across three layers. The UI, the API, and the database have to agree on which status transitions are legal. A client must not be able to skip a step.
• Permissions belong to the server. Responders and admins see different screens, but hiding an admin link in React is never the security boundary.
• SLA state is computed, not typed in. Deadlines come from policies that pair a managed service with an incident priority.

Decisions

• A feature-organized Spring Boot backend with a framework-free domain. The domain layer has no Spring, JPA, or HTTP types. Application services run the use cases, and PostgreSQL adapters persist users, services, incidents, events, policies, and escalations.
• Transitions are validated on the server. Notes, escalations, and status changes append to the timeline with the authenticated user as the actor.
• Spring Security with JWT enforces RESPONDER and ADMIN on every endpoint. Session data on the client stays in the active browser tab.
• SLA state comes from the API. The server reports whether acknowledgement and resolution are on track, breached, or met. The client shows it with text and a timestamp, not color alone.
• app -> features -> shared on the frontend, so dependencies only point one way.

Outcome

Full-stack verification used signed login requests, Spring Security, MockMvc, PostgreSQL Testcontainers, and the same REST contracts the frontend consumes. It covered incident creation, status changes, notes, escalation, role-based 403 responses, admin catalog operations, and transactional deletion. Browser checks at desktop, tablet, and mobile widths exercised keyboard focus, scrollable dialogs, API recovery, expired sessions, and the no-horizontal-overflow requirement.