CB

Upgraded get_groups_below_me to allow supplying a userid other then myid as well as an optional $raw parameter so it outputs an array of gids. Then upgraded get_users_permission, get_user_permission_task, and get_user_moderator to utilize its usage. This results in proper comparison of GID to users gid tree. Will require thorough testing, but quick testing shows it resolves this issue (and probably others we've yet to find).

In the below scenario it doesn't work properly.. or maybe it does.. subject to opinion.

Group 1
- Group 1a
Group 2

In the above Group 1a is the Moderator group, but they can not edit Group 2. It seams to be working as designed as Group 2 is a different parent group, but should it matter? Should moderator access even care what group anyone is? The error (see below) is happening in get_users_permission. It doesn't affect administrators or super administrators because it has a check to see if the user is either/or so they're not subject to child GID trees.

"You cannot ACTION a USERGROUP. Only higher-level users have this power."

Final patch submit for review.

Part 2 changes current SVN to implement a groups above function. It then checks that the "master" has a group above the "user". It then checks that the groups below "master" belong to an admin group. The new checks ensure the "master" is always above the user.

Fixed backend admins not being able to edit themselves

get_groups_below_me keeps the top most group you belong to plus those below you. get_groups_above_me only returned groups above you and didn't keep what you already belonged to. Fixed it so it includes those above you and the top most group you already belong to. Tested the usage experience against J1.5 and works exactly the same (admins can edit other admins in backend even if not self, confirmed j1.5 as well; so seams intended).

Fixed exactly as last patch proposed in r1168 / r1169 for comment.

Thank you very much Kyle for your patience during this review and for the improved proposals and tests.