Answered #6 at 3486240 π¬ Custom User roles permissions lost Active .
This module doesn't add/remove roles, only permissions. I suggest converting them to the core permissions before upgrading to Drupal 11 since 11 is not supported. See the "How to migrate to core permissions" section on the project page.
Per the project page, this module's functionality is apart of Drupal 10.1.x-dev. This project is no longer needed for newer Drupal versions. Closed as "won't fix".
joshua.roberson β made their first commit to this issueβs fork.
This module's features are now in core as of 10.1.x-dev and the project page updated to "no longer needed" and a section added for "How to migrate to core permissions". As I recall, "View restricted block content" is the only extra permission. Core moved the "Custom blocks" page from under "Structure" to "Content", removing the need for the "Administer blocks" permission.
I'm just wondering, is the core version not usable in this instance or is there something extra this module offers that is needed? As of WxT v5.2.0, it has a note that it's equivalent to v5.1.1 but against Drupal Core 10.2.x, so I would assume the same core feature is available.
Unlike that module, which its project page describes as obsolete, this one can't say "All features of this module are now in core" due to the unique "View restricted block content" permission and functionality. I have a note and migration instructions on the project page, which I hope is sufficient. Too bad I can't distinguish the number of D8 and D9 sites using it.
Do you know if Drupal has any guidelines or recommendations? I didn't see anything with my quick search.
No, this module will still work. All it means is this module isn't needed anymore. There is a section on the project page that says "As of Drupal 10.1.x-dev, this module is no longer needed." Also see the instructions on switching to the core permissions.
I tested the module without modification on D9.5.3 and D10.0.3 with a user without the "view restricted block content" permission. The page works correctly and nothing was reported in the log messages. Seems like you want to extend the current query to something more by adding the "join", so this isn't a bug. Can you elaborate on what you are trying to accomplish?
I also tested it and it works great. Thanks everyone! I've added info to the Block Content Permissions β module for migrating to the new permissions.
In response to #234. I'm the project maintainer for the Block Content Permissions module. Good to hear this is almost done. My module is temporary until this works.
Regarding the "View restricted block content" permission. It relates to an extra feature I added for practical reasons outside the scope of this project. Drupals default behavior is to show all or nothing. I felt seeing all block content in the library list regardless of permissions could be overwhelming, so by default I restrict the list to those the user can create, edit, or delete. Enabling that permission turns off that restriction so you see the full list, which is the default Drupal behavior.
Maybe they should be called "block content" and "block content types" based on the core module's name? There are also views blocks and probably other types through contrib modules. If I recall correctly, there is a "block" and "block content" core module. Placing a "block content" or other types of blocks in a page's region is technically called a "block". It's probably not specific enough to just say "custom block" or "block", and might cause some confusion.
This request is outside the scope of this project. The Field Permissions β module might give you the field level permissions you want.
Remove email addresses.