Support from Acquia helps fund testing for Drupal Acquia logo

Comments

lpalgarvio’s picture

note: role delegation is porting (the permissions aren't in D7 either)
http://drupal.org/project/role_delegation

ddyrr’s picture

FileSize
9.49 KB

Here's the D7 version. I also fixed a small bug (if a user has multiple roles, it wouldn't let an admin edit someone with the role for which they have access to edit if the role came second in the list). I also added another small change that I thought worked better (it checks for administer users access before checking the additional role access so the user doesn't get additional access denied messages including the name of the user they can't edit)

bigdave’s picture

Status: Active » Needs review

subscribing

lpalgarvio’s picture

nice;)

jyee’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
9.48 KB

ddyrr, thanks for the port work. The module is working as expected, however there were a few minor issues that should be resolved before the maintainer could add the port to CVS.

I've mad a few changes to remove the automatic CVS tagging and CVS lines in the info and module files. Also ddyrr had added a check for "administrate users" on line 34 of the module file, which seemed unnecessary (at least i didn't encounter any issues with removing it and it's not in the latest d6 version of the module).

jyee’s picture

Status: Reviewed & tested by the community » Needs work

hrm... just found an error.
Line 29: if (arg(0)==='admin' && arg(1)==='user' && arg(2)==='user' && arg(3)==='create') {
checks for a url like /admin/user/user/create

In D7, the user create form is at /admin/people/create

Docc’s picture

sub

bradjones1’s picture

Subscribe

eric.chenchao’s picture

Subscribe

chrisgross’s picture

What is the status of this port? Has the error in #8 been fixed? Is the port in #5 safe to use?

chrisgross’s picture

FileSize
19.19 KB

I ran into two errors using this module and have fixed them:
- arg(2) now checks for "people", instead of "user", following the proper D7 path.
- user_load syntax has been corrected from user_load( array('uid' => $uid) ) to simply user_load($uid)
This was producing the following message when editing a user: "Warning: array_flip() [function.array-flip]: Can only flip STRING and INTEGER values!"

chrisgross’s picture

Can someone explain to my why "authenticated user" has been excluded from this module? If I remove a role from a user, he becomes invincible and cannot be edited or deleted. I can see that the role > 2 condition exists, which is simple enough to change to >1, but the use of DRUPAL_AUTHENTICATED_RID to bypass the ability to edit authenticate users without a roles baffle me. I am ready to take the if ($rid === DRUPAL_AUTHENTICATED_RID) {continue;} lines out of this module, unless someone can explain to me why they exist in the first place. I don't like the idea of giving a user superpowers by removing all his roles.

MathRo’s picture

Subscribe

elgandoz’s picture

subs

elgandoz’s picture

subs

lpalgarvio’s picture

any new developments?

DamienMcKenna’s picture

Title: D7 port » Drupal 7 port of Administer Users by Role

Clarifying the title so it's more obvious when listed in the dashboard.

joryhogeveen’s picture

Is the latest D7 port post stable? I'd like to use it on a live website :)

Taxoman’s picture

Subscribing

amanire’s picture

Subscribing

jenna.tollerson’s picture

Subscribing. Is there a task I can do to get this moving?

Frederic wbase’s picture

Hello

Ive tested #11 and it works fine but maybe for useability it would be better to hide the edit links on the people overview page if the currently logged in user doesn't have the permissions to edit that user.

grts

frederic

zilverdistel’s picture

Issue tags: +Fixed #22 and some other issues
FileSize
2.01 KB

I fixed:

  • the usability issue in #22
  • multiple roles where not handled right, every role should be checked, if access was ok for the first role, the other roles were not checked any more

I also added edit and delete permissions for 'Authenticated users'. Checking all roles made this possible.

zilverdistel’s picture

Status: Needs work » Needs review

Also, I think it would be more convenient to hava a development branch for the drupal 7 version. We could move along much quicker, since we could handle separate issues.

Taxoman’s picture

Category: feature » task
Priority: Normal » Major

yes, time for a d7 branch?

Winn’s picture

Agreed. Let's get this module legit.

RKS’s picture

I just tested this on my site.

It works in title in that you can use the permissions correctly and the functions they assign work. There are a few things to note, however.

1) You must grant the administer users permission. The other permissions take care of *some* of the trouble with this. If a user can edit only a certain role, they can only edit that role.

