Block access by role: done.

By flexer on 26 Feb 2005 at 13:31 UTC

I've implemented a way to permit the visualization of blocks on per-role basis, on the CVS HEAD version. It is not a new module, but some hacks in block.module and user.module, plus a new table (block_access).
How it works:
using the new "Configure" option on each block, you can select which roles can access the block (this works like "Content specific visibility settings" so now there is a "Role specific visibility settings"). Whenever the "list" hook is called on the block module, a check is made to match $user roles and block $roles (if any, saved in the new block_access table). The intersection of the two arrays, decide the visualization (or not) of the block. In combination with the menu module (that create a new block for each new menu) this could increase the power of Drupal access management.

Now what? What I should do with this code?

Comments

Create patches

kbahey commented 26 February 2005 at 16:21

I personally think this is a great feature! It provides consistency to Drupal, since

Do you know how to create patches?

First make sure your code is compliant with the coding standard http://drupal.org/node/318

Then, read this on how to create and send patches here http://drupal.org/patch

Submit a feature request against CVS, block.module, and describe what you did, and attach the patch. Don't forget to set the status to patch.

We look forward to more contributions.
--

Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Patch suubmitted

flexer commented 26 February 2005 at 23:41

http://drupal.org/node/18018

Thanks :)

As a follow up... Make sure

sepeck commented 27 February 2005 at 00:58

As a follow up... Make sure you follow any issue/comments on the patch. You might consider subscribing to Drupal-devel mail list and following/initiating any discussion there. If a feature/patch has an active responsive developer who responds to feedback patches that have enhanced functionality seem to have a better chance.

-sp
---------
Test site...always start with a test site.
Drupal Best Practices Guide

-Steven Peck
---------
Test site, always start with a test site.
_{Drupal Best Practices Guide}