"Role specific view settings" per block effects other blocks of same "type"

I'm experiencing the same issues.

When I set "Role specific view settings" on 1 block it automatically sets those settings on all the other blocks I manually created.

I tried to turn those settings off on another block, but they just remain set.
You can disable them all again by disabling the settings on the original block where you enabled the settings.

Experiencing the same issues as keZzosaurus and iancawthorne. When attempting to restrict access to the body field of a specific block, I am finding that they are all set the same way as the first block I set and the setting cannot be changed on these subsequent blocks.

Having the same issue here.

I just installed the module, I set permissions for one block from the block module.
And then my user has the same permissions for all blocks generated by block module (any delta).

Hi, I got the same issue, is there a way to patch/fix this until a new release ?
If someone got a solution please let us know.
Thanks

Hi,

I have the same problem. It's not a per role permision set, but it'll impact all the block permission..

Hi,

Hi, I have the same problem. Do you know if this problem can be fixed with some permission settings?

Thanks.

Hi guys,

Thanks very much for posting this issue.

After taking a closer look at the problem and module in general, it seems it could probably be improved a little bit and I would surely be glad to spend some more time to get more patches submitted.

In any case, please find attached to this comment a patch against block_access-7.x-1.x at 2fda868 which is and attempt to fix the issue described in this ticket (allow different blocks with different deltas, from the same module, to have different access settings configured).
File attached as: block_access-specific-access-settings-per-block-1916028-7.patch

Basically, in the function block_access_get_roles, if you look carefully at the code (which is quite short) you should be able to find that the $delta variable, passed to the function, is not used anywhere. Therefore, adding another condition to further filter on $delta in the query should only return access configurations for a given $module, $delta combination.

This patch has been tested and seems to work as expected, but I would greatly appreciate to have your feedback, questions, comments, reviews, suggestions, recommendations, improvements and testing.

Feel free to let me know if you would have any further comments, issues, questions, objections, recommendations, suggestions, testing, reporting or concerns on the attached patch or any other aspects of this ticket in general, I would be glad to provide more information or explain in further details.

Thanks to all in advance for your feedback, reviews, testing and reporting.
Cheers!

Thank you, works as expected. It could be merged with dev version.

Patch works for me, thx!

The patch has fixed the issue, it should be applied to the module.

Many thanks!

I can't get this to work.
I have applied all the patches in the Issues This one and THis one but I still can't get rid of the permissions settings on Block Access Settings.

I'm using Drupal 7.20
Block access 7.x-1.x-dev

I gave permission to my authors to one block only and now they have access to all the blocks. I go to admin/structure/block/block-access and edit the default setting for "Block" and they do not get saved.

What do I do wrong?
Thanks

I think this may be fixed in the latest dev branch. We will be testing the module more extensively over the next couple of weeks so I'm hoping to push out a 7.x-1.1 soon.

@lambic:

It would have been greatly appreciated if a link to the corresponding commit or code change that supposedly fixed this issue, could have been provided at #14.....

Potentially allowing users who have been following this issue with a great interest to know how it could have got fixed.

Thanks.

It appears that I am have this problem in the latest version 7.x -1.5. Has this patch been applied to that version? If not I will try the patch. Thanks!

I had the same experience as johnpicozzi in the latest stable 7.x-1.5.

The error is the next: if I enable permission to a role in connection with a specific block ( e.g. delta = 10, module = block ), than all of blocks created by block module will be enabled.

This release contains the patch, but a bit modified:

function block_access_get_roles($module, $perm, $delta=NULL) {
  $ret = array();
  $query = db_select('block_access_roles', 'b')
    ->fields('b', array('rid'))
    ->condition('module', $module, '=')
    ->condition('permission', $perm, '=');

  if ($delta) {
    $query = $query->condition('delta', $delta, '=');
  }

I think the $query = snippet is unnecessary ( even incorrect ). I tried without it, but it does not work that way either, because if the $delta is not NULL, but there is no record found with the query above ( with delta ), than the code repeats the query without delta:

  // If we didn't find any for the delta, use the module defaults <-- [[commented later ]]
  if ($delta && empty($ret)) { <-- [[ if $delta not equals NULL, but the previous query did not find anything ]]
    $query = db_select('block_access_roles', 'b')
      ->fields('b', array('rid'))
      ->condition('module', $module, '=')
      ->condition('permission', $perm, '=');

and voilá! It finds something! I think this is bad logic. If I have a record with a specific module/delta/role_ID/permission combination, why the combination without the delta is the module defaults?!?
( same problem in dev )

I can confirm the same problem in 7.x-1.5. Granting access to a single block for a role allows the user with that role to edit all blocks created by the blocks module.

However I don't think the problem is with the block_access_get_roles function... I think it's the block_access_add_role function. The issue is that once role specific config settings are set for one block, they are set for *all* blocks. As an example, I edited one block and set the role specific config_body settings to be available to admin and editor. I select a second block to edit, and the admin and editor checkboxes have been selected for that block too!

As soon as I remove the selected checkboxes from the second block and save, the editor role no longer has the ability to access the page.

So there is a manual workaround for this problem... edit all the blocks where you don't want the role to have access, and remove those checkboxes. However the core problem is that once a Block Access role configuration is set for one block created by the blocks module, it automatically does so for all of them.

One additional comment -- once roles have been automatically set for a block by the Block Access module, they cannot be completely removed. Rather, it is only possible to restrict access to the block.

For example, say I have Block 1 and Block 2. For Block 2, I have set admin and editor roles to be able to edit the block body. As soon as I save Block 2, Block 1 also automatically has these settings. If I attempt to edit Block 1 and remove the admin and editor roles, it won't allow me to do so. I remove the two checkboxes, click save, and the roles are still selected.

The only way possible to manually work around this is only remove the roles that should not be accessible, not all of them. In my example above, I can remove the editor role from Block 1, but not the admin role. Doing so will achieve the result of allowing admins to edit the block body, but not editors.

--- block_access_old.db.inc 2015-02-04 15:08:26.937852752 +0700
+++ block_access.db.inc 2015-02-04 15:09:38.733852636 +0700
@@ -66,11 +66,11 @@

// If we didn't find any for the delta, use the module defaults
if ($delta && empty($ret)) {
- $delta = NULL;
$query = db_select('block_access_roles', 'b')
->fields('b', array('rid'))
->condition('module', $module, '=')
->condition('permission', $perm, '=');
+ if (!empty($delta)) $query->condition('delta', $delta, '=');
$result = $query->execute();
foreach ($result as $record) {
$ret[] = $record->rid;

Hello!

This module does not work as I expect and has many bugs. I've hacked it (v. 1.5) and it works fine now. It is quick fix, maybe not beauty but it works well :)
If someone intersted in, it is available on this link below:
http://internetexperts.pl/block_access.zip
block_access by MKozlowski

PEACE!

The attached patch is a correctly formatted version of the contents of comment #21. It works for me.

Reviewed and tested the above patch (#23) and works.

This patch doesn't quite cut it, as it breaks other use cases, but it pointed me in the right direction and I should have a working update shortly.