Problem/Motivation
Drupal's Entity Access aggregates access like this (in symfony language):
- the EntityAccessControlleHandler collects and aggregates the results
- it has on vote itself
- more hook_access votes are collected
- the results are aggregated wrt 3-state logic "strategy" (allowed if any allowed and no forbidden)
The 3-state Drupalism has big issues in itself:
- it is hard to get right, even senior developers fail (SA-CONTRIB-2023-054, #3422253: Access broken when more than one relationship, ...)
- it has limited expressiveness (i remember a project that wanted to marry group and domain access, which needed to swap out a lot of code)
And the whole system has a lot of issues more:
- the access votes have no names
- access votes are often aggregated already, with no way for the aggregation to tell the parts apart
Proposed resolution
Work towards an AccessAggregationApi that has these properties:
- (Like today) The EntityAccessControlleHandler collects votes from the controller itself and all hook_access implementations
- The hook_access AccessResult return values have more metadata than today
- a name and named sub-votes
- the sub-votes have a default role ("allowing", "forbidding" like today) and a priority (new)
- Optionally, the votes can be lazy
That way,
- EntityAccessControlleHandler is always in charge of overriding the access aggregation. (Marrying group and domain access is no longer a nightmare.)
- There is a smooth upgrade path from current system to modern, expressive access aggregation.
Relation to Unifying single and query access:
- #777578: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() discusses the idea of unifying single-entity and entity-query access by adding a field condition abstraction that is php-evaluated for single-entity access, and compiles to query conditions for entity queries (and was pioneered in Entity API and in an advanced form Entity Unified Access).
- In comment #777578-256: Add an entity query access API and deprecate hook_query_ENTITY_TYPE_access_alter() ff some problems with unifying access were stated, that should be solved or mitigated by a central aggregator, not trying to aggregate within access alterers.
- Which suggests poptponing the other issue on this.
Remaining tasks
Discuss, implement.
User interface changes
None.
Introduced terminology
Access aggregation.
API changes
Access aggregation api.
Data model changes
None.
Release notes snippet
Drupal has an access aggregation API.
Comments
Comment #2
geek-merlinComment #3
quietone commented