a61d254ff9
New specs: archer-template-library, ccp-metrics-view-restructure, compliance-list-stale-after-sidebar-edit, compliance-metric-estimated-resolution-date, compliance-remediation-display-fix, flexible-jira-ticket-creation, forecast-burndown-chart, granite-loader-export, ivanti-queue-clear-completed-fix, multi-item-jira-ticket, queue-collapsible-sections, vendor-issue-type-dropdown New steering: archer-template-gen.md Updated: migration-registration-check hook, remediation-plan-history spec, gitlab-workflow, tech, versioning steering files
3.9 KiB
Bugfix Requirements Document
Introduction
The compliance main table (CompliancePage.js) always displays "—" for the Resolution Date and Remediation Plan columns, even after a user edits these fields in the ComplianceDetailPanel. The detail panel correctly saves and reads per-device metadata via PATCH /api/compliance/items/:hostname/metadata and GET /api/compliance/items/:hostname, but the list endpoint GET /api/compliance/items?team=X&status=Y omits resolution_date and remediation_plan from its SELECT query, and the groupByHostname() helper does not propagate these fields into the device objects returned to the frontend.
Bug Analysis
Current Behavior (Defect)
1.1 WHEN the main compliance table fetches devices via GET /api/compliance/items?team=X&status=Y THEN the system does not include resolution_date or remediation_plan in the SQL SELECT clause, so these columns are absent from the query result rows.
1.2 WHEN groupByHostname() constructs per-device objects from the query rows THEN the system does not include resolution_date or remediation_plan fields in the device objects, resulting in undefined values on the frontend.
1.3 WHEN the frontend renders the Resolution Date column using device.resolution_date || '—' THEN the system always displays "—" because the field is undefined.
1.4 WHEN the frontend renders the Remediation Plan column using truncateText(device.remediation_plan) THEN the system always displays "—" because the field is undefined.
Expected Behavior (Correct)
2.1 WHEN the main compliance table fetches devices via GET /api/compliance/items?team=X&status=Y THEN the system SHALL include ci.resolution_date and ci.remediation_plan in the SQL SELECT clause so these values are present in the query result rows.
2.2 WHEN groupByHostname() constructs per-device objects from the query rows THEN the system SHALL include resolution_date and remediation_plan fields in each device object, aggregated as the first non-null value encountered across the hostname's metric rows (or null if all are null).
2.3 WHEN the frontend renders the Resolution Date column and device.resolution_date contains a valid date string THEN the system SHALL display that date value instead of "—".
2.4 WHEN the frontend renders the Remediation Plan column and device.remediation_plan contains a non-empty string THEN the system SHALL display the truncated plan text instead of "—".
Unchanged Behavior (Regression Prevention)
3.1 WHEN the detail panel saves metadata via PATCH /api/compliance/items/:hostname/metadata THEN the system SHALL CONTINUE TO persist resolution_date and remediation_plan to the compliance_items table correctly.
3.2 WHEN the detail panel reads a single device via GET /api/compliance/items/:hostname THEN the system SHALL CONTINUE TO return resolution_date and remediation_plan for that device's metrics.
3.3 WHEN groupByHostname() processes rows for devices that have no resolution_date or remediation_plan set (all null) THEN the system SHALL CONTINUE TO return null for those fields, and the frontend SHALL CONTINUE TO display "—".
3.4 WHEN the VCL reporting endpoints read resolution_date from compliance_items for burndown forecasts THEN the system SHALL CONTINUE TO function identically, as this fix only affects the list endpoint's SELECT and the grouping helper.
3.5 WHEN the main compliance table displays hostname, IP address, device type, failing metrics, and seen count THEN the system SHALL CONTINUE TO display these fields correctly without any change in behavior.
3.6 WHEN per-metric metadata scoping is used (different resolution_date values per metric on the same hostname) THEN the system SHALL CONTINUE TO store per-metric values correctly; the list endpoint SHALL aggregate by selecting the first non-null value across the hostname's metrics for display purposes.