feat(incidents): case templates with tasks and timeline (#827)

* feat(incidents): phase 1 — case template schema + Pydantic models Adds the data model foundation for issue #792 (case templates with tasks and timeline). No behavior change yet — these tables are not referenced by any route or service in this commit. New SQLModels in app/incidents/models.py: - CaseTemplate: reusable investigation playbook scoped by customer_code (NULL = global) and source (NULL = any). Selection priority on case creation (Phase 3) is customer+source > customer > source > is_default. - CaseTemplateTask: definition rows on a template (title, description, guidelines, mandatory, order_index). - CaseTask: instance rows attached to a real Case. Snapshot-copied from CaseTemplateTask at template-application time; template_task_id is an informational soft link (editing a template does not mutate existing CaseTask rows). Custom analyst-added tasks have template_task_id NULL. Status field accepts TODO / DONE / NOT_NECESSARY (NOT_NECESSARY only valid when mandatory=False — enforced at service layer in Phase 3). - CaseEvent: append-only audit log of case mutations, used to power the timeline view. event_type and case_id are indexed for fast per-case timeline lookups. New Pydantic schemas in app/incidents/schema/case_templates.py covering Create/Update/Response variants for templates, template tasks, case tasks, and timeline events. Also includes: - CaseTaskStatus / CaseEventType enums - CaseCloseWarningResponse — payload returned when closing a case with incomplete mandatory tasks (soft-warning behavior, requires force=true to override). Wired in Phase 3. Decisions baked in (per design discussion on issue #792): - Soft warning on close (not hard block) - First-alert-wins template selection in v1 - Tasks are snapshots, not live references to template rows - Custom-task add available during investigation - Customer portal will be read-only on tasks and timeline (enforced in Phase 3 route guards and Phase 5 UI) - Template ownership scoped to admin/analyst (enforced in Phase 2 router) Next: run alembic autogenerate to produce the migration, then Phase 2 implements template CRUD routes. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(case-templates): add tables for case templates and related events * fix(incidents): phase 1 — widen case template text columns to TEXT The autogenerated migration 6ba5c2887ec5 materialized several free-form text columns as VARCHAR(255) because alembic's type inference doesn't pick up SQLModel's bare sa_column=Text reliably. This follow-up non-destructive ALTER migration widens them so analysts can paste multi-paragraph guidelines and log snippets / command output without truncation. Affected columns (all in incident_management_case_template*, incident_management_case_task*): - description (template, template_task, task) - guidelines (template_task, task) - evidence_comment (task) — most critical since the issue spec calls out "include evidence like logs, commands output" for this field. Tables are empty (introduced in 6ba5c2887ec5) so no data at risk. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(incidents): phase 2 — case template CRUD API (admin/analyst) Builds the API surface for managing case templates and their tasks. The entire router is gated on the admin or analyst scope; customers (customer_user scope) cannot view or modify templates. New service layer (app/incidents/services/case_templates.py): - create_template, list_templates, get_template, update_template, delete_template - add_template_task, update_template_task, delete_template_task, reorder_template_tasks - _enforce_single_default helper: when a template is marked is_default, any other default template within the same (customer_code, source) scope is automatically demoted so selection in Phase 3 stays unambiguous. - delete_template / delete_template_task explicitly NULL out the template_task_id soft FK on existing CaseTask snapshots so deleting a template doesn't clobber audit history on real cases. - Partial updates use Pydantic's __fields_set__ so callers can clear optional fields (description, customer_code, source) back to NULL. New router (app/incidents/routes/case_templates.py): - GET /incidents/case_templates — list with optional customer_code + source filters and an include_global flag (default true) so an admin UI can ask "what templates apply to customer X?" and get both customer-specific and global rows in one shot. - POST /incidents/case_templates — create, optionally with initial tasks - GET / PATCH / DELETE /incidents/case_templates/{id} - POST /incidents/case_templates/{id}/tasks — add task - PATCH / DELETE /incidents/case_templates/tasks/{task_id} - POST /incidents/case_templates/{id}/tasks/reorder — drag-and-drop reorder support for the future template editor UI. Wired into app/routers/incidents.py so the routes appear under the existing /api prefix alongside the rest of the incidents surface. Phase 3 will hook these templates into case creation (create_case_from_alert + manual create_case) and add the case-side task lifecycle endpoints with the soft-warning close behavior. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(incidents): phase 3 — case template integration + task lifecycle Wires case templates into case creation, exposes the case-side task lifecycle endpoints, and gates close-case on a soft warning when mandatory tasks are incomplete (per design discussion on issue #792). New service module (app/incidents/services/case_tasks.py): - pick_template_for_case(customer_code, source) — selection priority customer+source > customer-only > source-only > global default. Each step short-circuits on first match; ties within a step are broken by is_default desc, then created_at desc. - apply_template_to_case(case_id, template_id, actor) — snapshot-copies every CaseTemplateTask into a new CaseTask row. Snapshot semantics: editing the template later does NOT mutate already-applied tasks. Supports commit=False so it composes with the case-creation transaction. - auto_apply_template_for_new_case() — convenience wrapper used during create_case_from_alert (first-alert-wins source hint). - list_case_tasks / add_case_task / update_case_task / delete_case_task with NOT_NECESSARY-on-mandatory rejection and automatic completed_by/completed_at maintenance based on status transitions. - get_incomplete_mandatory_tasks() + build_close_warning_response() for the soft-warning gate. Integration into existing case creation flows (app/incidents/services/db_operations.py): - create_case_from_alert now accepts actor and template_id kwargs. When template_id is omitted, pick_template_for_case is called with alert.customer_code and alert.source. Template application happens before the commit so the case + initial tasks land atomically. - create_case (manual path) accepts the same kwargs. Without an alert source there's no auto-selection, but a template_id can be supplied explicitly. Analysts can also apply a template later via the manual-apply endpoint below. New routes on app/incidents/routes/db_operations.py: - GET /incidents/db_operations/case/{case_id}/tasks Read-only for customer_user; visible to admin/analyst as well. Customer access enforced via the existing customer_access_handler. - POST /incidents/db_operations/case/{case_id}/tasks Add a custom task mid-investigation. Admin/analyst only. - PATCH /incidents/db_operations/case/tasks/{task_id} Update status (TODO/DONE/NOT_NECESSARY) and/or evidence_comment. Admin/analyst only. NOT_NECESSARY rejected for mandatory tasks. - DELETE /incidents/db_operations/case/tasks/{task_id} Admin/analyst only. Allowed against template-derived tasks too. - POST /incidents/db_operations/case/{case_id}/apply-template/{template_id} Manual post-creation template application. Adds to existing tasks rather than replacing — analysts can layer multiple templates over an investigation (e.g., a Wazuh template plus an EDR template). Admin/analyst only. - /incidents/db_operations/case/from-alert and /case/create now accept an optional ?template_id= query param to override auto-selection. Soft-warning gate in PUT /incidents/db_operations/case/status: When closing a case, the route now calls get_incomplete_mandatory_tasks() and returns a CaseCloseWarningResponse (success=false, requires_confirmation=true, list of incomplete tasks) when any mandatory task is not DONE. The case is NOT closed; the caller re-submits with ?force=true to override. Response model is relaxed to None so the close path can return either the normal CaseOutResponse or the warning payload. Customer portal scope: - Read access on tasks: customer_user is included on the GET endpoint alongside admin/analyst. - Write paths (POST custom task, PATCH status, DELETE, apply-template) are restricted to admin and analyst scopes via Security() guards on each route. Customer users will see the tasks read-only in the Phase 5 UI. No frontend changes in this phase — Phase 5 will surface the new endpoints as Tasks and Timeline tabs on CaseDetails.vue. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(incidents): phase 4 — case timeline (CaseEvent) audit + GET endpoint Adds the unified audit log that powers the case timeline view. Every meaningful case mutation now writes one row to incident_management_case_event with an event_type, actor, timestamp, and a typed JSON payload. New service module (app/incidents/services/case_events.py): - emit_case_event() — append-only writer. Failures are logged but never raised; an audit-write failure must not break the underlying mutation. - list_case_events() — paginated, most-recent-first reader for the timeline endpoint. - payload_* convenience constructors (status_change, assignment, escalation, alert_link, alert_links_bulk, comment, template_applied, task) keep payload shapes consistent across emit sites. Audit emits wired into: Service-layer (lives in services/case_tasks.py): - apply_template_to_case: TEMPLATE_APPLIED + per-snapshotted-task TASK_ADDED - add_case_task (custom analyst-added task): TASK_ADDED with source='custom' - update_case_task: TASK_STATUS_CHANGED on a real status transition (no-op events are suppressed); TASK_COMMENTED when an evidence_comment is set in the same call. Both can fire in one PATCH and surface as two distinct timeline rows. Route-layer (lives in routes/db_operations.py — actor naturally available via current_user.username): - POST /case/create -> CASE_CREATED (source='manual') - POST /case/from-alert -> CASE_CREATED (source='from_alert') + ALERT_LINKED for the originating alert. template_applied / task_added come from the service layer (no double-emit). - POST /case/alert-link -> ALERT_LINKED - POST /case/alert-links -> single aggregated ALERT_LINKED carrying the list of alert_ids (avoids 50-row blasts for bulk attaches) - POST /case/alert-unlink -> ALERT_UNLINKED - PUT /case/status -> CASE_STATUS_CHANGED with from/to and a forced=true flag when the soft-warning was bypassed via ?force=true - PUT /case/assigned-to -> CASE_ASSIGNED with from/to assignee - PUT /case/escalated -> CASE_ESCALATED - POST /case/comment -> COMMENT_ADDED with a 140-char snippet preview New endpoint: - GET /incidents/db_operations/case/{case_id}/timeline Returns paginated CaseEventResponse rows ordered timestamp DESC. Visible to admin, analyst, and customer_user (read-only) so the customer portal in Phase 5 can show the timeline tab. Customer access is enforced via the existing customer_access_handler. No frontend yet — Phase 5 will surface this endpoint as the Timeline tab on CaseDetails.vue, alongside the Tasks tab. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(incidents): phase 4 — import CaseEventType in case_tasks service The Phase 4 audit emits added to apply_template_to_case, add_case_task, and update_case_task reference CaseEventType but the module-level import was missing, causing NameError at runtime when create_case_from_alert auto-applied a template. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(incidents): phase 5 — Tasks + Timeline tabs (analyst + customer portal) Surfaces the Phase 3/4 backend work in both Vue apps. Analysts get full read/write on Tasks; customers get a read-only view of Tasks and the case Timeline so they can see what the SOC team is doing on their cases. Analyst frontend (/frontend): - src/types/incidentManagement/caseTemplates.d.ts — TypeScript types for templates, template tasks, case tasks, case events, and the soft-warning response. - src/api/endpoints/incidentManagement/caseTemplates.ts — full API client covering template CRUD, template task CRUD + reorder, case task CRUD, manual apply-template, and timeline GET. Registered in the incidentManagement namespace index. - src/api/endpoints/incidentManagement/cases.ts — updateCaseStatus now accepts an optional `force` flag that maps to the backend's ?force=true query param used to bypass the soft warning. - src/components/incidentManagement/cases/CaseTasksList.vue — task UI with status dropdown (TODO/DONE/NOT_NECESSARY), evidence-comment textarea (auto-saved on blur), mandatory + custom badges, collapsible guidelines, completed-by/at footer, "Add task" modal, "Apply template" modal with a customer-scoped template picker, and delete-confirmation for custom tasks. - src/components/incidentManagement/cases/CaseTimelineFeed.vue — read-only chronological feed using n-timeline. Per-event-type icon, summary line, and detail renderer (comment snippet, alert id list). Falls back gracefully on unknown event_types so a future backend addition doesn't blank-render. - src/components/incidentManagement/cases/CaseDetails.vue — adds the Tasks and Timeline tab panes. Reads authStore.userRole and passes canEdit=false when the role is CustomerUser so any customer_user who lands on this view sees read-only. - src/components/incidentManagement/cases/CaseStatusSwitch.vue — intercepts the close-case path. When the backend returns requires_confirmation=true, shows a modal listing the incomplete mandatory tasks; "Close anyway" re-submits with force=true and records the override in the timeline. Cancel reverts the dropdown to the previous status without retriggering the watcher. Customer portal (/customer-portal): - src/types/caseTemplates.ts — read-only mirror of the relevant types. - src/api/endpoints/caseTemplates.ts — only GET endpoints exposed (getCaseTasks, getCaseTimeline). Backend write paths return 403 for customer_user scope, so this client intentionally omits the mutation surface entirely. - src/components/cases/CaseDetails/CaseTasks.vue — read-only task panel showing status, evidence notes, completion attribution, and guidelines. No interactive controls. - src/components/cases/CaseDetails/CaseTimeline.vue — read-only audit feed mirroring the analyst version but without write affordances. - src/components/cases/CaseDetails/CaseDetails.vue — wires the two new tab panes in. No backend changes in this phase. Phase 6 will add the template management view (CRUD UI) plus a CaseCreationForm template picker and the user docs. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * feat(incidents): phase 6 — template management UI + creation picker + docs Closes #792 Final phase: surfaces the case template Phase 1-2 backend work in the analyst UI so admins/analysts can author and curate templates without hand-rolling JSON, and gives the manual case-creation flow a way to opt into a specific template. Template management view (admin / analyst only): - src/views/incidentManagement/CaseTemplates.vue — page shell. - src/components/incidentManagement/caseTemplates/CaseTemplatesList.vue — n-data-table with name+default badge, scope (customer/source), task counts (total + mandatory), updated_at, edit/delete actions. Filters by customer_code / source / include_global, plus a free-text search across name/description/customer/source. Refresh button. Confirmation dialog on delete that explicitly notes CaseTask snapshots are preserved on real cases. - src/components/incidentManagement/caseTemplates/CaseTemplateEditor.vue — full template + tasks editor in a modal. * Metadata form (name, description, customer_code, source, is_default). * Inline task list editor: add task button, per-task title / description / guidelines / mandatory toggle, up/down reorder buttons, delete button. * Streaming saves: when editing a persisted template, task add/edit/delete/reorder hit the backend immediately so the user can iterate without an explicit "save tasks" round-trip. The metadata form still requires Save to commit. * Create flow batches: tasks are submitted alongside the CaseTemplateCreate payload so the backend creates them in one transaction. - src/router/index.ts — adds /incident-management/case-templates route with meta.roles=[Admin, Analyst]. Imports AuthUserRole alongside RouteRole. - src/app-layouts/common/Navbar/items.tsx — adds the "Case Templates" child item under Incident Management. Route-level role gating handles 403 if a customer_user clicks through. CaseCreationForm template picker: - src/components/incidentManagement/cases/CaseCreationForm.vue — optional template select below the customer field. Picker is customer-scoped (refetches when customer_code changes) and always includes global templates. Clears the selection when the customer changes so a stale ACME-only template can't accidentally apply to Customer B's case. - src/api/endpoints/incidentManagement/cases.ts — createCase and createCaseFromAlert now accept a params object so the picker can pass template_id as a query param without breaking existing callers. Docs: - docs/user/ui/incident-case-templates.md — full operator guide: scoping fields, matching priority (with first-alert-wins note), authoring workflow, snapshot semantics, soft-warning behavior, timeline coverage, three worked examples (Wazuh global default, customer-specific override, EDR addon), permissions matrix, and common gotchas. - mkdocs.yml — adds the new doc under Incident Management nav. That completes the case-template feature: backend tables + APIs (Phases 1-4), analyst Tasks/Timeline tabs + customer-portal read-only views (Phase 5), and the management UI + manual picker + docs (this phase). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * docs(case-templates): add "How to use templates well" best-practices section Extends the case-templates operator doc with a practical guide on running the feature day-to-day. The original doc covered the mechanics; this commit covers the judgment calls operators face once they have the mechanics down. New sections in incident-case-templates.md: - Start with one global default per source, then layer (anti-overload guidance for teams just adopting templates). - Mandatory discipline: when a task should and shouldn't be marked mandatory, with an explicit anti-pattern callout for "everything is mandatory" and what that does to the soft-warning signal. - Use guidelines as the runbook quick-reference: what to put in the guidelines field, with a good vs bad example. - Evidence comments as the compliance trail: what belongs there and what doesn't (especially given customer-portal visibility). - Reorder for natural investigation flow: a 6-step sequencing pattern (triage → identify → investigate → decide → act → close). - The two-template pattern (source + capability) for cross-template workflows like Wazuh + EDR. - Custom-task adds as a feedback loop: how to use task_added events with source="custom" to drive template iteration. - Timeline as compliance + handoff tool: how to read the timeline as case narrative and what it answers for audits / shift changes. - Customer-portal as transparency tool: deliberate use of read-only visibility to communicate effort and substance, with explicit guidance on what to keep out of evidence comments. - Quarterly template review checklist (close-with-force rate, custom task patterns, NOT_NECESSARY hot-spots, wiki link rot, etc.). Also adds a Case Templates link to the Incident Management overview page so the template feature is discoverable from the menu landing. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * chore(deps): update frontend dependencies * style(incidents): format api calls and imports * style(ai-analyst): format metric tile * style(auth): remove unused nextTick import * style(snapshots): format schedule form * style(cases): format case management components * style(cases): format case template components * refactor(cases): split case task list components * refactor(cases): extract task creation form * refactor(cases): extract apply template form * refactor(cases): add debounced saving to task items * refactor(cases): update timeline feed UI and dates * refactor(cases): use CardEntity for task items * refactor(cases): simplify done task count * refactor(cases): use secondary style for templates * refactor(cases): refine status switch component * refactor(cases): refine task item layout * style(auth): add gap to totp form actions * refactor(cases): use CardEntity for task items * refactor(cases): refine timeline UI and dates * refactor(cases): refine template selection UI * refactor(cases): improve template list filters * refactor(cases): refine template list layout * refactor(cases): use JSX in template list * refactor(cases): refine template list UI * refactor(cases): use data table loading prop * refactor(cases): use selects in template editor * refactor(cases): show task saving indicators * precommit-fixes Co-authored-by: Copilot <copilot@github.com> * chore(version): update CURRENT_VERSION to 0.1.60 --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: Davide Di Modica <webmaster.ddm@gmail.com> Co-authored-by: Copilot <copilot@github.com>