TryGhost
OSS
Ghost
Declared custom_fields in the Admin API member schema ref https://linear.app/ghost/issue/BER-3801/declare-custom-fields-in-admin-api-schema-and-remove-the The member schemas set additionalProperties:false, so ajv silently stripped custom_fields out of the body before it reached the service, which was worked around by wrapping the shared members input validator. Declaring the property removes the need for that wrap. It is declared without a shape because only the site's field-type catalog knows what a given key accepts, and constraining it here would both split validation across two layers that could disagree and change behaviour for existing callers, since the key reaches the schema on every site regardless of whether the flag is on. The flag gate therefore moves into the service, where a flag-off site drops the key exactly as a Ghost predating the feature would. Because any JSON value now reaches the create path, the not-supported-on-create refusal asks the values service whether the body names a value, and it answers exactly as resolving an edit would: both verbs share one parse, so a body malformed enough to be refused on edit is refused on create rather than accepted and dropped, and a well-formed body that names no value is created as though custom_fields had never been sent, including an object carrying only a __proto__ key, which names nothing once parsed. The question is only asked when the key is present, so a create that never mentions custom fields does not reach for the collaborator to be told nothing is there.
nx run ghost-monorepo:lint:boundaries
Sign in / Sign up
Open main menu
Succeeded
CI Pipeline Execution
nx run ghost-monorepo:lint:boundaries
Click to copy
Linux
4 CPU cores
read-write
access token used
5f57ab2a
29457