fix(permissions): one record rule for every read, update and delete, across projects and through the records a record names

[simlarsen]

Problem

Reads, updates and deletes did not all narrow their records by the same rule. A team's block with labels left records out of a read in one project, but not out of a list read across all of a user's projects, an update or delete by query, or a record that carries no labels of its own. A grant limited to labels narrowed labelled records, but not the records without labels that belong to them, and a record read through another one (an incident's note) could be changed or deleted through a parent the caller may not read. A filter naming a record through a relation could replace the request's own filter on the relation's key, and a check of one record by id read the record before narrowing it to the caller's project.

What changed

One record rule now narrows every read, update and delete of the CRUD path, in the project the request acts in (BasePermission.addRecordScopeToQuery):

• A request keeps to its project. A filter on project, projectId, or any relation given as a plain id, { _id } or Includes is written onto the relation's key and combined with the condition already there, never in place of it (QueryUtil.moveRelationFilterToKey). A record of another project, named by its id or in a filter, is answered as if it did not exist.
• Lists across projects narrow each project by its own rows. A read across all of a user's projects (the home page's lists) narrows each project's records by that project's grants and blocks, exactly as a request in that one project is narrowed (TenantPermission); a block in the project the request names leaves out that project's records only. Projects are worked out four at a time (TenantPermission.PROJECT_CONCURRENCY), however many a user belongs to.
• Updates and deletes follow the read rule. Label grants, Owned grants, the record a model is read through, and the team's blocks narrow updates and deletes, by id and by query. A block with no labels on the operation's permission refuses an update or a delete by query as it refuses a read; a block with labels leaves the records carrying them out.
• A record read through another one keeps to parents the caller may read. An incident's note is read, changed and deleted only through an incident the caller's read grants reach. A change also keeps to the incidents the caller may edit, as it always has; a delete is the note's own permission and weighs no delete grant on incidents. A write is narrowed by conditions on the record's own id, one per list of labels (ReadPermission.addParentLabelsToQuery, QueryHelper.oneLinkedToAny), so the caller's own filters stay exactly as sent and a record readable through one parent and editable through another (an announcement on two status pages) is reached. A read narrows the relation itself, as before.
• Records without labels carry the labels of what they name, for grants as for blocks. ReadPermission.addLabelRulesToQuery is the one helper for both halves, over the same references: the model's parent, its key columns, and resource ids of any kind. A grant limited to labels reaches such a record when one of the records it belongs to or names carries one of the grant's labels (one condition on the record's id, QueryHelper.namesNothingOrOneLinkedToAny); a block with labels leaves it out when one of them carries a blocked label.
• A check of one record reads it in the caller's project, once. DatabaseService.findWithAccessControlIds (used by updateOneById, deleteOneById and findOneUpdatableById) names the record in the caller's project, with its project, before reading its labels. AccessControlPermission.checkRecordByModel runs the block and the grant check of an update or delete by id on one read of the record, looks nothing up when the label rule adds nothing to it, and answers a record of another project, or one read without its project, as missing. A refusal names the block rows it weighed. The services that read the record themselves now select its project.
• findOneUpdatableById answers nothing for a record outside the update scope. A record with no labels of its own is weighed by the update scope's query, so a custom route that changes a record as root (a custom domain's checks) answers a record outside the caller's labels like a missing one.
• Analytics rows follow the record they belong to. Monitor logs (monitor), SLO history (SLO), network flows (network device) and Kubernetes cost allocations (cluster) are read through their parent: Owned and Labels reach the rows of the parents the caller may read, and a block with labels leaves out the rows of the parents carrying them (@OwnedThrough(..., { onlyParentModels: true })). An AI insight follows the service it names (@OwnedThrough("telemetryServiceId", Service, { includeUnattributed: true })).
• Live updates follow the same rule. A write to a key the label rule follows counts as a write that may change who reads the row.
• hardDeleteBy deletes the rows its narrowed lookup found by id, with the query's filters on the table's own columns; filters on relations stay with the lookup, since a DELETE statement cannot join them.

Decisions

• Label grants reach records without labels through the same references as blocks, and through any one of them: a record carries the labels of every record it names, as a labelled record is reached through any one of its own labels.
• A record that names no labelled record is about none of them: a grant limited to labels keeps it and a block with labels does not take it away. A block with no labels is what takes a whole table away. A key that can name records of several kinds counts as naming a labelled record whenever it is set.
• A record read through another one is reached only through a parent the caller may read, on every operation. Updates keep weighing the parent's edit grants as well, as before (custom domains rely on it); deletes weigh none of the parent's delete grants, as before. When the parent's model carries no labels, grants limited to labels reach none of its records.
• An AI insight about no service belongs to the project.
• The audit log and threat intelligence indicators name no owning record, so they stay readable across the project by whoever may read them. The docs say so.
• Lists across projects are worked out four projects at a time, to bound the work on the shared database pool.

What changes for customers

