Skip to content

fix(soa): apply the fully-remote physical-control rule consistently#3397

Merged
tofikwest merged 2 commits into
mainfrom
tofik/cs-731-soa-fully-remote-consistency
Jul 13, 2026
Merged

fix(soa): apply the fully-remote physical-control rule consistently#3397
tofikwest merged 2 commits into
mainfrom
tofik/cs-731-soa-fully-remote-consistency

Conversation

@tofikwest

@tofikwest tofikwest commented Jul 13, 2026

Copy link
Copy Markdown
Contributor

Summary

Follow-up to #3395, addressing the automated review on the merged SoA change.

A fully remote organization's physical-security (7.x) controls are Not Applicable. That rule is enforced at generation time (auto-fill persists isApplicable = false) and the field is edit-locked — but the on-screen SoA and the PDF export did not apply it when no answer was persisted yet. On a freshly created SoA, those controls could render as Applicable/N/A and disagree between screen and export.

This applies the rule identically in both places:

  • resolveSoaDisplay (screen) forces Not Applicable for fully-remote 7.x controls.
  • exportDocument applies the same rule (via checkIfFullyRemote + isPhysicalSecurityControl).

So a fully remote org always sees Not Applicable for physical-security controls everywhere, even before auto-fill has persisted it — screen and PDF stay in agreement.

Changes

  • soa-display.ts: enforced fully-remote 7.x rule restored (applied consistently, not a display-only override).
  • SOATableRow / SOAMobileRow: pass isFullyRemote/isControl7 through.
  • soa.service.ts exportDocument: apply the same rule so the PDF matches the screen.
  • Tests added for both the display helper and the export path.

On the reviewer's other note (legacy applicability shows N/A)

Documents generated before #3395 don't have a per-answer applicability value, so they show N/A until re-generated. This is intentional: the legacy value isn't reliably recoverable from stored data, so surfacing N/A (and regenerating via Auto-fill) is correct rather than backfilling an unreliable value. This is a one-time data-remediation step handled outside this PR — not a code change.

Testing

  • apps/api: npx jest src/soa — 62 passing (incl. a new export test asserting fully-remote 7.x is forced Not Applicable).
  • apps/app: npx vitest run .../statement-of-applicability — 13 passing (incl. the fully-remote display case).
  • Typecheck: no new errors in touched files.

Summary by cubic

Apply the fully-remote physical-security rule consistently across the SoA UI and PDF: for fully-remote orgs, all 7.x controls are forced to Not Applicable and always show the standard remote justification. Fixes screen/export mismatches on new SoAs and prevents stale or cross-org text in those justifications (partially addresses Linear CS-731).

  • Bug Fixes
    • Enforced the rule in resolveSoaDisplay; SOATableRow/SOAMobileRow now pass isFullyRemote and isControl7.
    • In SOAService.exportDocument, used checkIfFullyRemote + isPhysicalSecurityControl; when forced, set isApplicable = false and used the standard remote rationale for both answer and justification, overriding any persisted text.
    • Added tests for UI and export, including overriding stale justifications and leaving non‑7.x controls unchanged.

Written for commit e01fc74. Summary will update on new commits.

Review in cubic

A fully remote organization's physical-security (7.x) controls are Not
Applicable. That rule is enforced at generation and the field is edit-locked,
but the on-screen SoA and the PDF export did not apply it when no answer was
persisted yet — a freshly created SoA could show those controls as
Applicable/N/A and disagree between screen and export.

Apply the rule identically in resolveSoaDisplay (screen) and in the export, so
a fully remote org always sees Not Applicable for physical-security controls
everywhere, even before auto-fill has persisted it. Adds tests for both paths.
@vercel

vercel Bot commented Jul 13, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
app Ready Ready Preview, Comment Jul 13, 2026 2:18pm
comp-framework-editor Ready Ready Preview, Comment Jul 13, 2026 2:18pm
1 Skipped Deployment
Project Deployment Actions Updated (UTC)
portal Skipped Skipped Jul 13, 2026 2:18pm

Request Review

@vercel vercel Bot temporarily deployed to Preview – portal July 13, 2026 14:04 Inactive
@linear

linear Bot commented Jul 13, 2026

Copy link
Copy Markdown

CS-731

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 6 files

Confidence score: 5/5

  • Safe to merge after the addressed issues were fixed.

Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic

Comment thread apps/api/src/soa/soa.service.ts Outdated
For a fully remote org's edit-locked physical-security (7.x) controls, use the
remote rationale unconditionally on both screen and export, rather than falling
back to a persisted justification that could be stale (e.g. written before the
org went remote) and contradict the Not Applicable status. Tests assert the
stale persisted text is overridden on both paths.
@tofikwest

Copy link
Copy Markdown
Contributor Author

Fixed in e01fc74 — both paths now use the remote rationale unconditionally for forced-remote 7.x controls.

One clarification on the framing: the persisted SOAAnswer.answer is per-organization clean — the cross-tenant contamination only ever lived in the shared config, which this work stopped reading. So the persisted value here isn't another org's text. But the fix is still correct: these controls are edit-locked and forced to Not Applicable, so a persisted justification written before the org went remote (their own, but now stale — e.g. "we maintain physical access controls at our office") would contradict the Not Applicable status. Using FULLY_REMOTE_JUSTIFICATION unconditionally on both the screen (resolveSoaDisplay) and the export keeps the output internally consistent.

Tests updated on both paths to assert a stale persisted justification is overridden by the remote rationale (API SoA: 62 passing; app SoA: 13 passing).

@vercel vercel Bot temporarily deployed to Preview – portal July 13, 2026 14:14 Inactive
@tofikwest tofikwest merged commit 1bde95b into main Jul 13, 2026
10 checks passed
@tofikwest tofikwest deleted the tofik/cs-731-soa-fully-remote-consistency branch July 13, 2026 14:21
claudfuen pushed a commit that referenced this pull request Jul 13, 2026
## [3.101.1](v3.101.0...v3.101.1) (2026-07-13)

### Bug Fixes

* **soa:** apply the fully-remote physical-control rule consistently ([#3397](#3397)) ([1bde95b](1bde95b))
@claudfuen

Copy link
Copy Markdown
Contributor

🎉 This PR is included in version 3.101.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants