hello

in D7 core, we still don't have this sort of permissions.

please port it :)

Comments

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

StatusFileSize
new9.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)

Status:Active» Needs review

subscribing

nice;)

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new9.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).

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

sub

Subscribe

Subscribe

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

StatusFileSize
new19.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!"

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.

Subscribe

subs

subs

any new developments?

Title:D7 portDrupal 7 port of Administer Users by Role

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

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

Subscribing

Subscribing

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

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

Issue tags:+Fixed #22 and some other issues
StatusFileSize
new2.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.

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.

Category:feature» task
Priority:Normal» Major

yes, time for a d7 branch?

Agreed. Let's get this module legit.

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.

StatusFileSize
new1.69 KB

Made some changes, feel free to try it out.

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

#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.

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

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.

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.

subscribe

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...

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

Any chances of a D& release please?

Thanks
Jaya

@columbus1492 change _administerusersbyrole_can_edit_user($account) from this:

<?php
/**
* 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:

<?php
/**
* 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.

StatusFileSize
new6.67 KB

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

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

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

Thanks
Jaya

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?

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?

StatusFileSize
new8.39 KB
FAILED: [[SimpleTest]]: [MySQL] 6 pass(es), 1 fail(s), and 0 exception(s).
[ View ]

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.

StatusFileSize
new8.39 KB

updated patch

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?

Subscribing

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.

<?php
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.

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.

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.

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:

<?php
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.

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?! ;)

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?

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

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.

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

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

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.