Only record BU reassignment in ivanti_finding_bu_history when the
previous_bu is a known managed BU (from EXPECTED_BUS). Findings that
were never in our sync cache show as UNKNOWN which provides no
actionable insight for asset movement tracking.
Closes#28
- Replace all STEAM branding with AEGIS (Advanced Engineering Group
Intelligence System) across login, header, nav drawer, manifest, and
browser title
- Add shield logo to login page, main header, and nav drawer
- Fix BU drift checker recording incorrect previous_bu values by
building a previousBuMap snapshot BEFORE the upsert/delete cycle
instead of querying the DB after rows are already gone
- Clean 526 bogus BU history entries generated by the broken logic
- Add docs and scripts from prior session
Add requireGroup('Admin', 'Leadership') as router-level middleware on all
VCL multi-vertical routes. Hide the CCP Metrics nav item from users not in
those groups and guard the page render in App.js with a redirect fallback.
The jest.roots config in package.json already restricts to backend/__tests__
and testPathIgnorePatterns excludes integration tests. The CLI path arg
was being interpreted as an additional ignore pattern, causing 0 matches.
Jest 30 default test discovery was finding frontend/src/**/*.test.js
and __tests__/ files when running from the project root. These need
react-scripts (CRA's Babel config) to parse ESM imports and JSX.
Added jest.roots to confine root-level Jest to backend tests only.
Frontend tests run separately via react-scripts test in test-frontend.
The cached node_modules was missing react-scripts babel config after
package-lock.json changed (remark-gfm addition). Tests failed with
'Cannot use import statement outside a module' and JSX parse errors.
Always run npm ci to ensure fresh dependencies match the lockfile.
Single-host PUT and bulk POST now extract and store the action_plan_id
from the Atlas API response in the local cache. Previously only a stub
with plan_type/commit_date was now the actual plan ID iscached
included so it can be referenced for updates/display without re-fetching
from Atlas.
Instead of blanket-marking managed BU hosts, now parses the Atlas API
response: if it returns a valid {active, inactive} structure, the host
is known. If it returns an error or 'not found' message (even with a
2xx status), the host is not known and won't show a badge.
This prevents the shield showing on hosts Atlas doesn't actually track,
while correctly showing it on hosts Atlas recognizes (with or without
plans).
A STEAM/ACCESS-ENG host with zero Atlas plans but tracked in Atlas
(like olt01k7) wasn't showing the amber shield because atlas_known
was only true when plans existed. Now managed BU hosts always get
atlas_known=true so the '0 plans' warning badge renders. Non-managed
BU hosts only show badge if Atlas actually has plan data for them.
The migrations-idempotency.integration.test.js requires a reachable
Postgres instance. The CI Docker container can't resolve the DATABASE_URL
hostname. Skip files matching 'integration' in the test-backend job.
remark-gfm@3.0.1 uses the unified v10 ecosystem but react-markdown@10
requires the unified v11 ecosystem. This caused 'this.getRole is not a
function' at runtime, blanking the KB viewer. Upgraded to remark-gfm@4
which is compatible.
Tables are a GitHub Flavored Markdown extension not supported by
react-markdown's default parser. Added remark-gfm plugin so tables,
strikethrough, and task lists render correctly in KB articles.
res.sendFile requires an absolute path. Article #7 was stored with a
relative path which caused the TypeError. Now both the content and
download endpoints resolve relative paths against the backend directory
before calling existsSync and sendFile.
Root cause: archived findings were never removed from ivanti_findings
(state='open'), so they appeared in previousFindings every sync, got
flagged as 'disappeared' every time, and were re-classified by the
drift checker — inflating the BU reassignment count to ~220/sync
when only a handful of genuinely new reassignments existed.
Fixes:
1. Filter out already-archived findings (archived >2h ago) before
passing to the drift checker — only genuinely new archives get
classified.
2. Delete disappeared findings from ivanti_findings after archive
detection so they don't pollute future syncs.
3. Cleaned up 536 stale findings that were accumulated in the table.
The archive activity bar chart should drop from ~500 to near-zero
on the next sync, with only genuinely new disappearances showing.
Brings the reference manual in line with the current codebase:
- Add CCP Metrics (VCL multi-vertical) feature section and full API reference
- Add CARD Asset Ownership feature section with tooltip, direct actions, queue actions
- Add Granite Loader Sheet feature section with CARD enrichment details
- Add Atlas Action Plans feature section with cache and badge rendering
- Add Finding Archive Tracking feature section with lifecycle states and anomaly detection
- Add Archer Template Library feature section with hierarchy and clone
- Add In-App Notifications feature section
- Add Feedback (GitLab integration) feature section with webhook lifecycle
- Add FP Workflow Submission feature section with lifecycle tracking
- Update Ivanti Queue to document all 6 workflow types (FP, Archer, CARD, GRANITE, DECOM, Remediate)
- Update Reporting section with Group by Host, CARD tooltip, multi-BU scope
- Update Jira section with flexible creation, consolidation modal, raw status
- Update Configuration with CARD, Atlas, GitLab, IVANTI_BU_FILTER, IVANTI_MANAGED_BUS vars
- Update Architecture tree with all routes, helpers, and components
- Update Database Schema with 15+ new tables
- Update Migrations section with all 46 migration files
- Update API Reference with Archer Templates, CARD, Atlas, VCL, Notifications, Feedback, Webhooks
- Add per-user settings (bu_teams, ivanti_identity) to auth section
The drift checker runs well before computeAnomalySummary writes to the
anomaly log (20+ minute gap in some syncs). The 10-minute window was
too narrow to capture the BU history records written during drift
checking. Widened to 60 minutes to reliably catch all records from
the same sync cycle.
The drift checker now inserts into ivanti_finding_bu_history when it
classifies archived findings as bu_reassignment. Previously only the
inline per-finding BU comparison (for findings still in sync) wrote
history records — archived findings that moved BU were counted in the
anomaly summary but had no detail records for the banner to display.
Also captures title and hostName from the Ivanti API response in the
drift checker for richer detail display, and adjusts the banner's
time window to 10 minutes before sync_timestamp to catch records
written during the drift check phase.
Three changes to the Jira Tickets page:
1. CVE ID and Vendor fields are now editable in the Edit Ticket modal
(previously disabled when editing). Backend PUT endpoint validates
CVE format and vendor length on update.
2. Completed tickets (Closed, Done, Resolved, etc.) are shown in a
separate collapsible section below the active tickets table. This
keeps the active work front-and-center.
3. Sync All skips completed tickets on subsequent syncs. When a ticket
first reaches a completed status via sync it gets updated normally,
but on future syncs it won't be included in the batch query to Jira.
Response now includes skippedCompleted count.
Atlas sync now distinguishes between hosts Atlas actively tracks (returned
plans, active or inactive) vs hosts with empty responses (not in Atlas).
Only atlas_known hosts show the badge — ACCESS-OPS hosts not covered by
Atlas won't show the amber '0' warning badge anymore.
Changes:
- Migration adds atlas_known BOOLEAN column to atlas_action_plans_cache
- Sync sets atlas_known = true only when Atlas returns at least one plan
- Metrics endpoint only counts atlas_known hosts in its aggregation
- Status endpoint includes atlas_known in response
- AtlasBadge renders nothing when atlas_known = false
- Bulk-create and refresh-cache upserts set atlas_known = true
- Backfill marks existing hosts with plans + managed BU hosts as known
Problem 1: Atlas sync was querying ALL host_ids from ivanti_findings
regardless of BU, writing 'no plan' entries for ACCESS-OPS hosts that
Atlas doesn't cover. Now the sync respects the user's active teams scope
(passed via query param) and falls back to IVANTI_MANAGED_BUS when no
scope is provided.
Problem 2: Atlas /metrics and /status endpoints returned unscoped data
from the full cache, so changing scope didn't update the Atlas Coverage
donut or badge counts. Both endpoints now accept a teams query param and
JOIN against ivanti_findings to scope results by BU.
Frontend changes:
- fetchAtlasStatus and fetchAtlasMetrics now pass teams param
- Atlas sync button passes active teams to the sync endpoint
- Scope change (adminScope) triggers Atlas data refresh
Also purged 6,461 polluted cache entries for non-managed BU hosts.
The AnomalyBanner BU reassignment row is now clickable, expanding to show
each affected finding with its host name and the team it moved from/to
(e.g. STEAM → PIES). The backend bu-changes endpoint now supports optional
since and limit query params to scope results to the relevant sync cycle.
Dropdown was opening automatically on render and not closing when clicking
elsewhere. Now opens only on focus/click, closes on blur, selection, Enter,
Escape, and Tab. Selected value persists in the input after selection.
Each user can now have ivanti_first_name and ivanti_last_name configured in
User Management. The workflow sync queries all configured Ivanti identities
and fetches workflows for each. The GET endpoint filters workflows to only
show those belonging to the logged-in user's Ivanti identity.
Users without an Ivanti identity see all workflows (admin fallback).
If no users have identities configured, falls back to IVANTI_FIRST_NAME/
IVANTI_LAST_NAME from .env for backward compatibility.
Changes:
- Migration adds ivanti_first_name, ivanti_last_name to users table
- Users route accepts and returns the new fields
- User Management UI has Ivanti Identity input fields
- Workflow sync iterates all configured user identities
- Workflow GET filters by logged-in user's identity
RESPONSIBLE_TEAM, EQUIP_STATUS, and EQUIPMENT_CLASS now show searchable
dropdown selectors in both the Bulk Defaults section and per-row inline
editing. Type to filter options, use arrow keys to navigate, Enter to select.
Picklist values extracted from docs/Team_Device Loader.xlsx reference sheets.
Per-row cells remain click-to-edit for all columns — picklist columns show
the SearchableSelect, free-text columns show a plain input.
When a CARD action fails with 'update_token not found', display a clear
message explaining the asset cannot be actioned via API, with a prominent
'Open in CARD (ID copied)' button that copies the host ID to clipboard and
opens card.charter.com/ipn-search in a new tab.
Applied to both CardDetailModal (reporting page) and CardActionModal (queue).
When the hostId fast path resolves via asset-search but the response lacks
an update_token, do a follow-up getOwner() call using the resolved _id to
fetch the token. Returns the rich owner data from asset-search merged with
the update_token from the owner endpoint.
The asset-search response wraps in { assets: [...] } and includes the full
owner record. Previously we tried to extract just an _id from the top level
(which didn't exist) and then made a separate getOwner() call that returned
empty data for IPv6 assets.
Now when hostId resolves via asset-search, we return the owner data directly
from the search response — no second API call needed. This fixes the tooltip
showing empty confirmed/unconfirmed for IPv6-only findings.
Findings with no IPv4 address now display Qualys IPv6 or Primary IPv6 as
fallback in the IP column, with a badge indicator:
- 'Q' (amber) = Qualys IPv6 from hostAdditionalDetails
- 'v6' (indigo) = Primary IPv6 from assetCustomAttributes
Priority: IPv4 > Qualys IPv6 > Primary IPv6
Backend changes:
- extractFinding now captures qualysIpv6 and primaryIpv6
- New extractQualysIpv6 helper parses hostAdditionalDetails
- upsertFindingsBatch stores both fields
- API response includes qualysIpv6 and primaryIpv6
- Migration adds qualys_ipv6 and primary_ipv6 columns
The Qualys IPv6 is preferred over Primary IPv6 because it resolves in CARD
(confirmed via testing with PMADEV-1).
The enrich-batch endpoint now accepts a host_ids array alongside ips.
When queue items have no IP address but have a host_id (from ivanti_findings),
the frontend sends host_ids and the backend resolves them via CARD asset-search.
Results include the resolved IP so it populates the IPV4_ADDRESS column.
The LoaderModal now carries _host_id from initialDevices through to the
enrich call.
The CARD asset-search endpoint returns the full enriched record (card_flags,
ivanti_assets, ncim_discovery, etc.) — same shape as team-assets. Before
falling back to the slow paginated team-assets loop, try each IP's host_id
via asset-search for direct single-call resolution.
Also registers the notifications table migration in run-all.js.
The migration file existed but was never registered in the POSTGRES_MIGRATIONS
array, so it never ran on production. The missing table caused 500 errors on
GET /api/notifications/count.
Integrate CARD's new v2 asset-search endpoint that accepts Ivanti Asset ID
integers directly, eliminating the slow suffix-guessing resolution flow.
Changes:
- Add searchByIvantiHostId() helper to cardApi.js
- Add GET /api/card/asset-search/:hostId endpoint
- Update CARD queue confirm/decline/redirect to try host_id fast path first
- Update owner-lookup to accept optional hostId query param for fast resolution
- Pass hostId through CardOwnerTooltip and ReportingPage for tooltip lookups
- Join ivanti_findings in todo queue GET to expose host_id on queue items
- Update CardActionModal to pass host_id for faster owner-lookup
openCreateJiraFromQueue only populated the description for Remediate
workflow items. Non-Remediate items got an empty string, while multi-select
worked because it used generateConsolidatedDescription via ConsolidationModal.
Now always includes finding info (vendor, title, CVEs, host/IP) in the
description for all workflow types. Remediate items still append their
notes below.
The older migration drops and re-adds the workflow_type CHECK constraint
but only included FP, Archer, CARD, GRANITE, DECOM. Once Remediate data
exists in the table, re-adding the old constraint fails. Added Remediate
to the constraint set so migrations can run idempotently in order.
- Single-item: openCreateJiraFromQueue fetches notes for Remediate items
and pre-fills the description with a Remediation Notes section
- Multi-item: ConsolidationModal fetches notes for all Remediate items
and appends them via appendRemediationNotes utility
Previously notes were only integrated in IvantiTodoQueuePage.js but
the actual Jira creation flow users interact with is in ReportingPage.js
QueuePanel and ConsolidationModal.
- Add remediationModalItem state to QueuePanel
- Render RemediationModal from QueuePanel for notes access
- Add Remediate color to wfColor mapping in renderQueueItem
- Add Remediate option to SelectionToolbar workflow type buttons
The Notes button and Remediate workflow option were only added to the
standalone IvantiTodoQueuePage but not the QueuePanel slide-out on the
Reporting Page, which is the primary interface for queue interaction.
RedirectModal had a hardcoded WORKFLOW_OPTIONS array that only included
FP, Archer, CARD, and GRANITE. Added DECOM and Remediate options, and
updated needsVendor check to require vendor for Remediate workflows.
- Add 'Remediate' as a valid workflow type (vendor-required, like FP/Archer)
- Create queue_remediation_notes table with FK cascade and 5000 char limit
- Add POST/GET /api/ivanti/todo-queue/:id/notes endpoints
- Include remediation_notes_count in queue item GET response
- Add RemediationModal component for viewing/adding notes
- Add notes count badge on Remediate queue items (purple #A855F7 theme)
- Add delete confirmation warning when removing items with notes
- Append remediation notes to Jira ticket descriptions
- Add property-based tests for all correctness properties
Adds a CategoryFilterBar with pill-shaped FilterChip components below the
metric health cards. Non-metric categories (Missing_AppID, Aging Vulns,
Missing_DF, etc.) are derived dynamically from device data and displayed
as color-coded filterable chips with device counts.
Unified filter state replaces the old metricFilter array, ensuring mutual
exclusivity between metric card filters and non-metric chip filters.
Includes 4 property-based tests validating derivation, filter predicate,
mutual exclusivity, and color resolution correctness.
Closes#26
Add per-metric stats and trend endpoints to vclMultiVertical.js. Refactor
CCPMetricsPage to use a unified MetricSelector that drives StatsBar, TrendChart,
DonutChart, and ForecastBurndownChart for the selected metric only. Remove the
separate Per-Metric Forecast Burndown section (now integrated). Fix trend query
double-counting when multiple uploads exist per vertical per month.
Closes#25
NoteCell now propagates saved notes back to the findings state via
onNoteSaved callback. This allows classifyFinding() to immediately
reclassify items from 'pending' to 'archer' when an EXC- note is
added, updating the Action Coverage donut without a page refresh.
Auto-populate description field when creating Jira tickets from the Archer
page with ticket metadata (EXC number, CVE, vendor, status, Archer URL).
Previously the description was always empty, requiring manual entry.
Includes security audit fixes for SQL injection prevention and input
validation in compliance, VCL multi-vertical, and CCP metrics routes.
Updates security audit tracker documentation.
Hover over any IP address in the findings table to see CARD ownership data
(confirmed/unconfirmed/candidate teams) in an interactive tooltip. Click
'Actions' to open a full modal for confirm/decline/redirect — no queue
item required.
Backend:
- Add direct /api/card/owner/:assetId/confirm|decline|redirect endpoints
- Add quick mode to resolveAssetId (CTEC only, 15s timeout) for tooltip use
- owner-lookup supports ?quick=1 query param with 504 on timeout
- getOwner accepts options for custom timeout
Frontend:
- New CardOwnerTooltip component (portal, hover bridge, cached results)
- New CardDetailModal for confirm/decline/redirect from tooltip
- IP cells show help cursor, trigger tooltip on 400ms hover
- Timeouts (504) not cached — retry on re-hover
- Teams fetch retries silently up to 3x on failure
- Redirect dropdowns show owner-data teams as fallback when teams API fails
Client-side grouping that collapses duplicate assets (same hostname + IP)
with multiple finding IDs into expandable host rows. Hosts with only one
finding remain as normal flat rows.
- Toggle button in toolbar switches between flat and grouped views
- Group header rows preserve column alignment (severity, host, IP in proper columns)
- Expanded sub-rows show full finding details with all interactions intact
- Selection, queue, hide, and workflow actions all work in both modes
- Groups sorted by highest severity; expand/collapse all controls included
Previously, redirecting a queue item required completing it first, which
created a duplicate entry. Now:
- Pending items: redirect updates workflow_type in place (no new row)
- Completed items: still creates a new pending item (legacy behavior)
- Redirect arrow now visible on all items, not just completed ones
- Frontend handles in-place updates by replacing the item in state
