🧷 fix: Preserve Document Priority on Section-Scoped Config Writes

[dustinhealy]

Summary

The admin-config field-patch and tombstone handlers accept a priority field on the request body, which controls the position of the entire Config document in the precedence cascade. Today, that priority is written unconditionally, even when the caller holds only a section-scoped grant (e.g. manage:configs:memory). On a document that contains overrides for other sections, this lets a section-scoped caller silently reorder overrides they have no permission to author.

This is a defense-in-depth fix that matters for deployments using section-scoped grants (manage:configs:<section>). In a vanilla setup where admins hold broad manage:configs, the path is unreachable because the broad-capability short-circuit lets every priority change through; the fix is a no-op for those callers. The change makes the contract safe-by-construction for any deployment that narrows the auth model.

Concrete scenario

Tenant has two roles:

• content-admin holding manage:configs:memory only
• platform-admin holding broad manage:configs

platform-admin posts a config at priority: 5 containing both memory and endpoints overrides. Later, content-admin patches a memory.context field and includes priority: 999 in the body:

PATCH /api/admin/config/role/admin/fields
{ "entries": [{ "fieldPath": "memory.context", "value": "..." }], "priority": 999 }

Pre-PR: 200 OK, the entire document's priority jumps to 999, reordering the endpoints override in the cascade. Post-PR: 200 OK, document priority stays at 5; the section-scoped caller never touches priority. A logger.warn is emitted on strip so operators can see the request was partially honored.

Change Type

• Bug fix (non-breaking change which fixes an issue)

Testing

• cd packages/api && npx jest src/admin/config.handler.spec.ts — 71/71 passing (8 new cases covering: section-scoped strip, default-fallback when no existing doc, broad-manage honors request, priority: 0 preserved on broad write, existing priority: 0 preserved for section-scoped, findConfigByPrincipal skipped when broad provides priority, both patchConfigField and tombstoneConfigField)
• ESLint + Prettier + tsc clean on changed files

Checklist

• My code follows the project style guide
• I have performed a self-review of my own code
• I have added tests that prove my fix is effective
• All new and existing tests pass locally

[Copilot]

Pull request overview

This PR hardens the admin config field-patch and tombstone handlers so that document-level priority cannot be modified by callers who only have section-scoped config grants (e.g. manage:configs:memory). This prevents section-scoped callers from reordering unrelated overrides in the config precedence cascade.

Changes:

• Computes a single hasBroadManage (manage:configs) check and uses it to gate whether request-supplied priority is honored.
• Strips/ignores priority on section-scoped patch/tombstone requests (while preserving existing or default priority) and emits a logger.warn when this occurs.
• Adds Jest coverage for priority preservation behavior across patch and tombstone flows (including priority: 0 handling and “skip lookup when broad manage supplies priority”).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
packages/api/src/admin/config.ts	Ignores caller-supplied priority unless the caller has broad manage:configs, preserving existing/default priority for section-scoped writes and logging when stripping occurs.
packages/api/src/admin/config.handler.spec.ts	Adds regression tests ensuring section-scoped callers cannot change document priority while broad-manage callers can, including priority: 0 cases and lookup-skipping behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dustinhealy]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

Reviewed commit: 6ce5c86105

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".