2) This does not block them from doing other nasty things like blocking ALL users. If you give them administer users and none of the module provided options, they cannot edit, they cannot create, they cannot delete, but they can still block.

I'm wondering if this module would work better outside of the administer users. If you allow them to create, they can create. If you allow them to edit, they can edit. Do this without involving administer users and you block them from doing all of the other things you haven't designed the module to block.

if you cannot/don't want to take the module outside of administer users, I think you need to add some more permissions for things like block user of role a, b, c, etc and permissions for EVERYTHING administer users provides normally. You've done a good job taking care of some of these default issues but you should really take it one step further and take care of everything.

That's my thoughts on it.

geek-merlin’s picture

vikfroberg’s picture

FileSize
1.69 KB

Made some changes, feel free to try it out.

geek-merlin’s picture

ad #29: what did you do from which starting point?
to collaborate on this efficiently patches are needed...

vikfroberg’s picture

#30

I just went all crazy with the latest in this thread. (#23)

  • Removed edit link from user page, if no acces
  • Changed permission machine names to use rid instead of name
  • Changed access callback to user/%user/cancel instead
  • Fixed so that "can edit" and "can delete" functions did work with multiple roles
  • Removes remove account link if I dont have access

EDIT: Removed hook_init function since I remove links to the page instead of redirect.

geek-merlin’s picture

sounds reasonable. seems you don't use git, do you?

vikfroberg’s picture

Well I do use it but I tried to clone your sandbox project and it was empty so I just downloaded the latest. If you have a projekt that I can work agains I love to help out.

columbus 1492’s picture

Hello,
unfortunately the "D7 port of Administer Users by Role" described and posted above doesn't work under D7.12. Only the admin role can create/delete users. Every other role gets the access-denied-message. Can anybody help. Would be very nice...
Thanks a lot.

zilla’s picture

subscribe

rosell.dk’s picture

I don't understand - why did axel.rutz create a new sandbox project? Why not create a 7.x dev branch on this module?
Subscribing, btw...

alesr’s picture

@columbus1492
Did you enabled administer users permission?
It is in #27.

j4’s picture

Any chances of a D& release please?

Thanks
Jaya

aronne’s picture

@columbus1492 change _administerusersbyrole_can_edit_user($account) from this:

/**
 * Custom access callback for edit user.
 */
function _administerusersbyrole_can_edit_user($account) {
  
  global $user;
  if ($account->uid == $user->uid) {
    return TRUE;
  }
  if ($account->uid == 1) {
    return FALSE;
  }

  $permitted = TRUE;
  foreach ($account->roles as $rid => $role) {
    $permitted = user_access('edit users with role '. $rid);
    if (!$permitted) {
      return FALSE;
    }
  }
  return TRUE;
}

to this:

/**
 * Custom access callback for edit user.
 */
function _administerusersbyrole_can_edit_user($account) {
	global $user;
  
	if($account->uid == $user->uid)
		return TRUE;
  
	if($account->uid == 1)
    	return FALSE;
	elseif(user_access('edit users with role '.DRUPAL_AUTHENTICATED_RID))
		return TRUE;
  
	foreach ($account->roles as $rid => $role) {
		if($rid == DRUPAL_AUTHENTICATED_RID)
  			continue;
		if(!user_access('edit users with role '. $rid))
			return FALSE;
	}
	  
	return TRUE;
}

It works for me.

Heorhi Lazarevich’s picture

FileSize
6.67 KB

#29 + #39 work for me under D7.12 with one bag (see attachement)
screenshot

bachbach’s picture

what a mess here ;)
however thanks for the work
#29 + #39 works for me

j4’s picture

Works for me too..A proper release would be highly appreciated.

Thanks
Jaya

ñull’s picture

Version: 6.x-1.4 » 6.x-1.x-dev
Status: Needs review » Reviewed & tested by the community

Subscribing

Great that you guys tested this, but isn't it time for at least a 7.x-1.x-dev release?

MD3’s picture

