Description of the need
This is a sibling issue to #5350, and this is a related issue against Drupal 7 core: Dynamic permissions cannot be automatically assigned to or removed from roles.
The 3 content types that come OOTB with a default Backdrop installation all have these permissions already granted to the Editor role, but that is not the case when creating new content types:
When creating a new content type, these permissions need to be manually adjusted each time. With #900, we have improved the UX in Backdrop, since you don't need to navigate away from the content type creation/edit form in order to assign the required permissions to the various roles, nor do you have to search through a HUGE list of permissions to find the correct ones ...this issue here is to improve the UX a big further, by allowing some sensible defaults (that way, site builders will have to scroll/click less when configuring content types).
Proposed solution
- Automatically grant these permissions to the Editor role.
- Perhaps add a setting for this in
admin/config/people/roles
, similar to the "The role that will be automatically assigned new permissions whenever a module is enabled:" setting for admin roles. - Also throw a notice/info message in the node creation form, letting the user know that automatic permissions assignment has happened, and that they might want to review/tweak them as needed.
Advocate for this feature: @klonos
Recent comments
@onyx, you mentioned block_settings[body][value]. If your block has a body field: did you maybe switch the editor to source mode before saving the block? I'm asking because I recently...
update block doesn't work ( bug ? )
Hi Harold. Welcome to Backdrop. If you would like to start attending the meetings, which start at 19:00 UTC nearly every Thursday, I recommend finding out more at https://backdropcms.org/news/...
October 2, 2025 Weekly Meeting
I'm seeing same issue. Multiple browsers, computers. Using the inspect element I have seen that the payload passed to /system/ajax is the old block_settings[body][value], not the new value...
update block doesn't work ( bug ? )