deleted role not deleted from users_roles table
| Project: | Drupal |
| Version: | x.y.z |
| Component: | user system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | hunmonk |
| Status: | closed |
First of all, great addition to the user system to prevent people from changing privelages when you don't necessarily want them to. I spotted a problem though:
I created an access role to give to users who I wanted to be able to edit other users but without allowing them to change access control settings. It worked well, until I went to delete the role. I could delete the role, but when I logged in as a user who previously had that role assigned to them, they still were able to see the 'users' menu, click into it and see the list of users (?q=admin/user) with the 'add user' button and everything. When the user clicks on these links they either get an Access Denied message or are redirected to their own profile, depending on what they click.
To stop the user being able to see that page, their profile had to be saved again. This had the effect of clearing the relevant row from the users_roles table. Previous to that, there was a row left in there showing that they had a non-existant role, despite there seamingly being code to remove those from the table (see below). Any thoughts, anyone?
else if ($op == t('Delete role')) {
db_query('DELETE FROM {role} WHERE rid = %d', $id);
db_query('DELETE FROM {permission} WHERE rid = %d', $id);
// Update the users who have this role set:
$result = db_query('SELECT DISTINCT(ur1.uid) FROM {users_roles} ur1 LEFT JOIN {users_roles} ur2 ON ur2.uid = ur1.uid WHERE ur1.rid = %d AND ur2.rid != ur1.rid', $id);
$uid = array();
while ($u = db_fetch_object($result)) {
$uid[] = $u->uid;
}
if ($uid) {
db_query('DELETE FROM {users_roles} WHERE rid = %d AND uid IN (%s)', $id, implode(', ', $uid));
}
drupal_set_message(t('The role has been deleted.'));
drupal_goto('admin/access/roles');
}
#1
that mess of code for users_roles doesn't even do anything, as far as i can tell--it joins the table to itself by identical uid, then only allows unequal RIDs in the same row to be deleted. well that never happens, since you're joining the table to itself... :)
unless i missed something, we can eliminate that and use syntax similar to the query for the permissions table deletion. attached patch does this.
looks like this bug is present in both 4.7 and HEAD--patch generated against HEAD, but should apply to 4.7 as well
#2
committed to 4.7
#3
Committed to HEAD.
#4