When talking in #drupal-design IRC today a few of us recognized a feature that could be VERY beneficial for site management. We're proposing the addition of permissions to use of regions.

Most site builders/admins probably don't give anyone else access to the blocks menu because there's too much stuff they could mess up...putting things into regions that weren't intended for them, etc. But, imagine if we could set access to regions based on user role...that would allow a situation like this:

1. We set permissions so Role-x can only access Rightsidebar and Leftsidebar regions
2. We can then give them access to the block admin page and they only see those regions (and just as importantly the blocks in those regions) that they have permission to see/edit.

This would mean that we can keep all design/development blocks out of the hands of site managers, but still give them the ability to add/change blocks in areas that the site developer deems proper. This seems like it could be a powerful feature which would open up more editing ability for people not as far down the drupal-dev-curve.

Comments

mason@thecodingdesigner.com’s picture

I love this, but it might be good to extend it and set permissions on a per block basis as well. I think what you're describing wouldn't let users disable or see blocks not associated with a region. I'd like to let a content editor disable a block or move it to another region w/o them having access to all disabled blocks.

manuel garcia’s picture

I'm totaly up for this - it's a great idea.

Only sugestion i'd make would be to keep it as an optional core module, because not all sites would be needing this. Not even sure if it'd be possible the way i request, but well, there it is! :D

gábor hojtsy’s picture

Custom modules in Drupal 7 already have the ability to limit blocks for regions. Since the block placement is done via a select box, one can form_alter the items in any way. The JS for blocks drag and drop also supports this limitation, so when a region is not in the select box, a block cannot be dropped in the given region, and an error message is presented.

This is not exactly adding permissions for regions/blocks, but it allows contrib developers to just alter the available options in the select boxes and let Drupal do the validation, error reporting, etc.

Rob_Feature’s picture

I think the point of this is user permission issues, not so much block permission issues. We're suggesting that users can/cannot see, configure, and apply changes to particular blocks (and regions) not so much tying individual blocks to individual regions. This is a user-control issue, really...not a block-control issue.

sun.core’s picture

Version: 7.x-dev » 8.x-dev
design.er’s picture

This is exactly what I'm looking for. I'm wondering why nobody has needed this before.
I'd like to stay tuned and maybe throw some ideas in.
Here is the first idea: Is it an option to create first a contributed module and improve the usability, fix major bug reports etc. and then implement it into D8 core?
It would take a similar way as CCK.

Stefan

knaffles’s picture

You mention here that there are custom modules for D7 which provide the ability limit blocks for regions. I've been looking for something like this but haven't found quite the right module anywhere on drupal.org. Can you point me in the right direction?

Thanks in advance for any hints you can provide.

ehmprah’s picture

Not exactly a hot topic right now - but since I wasn't satisfied with the Block Access module and didn't find any appropriate solution to this exact problem, I've built something myself. The following code goes into a hook_form_alter() and is built for a use case where site editors should only be allowed to add/remove blocks from the second sidebar:

  //without proper permission, hide all regions except sidebar_second
  if($form_id == 'block_admin_display_form') {
    if(!user_access('access all block regions')) {
      foreach($form['blocks'] as $name => $block) {
        if($block['region']['#default_value'] != 'sidebar_second' && $block['region']['#default_value'] != NULL) {
          unset($form['blocks'][$name]);
        } else {
          $form['blocks'][$name]['region']['#options'] = array('sidebar_second' => t('Second Sidebar')) + array(BLOCK_REGION_NONE => BLOCK_REGION_NONE);
        }
      }
    }
  }

  if($form_id == 'block_admin_configure' || $form_id == 'block_add_block_form') {
    if(!user_access('access all block regions')) {
      $form['regions']['#access'] = FALSE;
      $form['regions']['akademie']['#default_value'] = 'sidebar_second';
      $form['visibility']['role']['#access'] = FALSE;
      $form['visibility']['user']['#access'] = FALSE;
      $form['visibility']['node_type']['#access'] = FALSE;
    }
  }
ladybug_3777’s picture

Issue summary: View changes

Thanks nekhster. I've updated your code a little so that I can check if a user has a specific role and to make sure the code only runs on the block forms. (NOTE, it could definitely use more testing, but on the surface seems to give me what I need)

