docs: document allow_all in the row_level access policy reference

[igorlukanin]

The row_level reference documented only filters, so a reader could not learn that allow_all exists. It is the documented way to write a policy that spans every row, and RowLevelPolicySchema accepts exactly one of the two.

Adds allow_all to the parameter list with a YAML and a JavaScript example, and states that setting both is an error. The concepts page already mentions allow_all; this brings the reference in line with it.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
cubed3	🟢 Ready	View Preview	Sep 16, 2026, 10:23 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[claude]

Claude finished @igorlukanin's task in 1m 45s —— View job

---

Docs-only change, accurate against the validator — 0 high, 0 medium, 2 low

Review details

• Gather PR context and diff
• Verify allow_all semantics against RowLevelPolicySchema and evaluation code
• Read the full changed file for consistency
• Check prior review threads
• Post findings

Verified claims

Doc claim	Code	Verdict
"Set exactly one of these parameters"	.xor('filters', 'allowAll') — CubeValidator.ts:1135	✅ (also makes row_level: {} an error, which "exactly one" covers)
"Combining allow_all with filters … is an error"	same xor	✅
"A policy with no row_level also grants every row"	!policy.rowLevel || policy.rowLevel.allowAll — CompilerApi.ts:707, and policyHasRowFilter at CompilerApi.ts:667	✅
"filters … the policy grants the rows that match them"	filters AND-ed in policyRowFilter — CompilerApi.ts:659-664	✅
snake_case allow_all in YAML	birdbox-fixtures/rbac/model/cubes/customers.yaml:68 and other fixtures	✅

The reference was genuinely the last place allow_all was missing — docs/data-modeling/data-access-policies.mdx:95 already mentioned it, and the examples match the shape the RBAC fixtures use.

Findings

Both low, both posted inline:

1. docs-mintlify/reference/data-modeling/data-access-policies.mdx:428 — the table row doesn't say allow_all: false is rejected. CubeValidator.ts:1134 is Joi.boolean().valid(true).strict(), so false is a validation error, not a no-op.
2. docs-mintlify/reference/data-modeling/data-access-policies.mdx:530 — the exclusivity rule is restated after line 423 already gave it, against docs-mintlify/CLAUDE.md's "Say it once".

No correctness, security, performance, or test-coverage concerns — the change touches only .mdx prose. No build or test run was needed or performed.

Review threads

The thread listing returned 0 of my own threads (no prior threads). None resolved, none re-affirmed.

· [`igor/document-row-level-allow-all`](https://github.com/cube-js/cube/tree/igor/document-row-level-allow-all)

[claude]

allow_all: false is rejected, not a no-op, and the row doesn't say so. packages/cubejs-schema-compiler/src/compiler/CubeValidator.ts:1134 accepts only the literal true:

allowAll: Joi.boolean().valid(true).strict(),

So a reader who writes allow_all: false (say, to template the flag off a variable, or to spell out "this policy does restrict rows") gets a model validation error rather than a policy that falls through to filters — and filters can't be present alongside it either, because of the xor. Worth one clause in the row.

Suggested change

	| `allow_all` | Set it to `true` to grant every row. The policy applies no row restriction. |
	| `allow_all` | Set it to `true` to grant every row. The policy applies no row restriction. `false` is not accepted. |

[claude]

The exclusivity rule is stated twice — line 423 already says "Set exactly one of these parameters", and docs-mintlify/CLAUDE.md asks to say it once. It also reads oddly as the second sentence of an example intro, where the example itself shows nothing about combining the two.

Suggested change

	Combining `allow_all` with `filters` in one `row_level` is an error.
	In the following example, users in the `auditor` group can access every row.