I have a hierarchical user structure, so every user has a entity reference field that points to another user - his/her supervisor.

The thing is that I need to give every user the permission to modify/delete the users that are under him/her in the hierarchy but to no one else.

It is a bit more complicated due to the fact that the hierarchy can be quite high, so a user has to be able to modify even users that points to someone (as to their supervisor) who points to him.

I've Googled for quite a few minutes but didn't find any solution whatsoever. I also need to implement it with my module so programmatic approach would be proffered to another module.


You need to define your own access call back for the menu items. For example: implement hook_menu_alter and changes the access callback for item['user/%user/edit'] and item['user/%user/cancel'] to your own custom access callback. I have not tried this myself yet, but it is something along these lines:

 * Implements hook_menu_alter.
 * Check access for forum menu item.
function MYMODULE_menu_alter(&$items) {
  $items['user/%user/edit']['access callback'] = 'MYMODULE_access_callback';
 * Callback to disallow access for the anonymous user.
function MYMODULE_access_callback(){
  global $user;
  // if the global user (current user) satisfy the criteria
  // then return true else false.
  // you might not have to load the user from the menu item
  // as it may be already loaded and passed to the page and access callback
  // see hook_menu

It might be a better idea though to define your own menu items and handle the operations on your own instead of altering the user menu items.

| improve this answer | |
  • Thanks, this should work. Just to be clear what exactly do you mean by defining my own menu items? I mean like deleting the default user/edit and creating my own? If so, is there any documentation of it or do I have to 'reverse engineering' and find myself? – Petrroll Aug 22 '13 at 19:04
  • I meant by adding your own module, and in you module define cutome menu items in your hook_menu (custom pages). i.e. (example.com/user/%user/custom_operation) where custom operation could be edit2 so it does not overwrite the original default user edit page. Then you implement your page callback (perhaps drupal_get_form and a page arguent where you pass the user edit form as form id) then you can do what ever you do on the page instead of having to worry about altering default drupal access callbacks. – awm Aug 22 '13 at 20:02
  • Yep, that sounds doable. – Petrroll Aug 24 '13 at 16:42

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.