• Teams with grants limited to labels see, change and delete only the records without labels (notes, announcements, remediation decisions, inventory items, endpoints, ...) of which one named incident, alert, monitor, status page, service or resource carries one of the grant's labels, plus the records that name none.
• Teams with block rows have them applied in lists across all projects, as in one project, and to updates and deletes as to reads.
• Changing or deleting a note (or another record read through an incident, alert, status page, ...) needs an incident the team may read, as reading it does. Changing it still needs an incident the team may edit when its edit grants are limited to labels.
• Monitor logs, SLO history, network flows, Kubernetes cost allocations and AI insights follow the Owned and Labels scope of the record they belong to.
• A filter naming another project's record finds nothing, and changing or deleting it by id answers "not found".
• Teams with project-wide grants and no blocks see no change.

The permissions page says all of this, in every docs language.

Left out

• A request across projects that also filters on projectId with a plain id reads each of the user's projects in turn; the filter does not pick one of them (an Includes filter does). Unchanged here.

Tests

• Common/Tests/Server/API/RecordScopeCrudPostgres.test.ts (new, 119 tests, runs in the Postgres workflow): the real BaseAPI routes over migrated Postgres, for a user and an API key: list, count, read, update and delete by id and by query with project, projectId and relation ids (plain, {_id}, Includes); the permission matrix (grant, block with no labels, block with labels, both) on every path; reads across projects, with and without the project in view named; records named through their parents and through several keys; notes changed and deleted through alerts the caller may read and edit; an announcement changed through one status page the caller may read and another they may edit; AI insights; and a statement count that does not grow with the rows read.
• Common/Tests/Server/Types/Database/Permissions/RecordScopeEveryOperation.test.ts (new): the record rule on read, update and delete, per project across projects, with bounded concurrency; one read of a record for both of its checks; refusals naming the weighed block rows; a note's update and delete narrowed through the incident it belongs to, beside the caller's own filters.
• Common/Tests/Server/Types/Database/RelationFilterKeepsKeyGuard.test.ts (new): every many-to-one relation keeps its key filter when filtered by id.
• Common/Tests/Server/Types/Database/QueryHelperLabelGrantOperators.test.ts (new): the grant condition over keys and parents, bound values, quoting, and fail-closed empty lists.
• Common/Tests/Server/Types/AnalyticsDatabase/ReadThroughParent.test.ts (new): analytics rows read through their parent.
• Common/Tests/Server/Services/DatabaseServiceRecordInCallerProject.test.ts (new): a check by id reads its record in the caller's project.
• Common/Tests/Server/Services/DatabaseServiceHardDeleteByRecordRule.test.ts (new): a hard delete under the record rule deletes the rows it found, with no filter on a relation.
• Extended: QueryUtil.test.ts, OwnedScopePermission.test.ts, OwnedThrough.test.ts, DatabaseServiceFindOneUpdatableById.test.ts (records without labels of their own), DatabaseServiceRealtimeReadAccess.test.ts, OnCallCalendarFeedPermissions.test.ts, TableLevelBlockPermission.test.ts, ProxmoxResourceAPIRemoveNode.test.ts, ResourceAiAccessAPI.test.ts, ResourceAiAccessChangeAuthorization.test.ts, DatabaseServerEndpointService.test.ts, AlertStateChangeAuthorization.test.ts, IncidentDeclareAcknowledgeAlerts.test.ts, CustomDomainChangePermission.test.ts.
• App/Tests/FeatureSet/Docs/RecordRuleEveryOperationDocs.test.ts (new): the permissions page in all 17 languages.

The new tests were checked against the code they cover: weighing the parent's delete grants on a delete, ignoring the parent's read grants on a write, putting the record lookups back into findOneUpdatableById, or keeping relation filters in the hard delete's statement makes them fail.

What ran

• packages/Common: npm run compile and npm run compile-tests pass on the branch with the latest master merged in.
• packages/App: npm run compile passes. The App suites that touch these checks (hard delete job, telemetry entity pruning, workflow run authorization, permissions table, declare-from-alert wiring, phone number API, the two permissions page docs tests) pass: 9 suites, 296 tests.
• Common Tests/Server, Tests/Types and Tests/Models (2,666 suites, 107,072 tests), with billing off and with billing on: everything passes except suites that fail the same way on master in this environment - the WebAuthn and passkey suites (UserWebAuthnPasskeyService, UserWebAuthnPasskeyIntegration, UserWebAuthnUserVerification, MobilePasskeyLoginIntegration), SsoInCommunityEdition and CreateAndReadResponsesKeepIds (billing off), and RealtimeAccessChangesValkey, which needs its own Valkey (the shared one here refuses its credentials).
• RecordScopeCrudPostgres against a Postgres migrated with every migration, master's latest included: 119 tests pass.
• eslint with --fix on every changed file.
• The mutation checks listed under Tests.
• Not run: the Playwright suites and the ee packages' tests; nothing in them changed.

🤖 Generated with Claude Code

[simlarsen]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.