Problem/Motivation
The block system has but one permission: "Administer blocks", creating an all-or-none situation where granting a user any permission to the subsystem entails giving them god powers there. Especially now that we have custom blocks, I expect people will want more of the flexibility they currently have with nodes to restrict access to different operations by bundle. I know I have for a long time!
Proposed resolution
I propose adding more granular permissions. Update block's permissions as compared to node's:
| Node | Block |
|---|---|
| Bypass content access control | x |
| Administer content types | Administer block types |
| Administer content | Administer blocks |
| Access the Content overview page | Access the Custom block library page |
| View published content | x |
| View own unpublished content | x |
| View all revisions | x |
| Revert all revisions | x |
| Delete all revisions | x |
| Per type: Create new content | Per type: Create new blocks |
| Per type: Edit own content | x |
| Per type: Edit any content | Per type: Edit any blocks |
| Per type: Delete own content | x |
| Per type: Delete any content | Per type: Delete any blocks |
| Per type: View revisions | x |
| Per type: Revert revisions | x |
| Per type: Delete revisions | x |
Marking the above items as 'x' (or deferred to separate issue) because:
- Revisions: there is no revisions ui (#1984588: Add a UI for viewing/reverting custom block revisions)
- Published/unpublished: no status field (#2820848: Make BlockContent entities publishable)
- The ’own’ permissions: no author field (can be handled as separate issue)
Remaining tasks
Decide if and what permissions to add.- Write a patch.
- Add tests.
- Review and commit.
- Write a change notice.
User interface changes
TBD.
API changes
TBD.