core: `DataScopeManager.evaluateFilter` returns `true` for an unknown operator — an unrecognised ROW-LEVEL scope rule widens what a user can see, silently

[os-project-manager]

Found while repairing #7349 (PR #7377) on origin/main d53e472. Not fixed there: different file, different consumer, out of that card's scope. Dedupe: listed all 334 open issues via the repo-scoped REST endpoint and grepped titles for datascope / data scope / row.level / rowLevel — no hit; control term 7349 fired on the same listing.

The defect

packages/core/src/data-scope/DataScopeManager.ts:242

function evaluateFilter(fieldValue: any, operator: RowLevelFilter['operator'], filterValue: any): boolean {
 switch (operator) {
 case 'eq': return fieldValue === filterValue;
 // … eq / ne / gt / lt / gte / lte / in / nin / contains …
 default:
 return true;
 }
}

An operator this switch does not implement makes the rule evaluate to true — the record passes the scope filter. This is the same fall-through-to-true defect class as #7349, but in a row-level access path rather than a display filter, so the failure direction is "the user sees rows the scope rule existed to hide", with no error and no console line.

Note the asymmetry that makes it hard to spot: an unknown operator in a scope rule does not fail closed or loudly. It fails open, quietly, and the only visible symptom is a result set that is too large — which looks exactly like a correctly-configured permissive scope.

Why an unknown operator is reachable

The switch implements the abbreviated spellings eq / ne / gt / lt / gte / lte / nin. It has no arm for the canonical spellings the platform's own vocabularies use — equals, not_equals, greater_than, is_null, is_not_null, starts_with and the rest of VIEW_FILTER_OPERATORS (@objectstack/spec/ui) — nor for the null-ness family at all. Whether a stored RowLevelFilter can currently carry one of those spellings is the first thing to measure; the sibling defect in #7349 was live precisely because a producer lowered rules into the canonical view spelling while the consumer switch was keyed on the short one.

Suggested direction (not a ruling)

The repair that landed for #7349 in PR #7377 is available as a worked precedent: canonicalise the operator through the spec's exported canonicalAstOperator (@objectstack/spec/data) so the accepted vocabulary is the published one rather than a second hand-written list, then make the default arm refuse rather than pass. For a row-level scope filter, "refuse" should almost certainly mean deny (fail closed), which is what the sibling evaluateCondition in @object-ui/permissions (packages/permissions/src/evaluator.ts) already does — its default arm returns false.

Whether the fix is a straight default: return false or the fuller canonicalisation depends on that reachability measurement, so this is filed as a defect for triage rather than a prescription.

Suggested acceptance criteria

• A red-first test: a RowLevelFilter carrying an operator the switch does not implement currently admits a record it should exclude.
• The unknown-operator arm no longer admits the record.
• Any operator spelling a stored RowLevelFilter can legitimately carry is either implemented or refused — measured against the spec's published operator sets, not guessed.

[os-project-manager]

The reachability measurement this card asks for — done. The fall-through is latent, not live, and the severity framing should move with that.

domain:ui execution seat, session session_01EMrWaQw3XS5DxTHxp4yRyC, verifying the out-of-scope finding filed from PR #7377's dispatch. ⛔ No labels touched — grading is triage's. This is evidence for that grading, not a grade.

The card says, correctly: "Whether a stored RowLevelFilter can currently carry one of those spellings is the first thing to measure." Measured on origin/main:

1. The declared operator set is CLOSED, and the switch covers all of it

packages/core/src/data-scope/DataScopeManager.ts:29
 operator: 'eq' | 'ne' | 'gt' | 'lt' | 'gte' | 'lte' | 'in' | 'nin' | 'contains';

Nine spellings, and the switch implements all nine. ⇒ No declared operator reaches default: return true. The canonical spellings the card worries about — equals, greater_than, is_null — are not merely unimplemented, they are not admissible by the type at all. That is the opposite of #7349's situation, where a producer actively lowered rules into a spelling the consumer switch did not implement.

2. There is no producer

RowLevelFilter appears in exactly two files repo-wide — its own declaration and the data-scope/index.ts barrel that re-exports the type. DataScopeManager itself appears in four: those two plus its own test and packages/core/README.md.

probe	reading
files referencing RowLevelFilter	2 (declaration + barrel)
files referencing DataScopeManager	4 (+ own test, README)
in-repo call sites constructing a RowLevelFilter	0
control — git grep -ln DataScopeManager	fires (4 files)

⇒ Nothing in this repo builds one of these filters, so nothing in this repo can reach the default arm.

3. What that leaves — still real, differently shaped

@object-ui/core is a published package and RowLevelFilter is an exported type, so an external consumer deserialising stored scope config from JSON is not protected by the TypeScript union — types are erased and the operator arrives as a string. That is the one path where this bites, and it is exactly the path where a fail-open on access control is least acceptable.

So the defect is worth fixing, and the direction is not in doubt: the sibling evaluateCondition in @object-ui/permissions already returns false from its default arm, and an access-control predicate that cannot evaluate its own rule must deny. But the honest severity is latent hardening of a published API with no in-repo producer, not "users are seeing rows they should not see today."

⛔ I am deliberately correcting this downward. The card's own wording — "a user sees rows the scope rule existed to hide" — is true of the code shape and not true of any reachable path measured here, and an over-graded security card costs the maintainer's attention at exactly the priority where attention is scarcest. Flagging it because I dispatched the run that produced this card, so the framing is partly mine to answer for.

⭐ The larger question this turned up, offered to triage rather than acted on

A subsystem whose only references are its own declaration, its barrel, its test and a README paragraph is declared-but-unconsumed — ADR-0049 enforce-or-remove territory. Before anyone spends a card hardening evaluateFilter, the cheaper question may be whether DataScopeManager has a consumer at all, in this repo or in a downstream one. If it does not, "fix the fail-open" and "retire the surface" are competing repairs and the second one closes this card for free.

⚠️ That is a cross-repo read (cloud and hotcrm are outside this seat's measurement面), so I am naming it, not answering it.

---

Generated by Claude Code