Hi guys,
I just threw this together tonight. It’s is my first run at a
proposal for a permissions scheme. I welcome your feedback.
My main priority is to create the best, most thorough permissions
scheme available for any blog. I take the requirements for this to be
as follows:
- provide a simple setup for entry-level bloggers (similar to
wordpress permissions) - provide granular permissions control for expert users
- allow for hierarchical style permissions (similar to wordpress
permissions) - provide something that will scale easily with changes to typo
- make sure that the consequences of all permissions are completely
computable using a standard set of algorithms that blindly computes
access based off of a well designed database structures; thus, there
should be no “if superuser then…” type of conditionals in the code. - back it up with the appropriate database tables (of course); the
sql for this will be in the next email (it was too large to be
included in this email)
Toward this end, I envision the following different kinds of
permissions types, each of which will be treated as logically
independent from each other:
- Read
- Edit
- Create
- Delete
- Configure
Moreover, we have the following different kinds of permission scopes.
This set of scopes is treated as a scale; with permission privileges
increasing as the numbers increase.
- the scope covering things that one owns
- the scope covering things one owns, plus those beneath ones
permission level - the scope covering all things
These scopes are intersected with the permission types to yield
meaningful permission boundaries.
We then have master permission zones:
1000 Content
2000 Blog Settings
3000 Sidebars
Each of these has sub types:
Content
1001. Comments
1002. Post Drafts
1003. Published Posts
Blog Settings
2001. Blog users
2002. Blog theme settings
Sidebars
3001. Blog Roll Sidebar
The idea here is that you can add as many different sub-types as you
want. For example, it may be appropriate to add a content subtype of
“Moderation Queue” and/or “Spam Queue.” There is plenty of room for
these and other sub-types.
The permission boundaries are applied either (a) to the master types
(which applies to all subtype permissions) or (b) to the subtypes
(treated as atomic units of permission that override master type
settings).
So where are these permission boundaries applied? They are applied in
user roles:
- Default Permission; master role = none
- Anonymous User; master role = 1
- User; master role = 1
- Guest Author; master role = 1
- Author 1; master role = 4
- Author 2; master role = 4
- Author 3; master role = 4
- Editor 1; master role = 4
- Editor 2; master role = 9
- Editor 3; master role = 10
- Sidebar Admin; master role = 1
- Admin 1; master role = 10
- Admin 2; master role = 12
- Admin 3; master role = 12
- Super User; master role = none
Master roles are the roles from which permissions are inherited.
Thus, the user inherits the default permissions of the Anonymous
user. These inherited values may be overridden, but if not
overridden, then they keep the database from being overrun by
redundant data (e.g., there doesn’t need to be an entry allowing for
every role to read comments, because that’s inherited).
Moreover, these are conceived of as hierarchically organized. Author
2 can edit author 1 posts but not vice versa. Editors can edit author
posts, but not vice versa.
The way that this is set up allows you to enter permissions for
Author 1 once, and then other 2 author types get the same
permissions, but sits atop it in the hierarchy (see the sql in the
next email – there is as “level” field in the user_roles table that
determines this hierarchy)
The user table is keyed to the these roles. So the beginner user
simply assigns users to one of the above pre-made roles, and never
needs to know about the details. Expert users can edit these types
and create new roles to meet their security needs.
This is kind of a cryptic explanation. I’m hoping that the sql in the
next email that outlines the database portion of it makes the
implementation more obvious.
In any case, all of this is manifest in the sql for the database
tables and their contents; all of these are new tables, except the
“alter table” for the users table at the end. The SQL will be in the
next email.
David King L.
(w) 617.227.4469x213
(h) 617.696.7133
One useless man is a disgrace, two
are called a law firm, and three or more
become a congress – John Adams