It became unwieldy though; this project doesn’t need quite that amount of flexibility so I scrapped most of it, including the cool APC constant stuff. I’m sure I’ll come back to it down the road, but for now, it makes for decent blog fodder

A little while ago my brother made such a system. It was split into three parts: roles, objects, and permissions.

Permissions are defined only as the names you give to something, much like what is in an enum. A permissions are contextually relevant to objects.

A permission object is something like a blog post or a forum thread. Its permissions would be read, write, edit, etc.

Finally, a role is a state that the user is in, eg: guest, member, admin.

The way this is laid out in a database is as such:
there is a many-to-many relationship between users and roles; roles each have a unique permission level that is a power of two (1, 2, 4, 8, …); objects are interesting because they are what contain the permissions in a very non-relational way (a comma-separated list of permissions). This order of permissions is important as each permission is implied to have a value that is a power of two. Finally, the permissions table is all numbers; there is a one-to-one relationship between permissions and roles, a one-to-one relationship between permissions and objects, and each permission has a ‘grant’ and ‘deny’ value. These values are just the implied values of the permissions that are in the CSV list in each row of the objects table ORd together.

How does this all end up working? Given a user id, you can find all permissions (from the permissions table) and join on the objects to build up a multidimensional array of bitfields. You can then perform queries of sorts on those to find out if a user can do a certain operation or not.

If you would like further info, feel free to email me. You obviously have my email address stored in your WP db.