Posted by Mega-Mario

---

(well I'm referring to admin-mode editprofile as edituser)

Edituser has $blockroot, which basically checks if an user is root or not, and if they're not, prevents them from promoting someone to root.

One issue with this method is that it only works well with an Acmlmboard-powerlevel based groups scheme. Let's say you have groups organized differently. You have two groups, and both are able to use edituser. One is able to do certain things, and the other one is able to do other things, perhaps more powerful. A member of the first group could use edituser to move themselves to the other group.

---

This is code from when Kawa introduced the first version of the 'Root Admin' powerlevel. It was built on the legacy power system. (IE: id 4 is root etc). You'll find a lot of code similar to this one that directly tests using the old system. If you see anything that refers to or uses the AB legacy (fixed power level) by number) please mark it for replacement.

Hmm.. Well the goal should keep in mind that our perm set may be nothing like the next guy's. I guess this is uncharted territory as we've not really explored the system in a non-hierarchical form.

#1 * - We can block it per user and group with revoke perms. This is currently limited to 'all or nothing' which could be changed.

#2 * - Possibly. it was just a root user situation we could build a super user mark (like default group, and etc) and build a perm for edit-superuser. However I don't see that being the best solution. (too inflexable)

#3 * - Correct. I agree. Some other board may have someone who they would like to only edit from "Normeys, Mods, but not "Happy Eilte" etc.

#4 * - You mean "default is if you can 'edituser' you will be able to set it to any group that doesn't explicitly have a define?" Well that would work if I read you correctly, but it wouldn't open up the ability to have more fine controls.

I would like to break down the admin functions to much finer perms if we can get the time to do so. I was thinking today where someone having a 'full mod with ban ability' would be useful in some context. They would only be able to set the person's group to 'ban' or 'normal'. (Well and other thing as you wish.. but it's immaterial.) I think that kinda is in line with this as well.

As long as the front end can easily handle it, we could control this in the admin/group editor. We can build it so it makes a perm for each one if so choose.

Thoughts? (sorry I was doing this at lunch so I may not be completely clear due to the rushing to finish it. Let me know if you need clarification)

Indeed. That would provide a very flexible interface, and it would be no more confusing db side than the rest of the perms. Hopefully no one will need to use direct sql to work with them when we are though, (save developers/coders of course)

Also if you haven't looked at it yet (I forgot to mention it) Bouche started to build some functions for permissions. it's in the file testbed.php public_html/

You might find it of some use, and if not it's worth a read