Guys, thank you so much! This was life saving. Just a suggestion, can we add some hooks so other modules can create more conditions to limit when a user can be edited?

Totally agree with ñull here, how do we get this thing in dev at least?

univate’s picture

Here is a patch against 6.x-1.x-dev with #29 + #39

Status: Reviewed & tested by the community » Needs work

The last submitted patch, administerusersbyrole-908424-45.patch, failed testing.

univate’s picture

updated patch

hoZt’s picture

This issue request was started back in 2010. Can we get a 7.x dev branch up for this and then track any remaining remaining bugs as new issues?

_ Mazzhe’s picture

Subscribing

NobuT’s picture

I don't know if this is a common issue to D6 and D7, but a user who doesn't have the permission to delete still can delete by bulk operation (update). I don't know if there's any hook api to check if a user can be deleted. So, the only thing I could do is to implement hook_user_delete and throws an exception there.

function administerusersbyrole_user_delete($account)
{
  $permitted = TRUE;
  foreach ($account->roles as $rid => $role) {
    $permitted = user_access('delete users with role '. $rid);
    if (!$permitted) {
      throw new Exception('Cannot delete user '.$rid.' '.$role);
    }
  }
  
  return;
}

Does anyone think of a better way? Ideally, the user who doesn't have the permission to delete the selected user should get a gentle error before proceeding.

geek-merlin’s picture

huh, what a mess...

maybe i did not state it clear enough in #28 that i already have a port and use it in production.
axel.rutz's sandbox: Administer Users by Role D7 | drupal.org

i really think we should merge efforts and will grant comaintainership to anyone who likes to help.

edit: this would also give us a separate issue tracker for the d7 branch so not to clutter up this one.

NobuT’s picture

Thank you, axel.rutz! #28 works way better than #29+#39 for my situation. I'll be using it. I wish someone (like you?) could be a co maintainer for D7.

That said, #28 allows a user who doesn't have the permission to edit to block any user. I'll post an issue to your sandbox.

mrfelton’s picture

Using the sandbox project (thanks @axel.rutz). However, if you give a role only the ability to 'Create users', they can not actually access /admin/people/create. Why? Because Drupal core does this:


function user_register_form($form, &$form_state) {
  global $user;

  $admin = user_access('administer users');

  // Pass access information to the submit handler. Running an access check
  // inside the submit function interferes with form processing and breaks
  // hook_form_alter().
  $form['administer_users'] = array(
     '#type' => 'value',
     '#value' => $admin,
  );

  // If we aren't admin but already logged on, go to the user page instead.
  if (!$admin && $user->uid) {
    drupal_goto('user/' . $user->uid);
  }

If a user is logged in, and they try to access the user create page, and they do not have the 'administer users' role, they get redirected back to the user page.

mrfelton’s picture

I have filed a bug report against Drupal Core at #1671182: Ability to better control wether user_register_form is built in admin mode.

Oh, and @smokris, could we get a D7 branch of the codebase please?! ;)

MD3’s picture

mrfelton,

You have opened a can of worms! Honestly it would be nice if Drupal Core just included this module by default as it's crazy not to have that kind of granularity on user administration!

Since I have personally emailed smokris with no response now, I keep meaning to do this for this project, but currently don't have time:
http://drupal.org/node/251466

Maybe someone else can do this get the ball rolling on getting an official D7 branch?

mrfelton’s picture

Started the ball rolling here #1673662: Offering to maintain administerusersbyrole module. Also contacted Steve by email.

mrfelton’s picture

Status: Needs work » Fixed

I'm on the maintainers list now (thanks Steve). I have fixed up Axel Rutz's initial port, and all 1400 odd tests are now passing. Code is in a 7.x-1.x branch, and I have cut a beta release. There is no D6->D7 upgrade path yet.

DamienMcKenna’s picture

So it isn't forgotten about: #1674716: D6 -> D7 upgrade script

MD3’s picture

Nice work mrfelton! Way to go and keep it up!

lpalgarvio’s picture

indeed, nice job =) in times like this, could use a +1/Like button in the issue tracker!

Status: Fixed » Closed (fixed)
Issue tags: -Fixed #22 and some other issues

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