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: 1. provide a simple setup for entry-level bloggers (similar to wordpress permissions) 2. provide granular permissions control for expert users 3. allow for hierarchical style permissions (similar to wordpress permissions) 4. provide something that will scale easily with changes to typo 5. 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. 6. 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: 10. Read 20. Edit 30. Create 40. Delete 50. 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. 1. the scope covering things that one owns 2. the scope covering things one owns, plus those beneath ones permission level 3. 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: 1. Default Permission; master role = none 2. Anonymous User; master role = 1 3. User; master role = 1 4. Guest Author; master role = 1 5. Author 1; master role = 4 6. Author 2; master role = 4 7. Author 3; master role = 4 8. Editor 1; master role = 4 9. Editor 2; master role = 9 10. Editor 3; master role = 10 11. Sidebar Admin; master role = 1 12. Admin 1; master role = 10 13. Admin 2; master role = 12 14. Admin 3; master role = 12 15. 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 Landrith (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 ------------------------------------------------------- public key available upon request |
_______________________________________________ Typo-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/typo-list
