chore: make overrideAccess explicit in first-party call sites - #17861
Merged
Merged
Conversation
Contributor
📦 esbuild Bundle Analysis for payloadThis analysis was generated by esbuild-bundle-analyzer. 🤖 |
nathanlentz
force-pushed
the
override-access/packages
branch
from
August 20, 2026 02:41
e98824b to
95a6404
Compare
nathanlentz
marked this pull request as ready for review
August 20, 2026 13:29
nathanlentz
requested review from
AlessioGr,
JarrodMFlesch and
jacobsfletch
as code owners
August 20, 2026 13:29
nathanlentz
force-pushed
the
override-access/packages
branch
from
August 20, 2026 13:31
95a6404 to
ef8731a
Compare
nathanlentz
force-pushed
the
override-access/packages
branch
from
August 20, 2026 15:31
ef8731a to
8e19a42
Compare
nathanlentz
force-pushed
the
override-access/packages
branch
from
August 20, 2026 16:42
8e19a42 to
baa6910
Compare
nathanlentz
force-pushed
the
override-access/packages
branch
from
August 21, 2026 17:34
baa6910 to
65a82bd
Compare
Adds an explicit `overrideAccess: true` to every Local API call in test/
that previously relied on the default.
The Local API currently defaults `overrideAccess` to `true`, so writing
the value explicitly produces exactly what the default already produced.
No behaviour changes.
Four kinds of call site are invisible to both the codemod and a typecheck,
and were found by running the suites instead:
- `(payload as any).create({ ... })` — the receiver is cast, so there is no
typed parameter to be missing (plugin-mcp, pg-replica)
- `payload2.create({ ... } as any)` — the cast is on the argument, so the
object literal is `any` (config)
- `payload.create(createDirector)` — the arguments are hoisted into a
variable, so there is no object literal at the call (relationships)
- Calls added to `main` after this sweep first ran, which arrive whenever
the branch is rebased (queues, versions)
`test/__helpers/shared/sdk/types.ts` makes `overrideAccess` required on the
PayloadTestSDK argument types, so writing an e2e test asks the same question
as writing product code. Every existing call site already passes a value.
Preparation for making `overrideAccess` a required property.
nathanlentz
force-pushed
the
override-access/packages
branch
from
September 8, 2026 14:07
65a82bd to
c12bbbf
Compare
jacobsfletch
approved these changes
Sep 23, 2026
nathanlentz
added a commit
that referenced
this pull request
Sep 24, 2026
This changes the Local API default for `overrideAccess` from `true` to
`false`, including `payload.jobs.*` operations. An omitted option now
enforces access control.
## Before and after
```ts
// Payload 3: omission bypasses access control.
await payload.find({ collection: 'posts' })
// Payload 4: omission enforces access control.
await payload.find({ collection: 'posts' })
// Explicitly preserve the previous behavior where it is intended.
await payload.find({ collection: 'posts', overrideAccess: true })
```
## Changes
- Local API auth, collection, global, and jobs operations now default to
`overrideAccess: false`.
- First-party calls that need the previous behavior pass
`overrideAccess: true` explicitly.
- The trusted CLI keeps its existing behavior through explicit
`overrideAccess: true` calls.
- REST and GraphQL behavior is unchanged; both already enforce access
control.
- The migration guide, Payload skill, jobs documentation, and examples
describe the new default.
## Migration
For a Payload 3 to 4 upgrade, run this from the project root:
```bash
npx @payloadcms/codemod upgrade
```
`upgrade run` is the mechanical step in the upgrade flow. It installs
Payload 4 and applies all registered transforms, including
`add-override-access-true`. A separate codemod run is unnecessary when
you complete this step.
If you manage the upgrade yourself, run this transform after upgrading:
```bash
npx @payloadcms/codemod --transform add-override-access-true
```
Review each inserted `true`. For calls on behalf of a user, use
`overrideAccess: false` and pass the request or authenticated user. The
transform skips argument objects with spreads and calls it cannot
identify as Payload Local API calls. Review aliases, casts, and
nonliteral arguments manually.
## Review notes
The first-party call-site updates are already on `main` through #17859
and #17861. This PR includes the documentation work from #17873.
Access-control integration tests and codemod tests cover the changed
default and migration behavior.
---------
Co-authored-by: Jake Fletcher <jacobsfletch@gmail.com>
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
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.
Summary
Make
overrideAccess: trueexplicit in Local API calls across first-party packages, plugins, templates, and examples. These calls currently rely on a default oftrue, so their behavior stays the same. This prepares them for the default change in #17869.Scope
Calls that intentionally exercise the default remain unchanged. Template calls keep their current access behavior; changes to template access decisions need separate review. The test call sites were addressed in #17859, which is already merged.
This PR combines #17862, #17864, and #17865 into #17861.
Validation
The branches merged without conflicts.
git diff --checkpasses for the combined change. CI will validate the consolidated branch.