Anyone looking to use this would need to add in the name of the region they are limiting to (my happens to be sidebar_callout) as well as the name of the user role (my happens to be editor). Also note you need to change "your_module" to match your module's name, and "your_theme_name" to be your theme.

function your_module_form_alter(&$form, &$form_state, $form_id) {
  //See if we are on the block admin form, block configure, or block add forms
  if ($form_id == 'block_admin_display_form' || $form_id == 'block_admin_configure' || $form_id == 'block_add_block_form') {
    global $user;
    $is_editor = FALSE;

    //Check if the user is logged in, if they are see if they have the editor role
    if (user_is_logged_in()) {
      foreach ($user->roles as $uid => $role_name) {
        //print('ROLE IS: ' . $role_name);
        if ($role_name == 'editor') { //You can change this to check for any role you want
         $is_editor = TRUE;
         break;
        }

      }
    }
    if ($is_editor) {
    //If this is the editor role, reduce the options they have to just be the sidebar callout
      if ($form_id == 'block_admin_display_form') {
      //Without proper permission, hide all regions except sidebar_callout
        if (!user_access('access all block regions')) {
          foreach($form['blocks'] as $name => $block) {
            if ($block['region']['#default_value'] != 'sidebar_callout' && $block['region']['#default_value'] != NULL) {
              unset($form['blocks'][$name]);
            } else {
              $form['blocks'][$name]['region']['#options'] = array('sidebar_callout' => t('Sidebar Callout')) + array(BLOCK_REGION_NONE => BLOCK_REGION_NONE);
            }
          }
        }
      }

      if ($form_id == 'block_admin_configure' || $form_id == 'block_add_block_form') {
        if (!user_access('access all block regions')) {
          $form['regions']['#access'] = TRUE;
          //Make sure the only options available are the sidebar callout and None
          $form['regions']['your_theme_name']['#options'] = array('sidebar_callout' => t('Sidebar Callout')) + array(BLOCK_REGION_NONE => BLOCK_REGION_NONE);
          $form['regions']['your_theme_name']['#default_value'] = 'sidebar_callout';
          $form['visibility']['role']['#access'] = FALSE;
          $form['visibility']['user']['#access'] = FALSE;
          $form['visibility']['node_type']['#access'] = FALSE;
        }
      }
    }
  }
}

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

miwayha’s picture

Is there still any interest in this, or any work being done on it elsewhere? It would be quite useful in a lot of the projects I work on.

manuel garcia’s picture

Wow, totally forgot about this... @miwayha I am not aware of any work being done in this direction at the moment. You're of course welcome to get the ball rolling =)

I guess the extremely high level battle plan for this could be:

1. Auto generate permissions per regions per enabled theme.
2. Auto clean up permissions per regions when uninstalling themes.
3. Check for these permissions on all the appropriate places, which probably needs a bit of thinking.

Permissions could be as follows:
"configure region [region] for [theme]"

gábor hojtsy’s picture

This may be worth running through the ideas process first: http://drupal.org/project/ideas given the extent of work required and the potential to waste that work if the change is not desired. (Doing that is as simple as moving this issue to the ideas queue and update the issue summary with the high level goals/plan).

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

yoroy’s picture

Project: Drupal core » Drupal core ideas
Version: 8.3.x-dev »
Component: block.module » Idea

Moving to ideas queue and closing #2816577: Region Permissions as a duplicate. In it, @miwayha explained:

Basically, we have a distribution that we clone for literally hundreds of sites, train some content editors how to create pages and blocks, and let clients self serve. The problem is that they have permissions on all of the regions, which we would like for them to not have. We would love for it to be more locked down.

joshua.roberson’s picture

I created a D8 module that allows you to manage permissions for regions and the region's blocks. I've been using it to restrict our editors for a few months now with no issues. Feedback is welcome.

Project: Block Region Permissions

manuel garcia’s picture

quietone’s picture

Project: Drupal core ideas » Drupal core
Version: » 11.x-dev
Component: Idea » block.module
Status: Active » Postponed (maintainer needs more info)

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Changing to the standard issue template would also help other contributors.

Also, there has been no discussion here for 8 years. Is there still support for this feature?

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

Read the ticket and think such a feature would best be in contrib. Think it would be a lot for core to take on

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.