Effective per-field readability for composing this asset's form
GET /assets/{id}/field-composition
What a composition surface needs to evaluate display_condition
against this asset, and deliberately nothing else (ADR 0099 §5).
One entry per non-archived asset field definition, carrying the
field’s identity and whether THIS caller may read THIS asset’s
values of it. The response carries no values at all: there is
no member a stored value could be placed in, so non-disclosure is
a property of the shape rather than a rule a handler has to
remember.
readable is derived on the SERVER and cannot be derived in the
browser. GET /auth/me/capabilities carries GLOBALLY held codes
only, so a grant scoped to the team that owns this asset is
invisible there, and a client inferring readability from it would
decide that the very operator the field was configured for cannot
read it. Here the answer is: no read_capability means readable;
otherwise the caller must hold it globally, or hold it scoped to
the asset’s team when the asset has one.
Why a caller needs this at all: false and “there is no value”
must be distinguishable. An unreadable controller makes the whole
condition unevaluable and the dependent is SHOWN, while a readable
controller with genuinely no value is a real FALSE and the
dependent is HIDDEN. Without this endpoint both arrive as the same
nothing and a client cannot tell them apart.
Authorizations
Section titled “Authorizations ”Parameters
Section titled “ Parameters ”Path Parameters
Section titled “Path Parameters ”Responses
Section titled “ Responses ”Per-field effective readability, values excluded
What a composition surface needs to know about ONE field
definition in order to evaluate a display_condition against a
particular subject, and nothing else (#1173, #1119, ADR 0099 §5).
THERE IS NO VALUE MEMBER HERE AND THERE MUST NOT BE ONE. The
non-disclosure requirement is met by the SHAPE: a caller who may
not read a field receives its identity and readable: false, and
there is no member into which the protected value could have been
placed. Sending the value alongside a false flag, or sending it
and expecting the client to drop it, are both explicitly refused
designs. The typed values live on
GET /assets/{id}/fields and GET /collections/{id}/fields, both
of which now filter by the same effective readability this
reports.
object
The federation-stable code. Carried alongside the id because
a display_condition term names a CODE, so a client
resolving a term would otherwise need a second index to get
from the term to this row.
May THIS caller read THIS subject’s values of this field?
Derived on the SERVER, and it has to be: read_capability is
answerable globally OR scoped to a team, and
GET /auth/me/capabilities carries only the global codes, so
a browser inferring this from what it holds would answer
“no” for exactly the team-scoped operator the field was
configured for.
true when the field carries no read_capability at all,
or when the caller holds it globally, or when the caller
holds it scoped to the subject’s team and the subject has
one. An asset may have a team_id; a collection has no team
column, so on a collection the global holding is the whole
answer.
What a condition evaluator does with it: false makes the
term UNEVALUABLE, which makes the whole condition unevaluable
and SHOWS the dependent. That is deliberately not the same as
a readable field with no value, which is a real FALSE and
HIDES the dependent. Distinguishing those two is the reason
this endpoint exists.
Authentication required, missing, or invalid
object
Human-readable error summary
Example
the request could not be completedExample
{ "error": "authentication required: sign in and retry with a valid session or API token"}Resource not found
object
Human-readable error summary
Example
the request could not be completed