Problem/Motivation

Some guarded fields are records about a user, stored on that user's account — directly on the user entity, or on a composition entity (a paragraph, an inline entity) that hangs from it. Sites may want the subject to be able to read their own record while keeping every other property of the guard: the edit protection, the definition-level (filter/sort) deny, and the deny against everyone else, administrators and uid 1 included.

Today the only way to open own-record viewing is to grant the mapped permission, which opens every record to that role — there is no ownership-aware option.

Proposed resolution

Add an opt-in, per-field, view-only flag to the protection map:

protected:
  paragraph:
    client_document:
      field_client_file:
        view: 'manage client documents'
        view_exempt_own_subject: true
        edit: 'manage client documents'

When the flag is boolean true and the entity carrying the field ultimately roots at the acting user's own account, the view guard stands aside by returning neutral — the module still never grants; ordinary entity and field access decide. The host chain is resolved by duck-typing on getParentEntity() (a new field_guard.host_chain_walker service), depth-capped, cycle-guarded, and fail-closed: an unresolvable chain, an orphan root, a broken parent accessor, or the anonymous user exempts nothing.

Deliberately out of scope:

  • No edit counterpart, ever: a record its subject can rewrite is not evidence. The edit guard on the same field is untouched.
  • The definition-level (NULL $items) deny is untouched: without an entity there is no subject, so filter/sort probing stays closed for everyone, subject included.
  • Only boolean true enables the flag; any other value fails closed. A typo'd key remains a schema violation (the operations mapping stays closed).
  • Everyone else is still denied exactly as before, and named permission holders still pass.

The exempt verdict carries the user cache context and every chain entity as a cacheable dependency, so re-parenting a composition entity invalidates it; the non-subject verdict on a flagged field keeps the role/permission cache contexts.

Remaining tasks

Kernel coverage pins: subject may view own / may not edit own; other users, is_admin roles, uid-1-style accounts and anonymous all still forbidden; explicit grants still honoured on a flagged field; the definition-level deny; the opt-in property (no flag, no exemption). Unit coverage pins the walker's fail-closed cases (orphan, cycle, depth cap, non-entity parent).

API changes

New optional view_exempt_own_subject boolean in the per-field operations mapping of field_guard.settings; new field_guard.host_chain_walker service. No BC break — existing maps behave identically.

Comments

jmcerda created an issue. See original summary.

jmcerda’s picture

Status: Active » Fixed

Shipped in 1.2.0.

The view guard stands aside for the record's own subject when a guarded field's per-field map entry sets view_exempt_own_subject: true. Host chain resolved by the new field_guard.host_chain_walker service (duck-typed getParentEntity(), depth-capped, cycle-guarded, fail-closed). The exempt verdict is neutral — the module still never grants — and edit guards, the definition-level deny, and every non-subject deny are unchanged. Kernel coverage pins the subject/non-subject matrix, cache contexts on both verdict arms, and the walker's fail-closed cases.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.