Problem/Motivation
Right now each content entity type needs to define its set of permissions from scratch, then declare a matching access handler. This is pure boilerplate, an entity type's permissions can very precisely be guessed based on the interfaces it implements and the permission granularity it specifies. Furthermore, requiring each developer to create a new access handler each time leaves room for frequent bugs, such as wrong cacheability metadata.
Proposed resolution
The permissions currently vary based on two factors:
- EntityOwnerInterface
- Permission granularity (bundle / entity_type)
Future iterations of the patch / issue followups would also take into account EntityPublishedInterface.
Generated permissions:
- "administer $entity_type_id" (god mode permission)
- "access $entity_type_id overview" (the basic permission for listings)
- "view $entity_type_id" OR "view own $entity_type_id" / "view any $entity_type_id" depending on EntityOwnerInterface
- create/update/delete permissions per bundle or per entity type, also taking into account EntityOwnerInterface
Note that view permissions are never per-bundle cause we have no way to enforce it, we'd need query access for that (ala node access).
Just like we did for route providers, we introduce the concept of permission providers. That makes this generation opt-in.
Each participating entity type would define the core's permission provider, and the matching access handler. Core calls the permission provider of each entity type when building permissions.
The proposed solution was implemented in the Entity API contrib module (#2801031: Provide a generic entity access handler and permissions) and is used by Commerce and other contrib modules.
Remaining tasks
Roll the patch