3

In a Drupal 7 site, I want to give users with a certain role the permission to manage some (but not all) blocks. More specifically, only want to allow editing the blocks provided by the Nodeblock module.

I can probably do a lot with hook_form_alter, but maybe there is a cleaner way (or even a module) to specify edit permissions on the block level.

|improve this question
1

Take a look at Block Access.

From the project page:

This module adds a set of global permissions for creating, viewing, moving, enabling, disabling and configuring blocks as well as permissions at the individual block level.

|improve this answer
  • In theory Block Access sounds good, but there is no Drupal 7 version yet, not even a patch or a git branch. – marcvangend Jun 10 '11 at 7:45
  • I'm marking this as accepted answer - even though there is no D7 code to be tested or used, this module seems like the way to go. – marcvangend Jul 10 '11 at 20:56
2

Part of your question is "... only want to allow editing the blocks provided by the Nodeblock module". Whereas the purpose of that module is like so (from its project page):

This module allows you to specify content type(s) as being a block. This allows the content managers of the site to edit the block text and title without having to access the block administration page. Users only need edit access to that node in order to edit it.

Together with "... I want to give users with a certain role the permission to manage some (but not all) blocks ..." (as in your question), it seems that a translation (summary) of your question is something like "How can I allow the content managers of my site to manage some (but not all) blocks (eg: edit the block text and title) without having to access the block administration page".

Using the Bean module you can perfectly allow your content managers to ""manage some (but not all) blocks (eg: edit the block text and title) without having to access the block administration page"". Here is a quote about the Bean module (from its project page):

Think of a Bean as a method to provide new types (compared to node this would be a content type) which then provides an add content interface to create as many blocks as you require. The bean content can then be placed around the site just like any other block.

Combined with the options available for granting the appropriate Bean permissions, it should give you a lot of flexibility about how exactly you want to use this (great) module in your specific case: for each Block type created with the BEAN module, you can use the typical Permissions page (at admin/people/permissions) to grant Add/Edit/View/Delete access to selected roles (Note: these are 4 separated permissions also). So if you'd create one such "block type" for the role "content managers", then all users with that role (and only those) could then Add/Edit/View/Delete such blocks.

Possible bonus: would you still need the Nodeblock module?

Some more background info about BEANs:

  • To define a Block type you use the admin UI (via admin/structure/block-types), which is similar to defining content types (via admin/structure/types).
  • The difference is that you don't create nodes (of a selected "content type", and by using node/add), but blocks instead (of a selected "block type", and by using block/add).

This module also works great in combination with the UUID and UUID Features Integration modules. And after you become familiar with the Bean module, you might find other cases in your site where you also want to use this module (which somehow compensates the fact that you need to add another module).

The video tutorial Drupal Bean module tutorial - using Bean Admin UI provides a great introduction to really understand the power of this module, and the kind of things you can do with it (by only using site building techniques, no custom coding involved). It also shows how the Bean module transforms Drupal blocks into fieldable entities.

Remark: interesting detail on the Nodeblock project page:

... There are several other modules and approaches that allow nodes to be presented as a block. See a comparison at http://groups.drupal.org/node/93499 ...

And this last link states the following:

The Bean module does not allow nodes to be presented as blocks, per se, but creates block entities instead. Since entities are the fundamental unit of Drupal 7 content, this is analogous and can accomplish many of the same ends.

This sounds like "Now that the BEAN module is available (it wasn't at the time this question was asked), you don't need blocks to be presented as nodes anymore to do more advanced things with blocks" ... no?

PS: The Bean module only started as of D7 (because of the "entities" of course that were only introduced in D7), and already has over 22K reported installs. AND it has been integrated (already) in core in D8. Those who don't use it yet should definitely start looking at it in preparation of some day upgrading to D8.

|improve this answer
  • Note that the question was asked when Bean was still at alpha-1... But I agree, Bean solves a lot of problems. – marcvangend Dec 4 '15 at 14:29
  • I agree that only recently BEAN became a valid option. But since the question was not closed I thought my updated answer might help somebody "today". – Pierre.Vriens Dec 4 '15 at 16:30
  • Absolutely. You got my upvote for that, and I would definitely consider making it the accepted answer if I had verified myself that it works as advertised. – marcvangend Dec 7 '15 at 9:09
  • 1
    Thanks for the extra clarification (and upvote!). Though my prior comment was not intended to sound something like "maybe you want to mark this answer now as the accepted answer" (as back in 2011 was probably the best available back then). Doei from around BXL (Leuven) to A'Dam ... – Pierre.Vriens Dec 7 '15 at 9:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.