After upgrading to the 2.x version of this module from the 1.x version, editing by role permissions do not work. 'Access the users overview page' and 'Create new users' both work as expected.

It's also possible to edit users via the update options on the user overview page, so I believe the problem is with the access callback for user/%user/edit.

For reference, we are also using role_delegation, userprotect, and role_export

Comments

AdamPS’s picture

Status: Active » Postponed (maintainer needs more info)

Thanks for the report.

The permissions work OK for me and are validated in the automatic tests, so I guess there must be something about your system that is different. You say "permissions do not work" - please can you be as specific as possible about what you see and where you think it differs from what ought to occur?

Here are some suggestions for ways to provide more information so that I can reproduce the bug.

  • Can you provide a sequence of steps that will produce this bug starting from a clean install?
  • Can you try disabling the other modules you mentioned on a test site to see if the problem still exists?
jastraat’s picture

The menu items for user edit specifically return access denied errors. The edit links next to each user appear, the user admin list is limited to the users with roles that the current user should be able to edit, and all bulk operations work. However clicking the edit link results in an access denied error.

AdamPS’s picture

Title: Edit by role does not work in 2.x branch » Module is not compatible with userprotect
Priority: Major » Normal

It looks as if the problem is related to userprotect which also overrides the access callback for 'user/%user/edit' and 'user/%user/cancel'. Drupal only allows one function for access callback - whichever hook_menu_alter gets called second will take precedence.

As far as I can tell this behaviour is the same in the 1.x branch. Perhaps what had happened before you upgraded was that this module was taking precedence and so userprotect wasn't being called??

I'm not sure if there is anything I can do to help you here. You have installed two modules that define different behaviour for the same function and Drupal will only call one of them. If in your case you are confident that you want this module to handle access for 'user/%user/edit' and want to ignore userprotect, then you can set this using hook_module_implements_alter, see https://api.drupal.org/api/drupal/modules!system!system.api.php/function.... Or possibly if you disable one of the modules then enable it again you can get them to be called the other way round - I'm not sure exactly how Drupal decides the order.

Please let me know if you think my analysis is wrong, or if you have any suggestions for a fix, otherwise I think I have to close as "works as designed"/"won't fix".

jastraat’s picture

Adam, you are correct; disabling userprotect allowed users with the admin by role permissions to edit users. I'd just suggest mentioning this incompatibility on the module page. Thanks for investigating!

AdamPS’s picture

Component: Code » Documentation
Category: Bug report » Task
Status: Postponed (maintainer needs more info) » Needs work
AdamPS’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

AdamPS’s picture

Starting with the most recent build, this module now has a dependency on chain_menu_access. This means that the behaviour should be much better for interacting with other modules.

If anyone is able to test userprotect with the newer version and report back on how it works that would be useful to know.

dzy’s picture

I installed userprotect 7.x-1.2 and administerusersbyrole 2.0, they are working together.