i’ve been pretty slammed with work and extracurricular projects, but i still intend on expanding this. the files included in the post should give you a (mostly) working example, feel free to hit me up on irc (irc://irc.freenode.net) nick jmcneese for help.

Keep up the good work!

i will be revisiting this soon, with action-level control, and unlimited groups. stay tuned.

the driving reason was so that this would be “plug-n-play”, without having to muck up your tables to make it work.

the performance hit on an indexed set of tables when doing a simple join is negligible. unless you really need that extra .0001 sec, this is really the best bang for your buck.

Thanks for sharing this. I see you went for a polymorphic “permission” model to store all permission data for all models in a single table, rather than add the columns to the original model’s tables themselves, as in the original xaprb implementation and also Martin Radosta’s version.

Just wondering what the thinking was behind this decision and what the performance hit might be?

“I admit I will have to look more into the behaviour to see how it properly works before dismissing it.”

hey, thanks! that’s generally the rule of thumb that will prevent getting roasted by the developer of said code.

like i said regarding the 32 group limit, feel free to update the behavior accordingly. one of these days i’ll do it, unless someone beats me to the punch.

one thing to really think hard about: bits and bitwise operators are not some magic trick that baron conjured up. they are a very useful and widespread way to pack lots of data into a small space. the operators allow us to query that data with very little cost. using bits for permissions has nothing to do with the 32 group limit. that limitation is mine, due to the nature of the project this was built for, as stated in my previous post. most RBAC systems that are geared for thousands (if not millions) of objects will be geared this way, because it’s simple The Right Way To Do It. can it be done in another way? sure. would the other way work? sure. is the other way good? (qua simplicity, scalability or performance), not so much. i mean, while unix permissions are presented in octal format, you are aware they are stored as bits, right?

so, aside from the artificial limitation of this particular implementation in regards to 32/64 groups, what exactly do you see as inflexible about this?

I admit I will have to look more into the behaviour to see how it properly works before dismissing it.

However, I do understand the purpose of the behaviour (I’ve read Baron’s post several months back). I just found 32 groups very limiting, it would be appreciated if you can show an implementation of the system with only 1 group owner per object, as is in Unix.

My idea does take more of a performance hit and is not ingenious as Baron’s use of bitwise arithmetic, but I was thinking of flexibility first and performance after. Of course, when that performance hit starts to show, then a revised solution is needed. But just to clarify, what I was advocating was in regard to row-level permissions, not controller/action permissions. So I did understand the purpose. Now thinking of a way to make this both flexible and efficient is something I’ve struggled to find.

On a side note: you should be able to do syntax highlighting on a shared wordpress server. Check out this article on the section “posting source code”: http://support.wordpress.com/code/