Removed the permission to read member custom field definitions by rob-ghost · Pull Request #30497 · TryGhost/Ghost

rob-ghost · 2026-09-03T11:18:42Z

ref https://linear.app/ghost/issue/BER-3922/rename-the-code-behind-the-metafields-api-to-match-the-domain-language

Background

Ghost lets a publisher define extra fields on their member records — a shoe size, a company name. A definition records that the site collects a shoe size; a value is what one member entered for it. Definitions are grouped under a namespace naming whoever owns them. The publisher's namespace is custom, the only one today; others are intended for installed apps.

Ghost guards these with a permission called member_custom_field, carrying five actions: browse, read, add, edit and destroy. Administrators and Admin Integrations hold all five. The Super Editor role holds browse and read, and nothing else.

Problem 1: the read permission protects nothing, and is inverted

A definition records only that the site collects a shoe size. Every signed-in member is already shown the complete list of them through Portal, Ghost's member-facing interface. So withholding that list from staff keeps back nothing that is not already on offer elsewhere.

It is also the wrong way round. An integration holding permission to browse members receives those members' field values on the member payload — that code path never consults this permission. The same integration asking for the definitions that describe those values is refused. It can read the data but not the schema.

The HTTP routes already draw the correct line, and do so deliberately: reads are not behind the feature flag, so Admin can ask any site for the list and get an empty one back, while everything that changes something is behind it. Only the permission layer had not caught up.

Problem 2: two checks run in the wrong order

Defining a field requires two things to be true: fields must be definable in the namespace named in the URL, and the caller must be allowed to define them. Ghost asked the second question first.

So a request naming a namespace that nobody can define fields in was refused for want of a permission. That answer sends the caller off to acquire a permission that nobody holds and that would not have helped them, when the real answer is that the namespace was never writable by anyone.

Solution

Reads need no permission. The browse and read handlers stop checking one. The two permission records are removed from Ghost's fixtures, along with the Super Editor grant, which consisted of nothing else. A migration removes both from sites that already have them. What remains on the permission is defining a field, which stays with the publisher.

The namespace settles before the caller. That check moves out of the definitions service into a module of its own, and the endpoint runs it first. A namespace nobody can define in is now refused on that ground, naming the namespace, whatever role the caller holds.

Consequence worth noting

Staff reads widen from Super Editor and above to any authenticated staff member. This is intended: a Contributor can now see a list that any signed-in member could already see.

Why the permission keeps its name

It governs who may define fields in the publisher's namespace, and it will only ever govern that. Other namespaces are to be owned by installed apps, and an app managing its own fields does not hold a staff role — it has to be that app, which is an ownership check rather than a permission check. Naming this permission after metafields generally would claim an authority it is never going to have.

The new namespace module is where that ownership check will live.

Verification

The migration replay test passes against both MySQL and SQLite, along with the metafields suites and the fixture and schema integrity checks. Three existing tests changed to match the new behaviour, and one was added pinning the new ordering: a role without the define permission, naming a namespace nobody owns, is now told about the namespace rather than about a permission.

Where this sits


#30492	shared field-type package
#30494	database tables and columns
#30495	server-side service and its types
this PR	permission to read and define fields

Last of four. Stacked on #30495, on #30494, on #30492 — review those first. Merging this one brings the whole stack in.

https://claude.ai/code/session_01XFCbqgYHYhd9rZ5WXtqZyT

ref https://linear.app/ghost/issue/BER-3922/rename-the-code-behind-the-metafields-api-to-match-the-domain-language Reading a field definition is no longer gated by a permission. A definition says only that the site collects a shoe size, and every signed-in member is already shown the whole list through Portal, so holding it back from staff protected nothing that was not already on offer elsewhere. It was also inverted. An integration holding member browse received members' field values on the member payload, which never consults this permission, while a request for the definitions describing those same values was refused. It could read the data but not the schema, which is the wrong way round. The routes had already drawn the line correctly and deliberately: reads are unflagged so Admin can ask any site and get an empty list, and everything that changes something is flagged. Only the permission layer had not caught up. What remains on the resource is defining fields, which stays with the publisher. The smaller change alongside it is one of order. Which namespace is being written to now settles before who is asking, so a namespace nobody can define in refuses on that ground whatever role the caller holds, rather than answering with a missing permission that no one could have been granted. That is also where namespace ownership belongs once an app owns a namespace of its own, since the caller will then have to be that app rather than hold a role. Claude-Session: https://claude.ai/code/session_01XFCbqgYHYhd9rZ5WXtqZyT

coderabbitai · 2026-09-03T11:18:49Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: QUIET

Plan: Team

Run ID: 5da3b722-7460-4133-9ed9-1bc6d2691019

📥 Commits

Reviewing files that changed from the base of the PR and between 45274cd and 5e83246.

📒 Files selected for processing (10)

ghost/core/core/server/api/endpoints/member-metafields.ts
ghost/core/core/server/data/migrations/versions/6.63/2026-09-03-11-03-31-remove-member-custom-field-read-permissions.js
ghost/core/core/server/data/schema/fixtures/fixtures.json
ghost/core/core/server/services/members-metafields/definitions-service.ts
ghost/core/core/server/services/members-metafields/namespaces.ts
ghost/core/test/e2e-api/admin/member-custom-fields.test.ts
ghost/core/test/integration/migrations/migration.test.js
ghost/core/test/unit/server/data/schema/fixtures/fixture-manager.test.js
ghost/core/test/unit/server/data/schema/integrity.test.js
ghost/core/test/utils/fixtures/fixtures.json

💤 Files with no reviewable changes (2)

ghost/core/core/server/data/schema/fixtures/fixtures.json
ghost/core/test/utils/fixtures/fixtures.json

Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review.

📜 Recent review details

🧰 Additional context used

📓 Path-based instructions (12)

Review migration safety beyond lint: schema and migration parity, existing-data shape and volume, deploy/rollback compatibility, transaction and locking risk, idempotency, export/integrity updates, and preservation of constraints/defaults.