Conversation
…3 treatment plan documents (CS-727) (#3493) * feat(risks): risk acceptance events + ISMS 6.1.2/6.1.3 document types (API) - RiskAcceptance append-only model (risk XOR vendor subject, frozen residual rating + acceptor name, CHECK constraint in migration) - record/list acceptance endpoints on risks + vendors (stale computed against live residual rating; no update/delete - immutable) - server-side risk-level mirror of apps/app risk-score.ts - 11th ISMS doc type risk_assessment_methodology (6.1.2): fully templated narrative incl. 5-point scales, computed 5x5 color matrix, acceptance thresholds, treatment options; seeded via ensure-setup heal - 12th ISMS doc type risk_treatment_plan (6.1.3): rendered live from Risk Register + vendors with per-row acceptance state, drift via riskTreatmentFingerprint, owner submit gate, page payload endpoint - renderers: optional per-cell fills for the 6.1.2 risk matrix * feat(app): acceptance UI + ISMS pages for 6.1.2/6.1.3 documents - ResidualAcceptanceCard + RecordAcceptanceDialog on risk and vendor treatment-plan tabs (record acceptance, stale badge, history) - useAcceptances hook (list + record; append-only) - RiskMethodologyClient/Form: editable templated narrative with fixed scale labels + read-only computed 5x5 matrix preview - RiskTreatmentPlanClient: live preview of org + supplier risk tables with acceptance badges, server-computed submit blockers - isms-types: new union members, meta, slugs, narrative + RTP types * test(risks): acceptance service/controller + 6.1.2/6.1.3 builders and drift coverage * fix(isms): floor pdf table columns at header word width Wide tables (the 9-column Risk Treatment Plan) squeezed columns below their header's width, breaking words mid-word ("Acceptanc/e"). * fix(risks): pre-existing RiskCategory typo in controller spec (operational -> operations) * chore: cs-727 plan + review notes * fix(risks): address review round 1 on CS-727 - level labels now use the score-based bands everywhere in the feature (acceptances, both documents, matrix preview) — matches RiskScoreBadge / TreatmentHero instead of the raw getRiskLevel bands they disagree with - RTP tables gain the ticket's per-row Status column using the reference document's abbreviated headers (Cat./Inh/Treat./Res, defined in the cell key); UI table moves Status after Acceptance - restricted roles: record-acceptance now enforces the same assignment gate as the list/read endpoints (access callback run on the loaded risk before any write) - acceptance endpoints extracted to RiskAcceptancesController / VendorAcceptancesController (both host files back under 300 lines) - acceptance queries org-scoped as defense-in-depth; 403 responses documented; isms riskTreatment endpoint gains controller + permission-metadata specs - RTP drift fingerprint: includes rendered owner display values (rename = drift) and ignores acceptances on archived risks (no false drift) - RTP preview revalidates on Generate (new IsmsDocumentShell onGenerated) - methodology form trims whitespace-only input and surfaces per-row errors on the labelled-list fields - acceptance card derives stale client-side from frozen vs live rating (no stale-blind cached list); table rows keyed by index * fix(app): announce methodology and acceptance validation errors to assistive tech --------- Co-authored-by: Tofik Hasanov <annexcies@gmail.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
…s intune device (#3495) ## Problem A device migrated from Intune integration to Comp AI endpoint agent shows as "missing" in the People tab (Overview) but displays correctly in the Device tab. The customer reported the device was initially imported via Intune, Intune was disconnected, the endpoint agent was installed and confirmed working, but the following morning the device appeared as missing in the People tab only. ## Root cause When a device migrates from Intune to the endpoint agent (same serial + member), the agent adoption flow in `registerWithSerial` (device-registration.helpers.ts) and `checkIn` (device-agent-auth.service.ts) updates the existing Device row but never sets the `source` field. The row retains `source='integration'` while carrying live agent compliance data. The People tab rollup query filters to only `source='device_agent'` devices (compute-device-status-map.ts:41), so the device is excluded and the member renders as "not-installed" → "Missing". The Device tab lists all devices regardless of source, so it remains visible there. This asymmetry matches the customer's report. ## Fix Set `source: 'device_agent'` in the agent's adopt and check-in update paths. The change is localized to two code paths (registerWithSerial and checkIn) and backward-compatible: agent rows are already sourced correctly; the Intune sync already refuses to overwrite non-integration serials, so no race condition. No schema change required. ## Explicitly NOT touched - Offboarding date handling (the customer's mention of an incorrect offboardDate is a separate minor issue and does not affect device display logic, which gates on deactivated/isActive flags) - The "unable to clear offboardDate" UI issue in EmployeeDetails.tsx (separate bug) - Device deactivation or member lifecycle logic ## Verification - Added regression test asserting that when a device transitions from integration source to agent source via checkIn, the source field is updated to 'device_agent' and the device appears in the People-tab rollup query result - Existing device-registration and device-agent-auth unit tests pass locally ✅
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
All reported issues were addressed
Tip: instead of fixing issues one by one fix them all with cubic
Re-trigger cubic
…ft baseline, error surfacing) (#3497) * fix(risks): cs-727 deploy-review fixes - acceptance create runs in a transaction with a FOR UPDATE row-lock on the subject, so a concurrent residual edit can no longer produce an acceptance frozen at a superseded rating - approve() collects the drift baseline INSIDE the approval transaction (collectPlatformData gained an optional client), so a just-approved document can't immediately read as stale - useAcceptances surfaces ApiResponse.error (apiClient never throws); the acceptance card renders an error + retry state instead of misreporting a failed load as "no acceptance recorded" - acceptance dialog only preselects the owner when they are selectable - RTP submit stays blocked while readiness is loading or failed - methodology matrix intro states score bands AND raw-product bands (the previous wording misattributed raw ranges to the score) - readiness queries extracted to risk-treatment-readiness.ts - acceptance response schemas document authType/authenticatedUser + 500 - comment fixes: 10-column table note, ISO 27001 attribution * fix(risks): address review round on the deploy-fix PR - RTP submit gating fails closed: a load/revalidation error blocks submission even when stale cached readiness data is present - approve() runs REPEATABLE READ (single MVCC snapshot), so the drift baseline and the frozen rows can never observe different data; one retry on a P2034 write conflict re-runs with a fresh snapshot - acceptance row locks are org-scoped, so a foreign-tenant id can never acquire another organization's row lock - 500 responses wired into all four acceptance endpoint decorators - authType documents the 'service' value HybridAuthGuard can return --------- Co-authored-by: Tofik Hasanov <annexcies@gmail.com>
Contributor
|
🎉 This PR is included in version 3.108.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.
Summary by cubic
Adds residual-risk acceptance events and two new ISMS documents (6.1.2 Risk Assessment Methodology, 6.1.3 Risk Treatment Plan), and fixes device-agent adoption so integration-imported devices adopted by the agent are counted in People (CS-770). Also hardens acceptance creation and approval to prevent races and immediate drift, improves error handling, and tightens submit gating (CS-727).
New Features
RiskAcceptanceevents for risks and vendors; list and record endpoints with “stale” computed against live residuals.risk_assessment_methodology(templated narrative with fixed scales and a computed 5×5 color matrix) andrisk_treatment_plan(rows from Risk Register + vendors + latest acceptance).risk_treatment_planuses a fingerprint to flag drift; methodology is never platform-stale.authType(includingservice).Migration
RiskAcceptanceand extendIsmsDocumentTypewithrisk_assessment_methodologyandrisk_treatment_plan.ensureSetupwill backfill drafts.evidence:read.Written for commit 7446c89. Summary will update on new commits.