Rainbow.Framework.Permissions
Permissions will basically be one table the way i see with a couple of helper tables or settings.
the idea is to make the permissions very flexible, but also granular, so we can permission anything, and the code and business logic will interpret the permissions appropriate , so for example, we can combine the code for sqlsitemap provide, to join with permissions for the user and roles he is included in, returning only those pages that he has permissions for, so that you can remove all the code, and xsl logic from doing this, and improve the pipeline a little... this is just one small example.
| PermID |
bigint |
This defines the type of object we are permissioning |
primary key, identity, increment 1 |
| ItemType |
smallint |
This defines the type of object we are permissioning |
Page
Module
Application
Site / Portal
Content Item |
| ItemID |
bigint |
|
The primary key field in the item type table, perhaps we should maintain a reference list of all tables, and keys, and the type field should reference that table, and keys... etc... |
| RoleOrUser |
bit |
0 = role, 1 = User
perhaps this should be more flexible? |
is the permission for a user, or role... perhaps we need more types? |
| RoleUserID |
bigint / varchar ?? |
|
the id of the user or role, since user id's have possibly to be emails, or user names in some applications, it might be good to have varchar support |
| HasAll |
bit |
|
if the user is "master" on this object, then this is all we need |
| HasSelect |
bit |
concept can be abstracted in business layer for different puposes |
can view item |
| HasInsert |
bit |
ditto |
can insert item |
| HasUpdate |
bit |
ditto |
|
| HasDelete |
bit |
ditto |
|
| CustomPerms |
varchar |
Maybe perms should be abstracted more to a settings type table, perm Name, perm Value, permID and then we can remove all the bit fields, and the custom perms field into that table... but |
hasmove=1;hasapprove=1;hasmoderate=1 |
( we should add some audit info, like who created the permission and when, perhaps also about updates )
If anyone would like to discuss this in more detail, I propose we open a thread in the developer forum, and begin an archived discussion there. Also, if anyone would like to volunteer for this part of the framework, it's something that can be started now, completely separate from all other work.... build tables, use rainbow db object to connect to db, and create some basic helper methods like
InsertPermissionData(etc....);
GetPermissionDataForObject(int type, string id);
etc....
perhaps also begin thinking about some key places to begin implementation, things like i mentioned for site map, getting modules for a page... things like that... things that might improve performance, or throughput in the database.... also....how will we integrate this into the modules, pages, and portals....we must figure out the ui and changes for security setting pages... as well as how we might get this added to content items....
;look at the sample in secure documents module.... so we can permission individual documents, images, articles, bogs, discussions, pages, links, announcements, etc...etc....
ok, that's my note for now.... later today or tomorrow i will do a write up on Rainbow.Framework.ObjectSettings ( an api that would take the functionality of portal Settings, tab Settings, module Settings, and contetn Item Settings and wrap them into one reusable object ;-)