【自然框架】之通用权限(四):角色表组

 

      继续,这是第四章了。这里涉及到了资源方面的,不过有点绕,所以这里先介绍一下表结构,在后面的章节里面,再举例子详细介绍。

通用权限想要写的文章目录:(这是第四章)

 

1、 简介、数据库的总体结构
2、 介绍人员表组
3、 介绍组织结构表组
4、 介绍角色表组
5、 介绍“项目自我描述表组”
6、 权限到节点
7、 权限到按钮
8、 权限到列表(表单、查询)
9、 权限的验证
10、 资源方面的权限
11、 角色管理的程序(给客户用的)
12、 权限下放
13、 个性化设置

A、、 【自然框架】之通用权限(外传):杂谈

 

 

 

 

角色表组

 

 

 

      目前有七个表:(有四个是这两天才加上的)
      一、Role_Roles ,记录角色信息,比如角色名称、角色描述、角色拥有的节点等。这个表我也打算可以做成n级分类的形式,因为如果角色多了(比如几百个),不分类的话,看起来就比较乱,但是如何来分类我又没有想好。当然对于一些简单的情况,也是可以不分类的。

      这个角色表Role_Roles记录的是操作方面的,并不包含资源方面。这个角色分为两种:正向角色、拒绝角色。

      1、正向角色
      记录可以做的权限,就是记录下来可以做哪些操作,正向角色不能继承,不能关联,但是可以组合。如果一个人拥有多个正向角色,那么只要有一个角色里面允许,那么他就可以做这个操作。

      2、拒绝角色
      和正向角色相反,他记录的是不可以做的操作。拒绝角色必须“继承”(或者叫做关联)一个或多个正向角色。拒绝角色不能继承拒绝角色。如果一个人拥有了一个拒绝角色,那么拒绝角色里面不允许做的操作就绝对不可以做,不管他拥有的其他的正向角色是如何规定的。

      至于给人员分配角色的时候如何来具体的区分,还没有太完善。

      3、“FunctionIDs”:角色拥有的节点的字段。这个字段的内容是“1,2,3,4”的形式。对于正向角色来说这里记录的就是可以操作的节点,而对于拒绝角色来说,这里记录的就是不可以操作的节点。
这个也是“权限到节点”的关键字段。

字段名 中文名 字段类型 大小 默认值 是否空 说明
RoleID 角色 int 4 1 0 主键
RoleName 角色名称 nvarchar 50 _ 0 角色名称
RoleDescribe 角色描述 nvarchar 50 _ 0 角色描述
RoleKind 角色类型 int 4 1 0 1:正向角色;2:拒绝角色
LinkRoleIDs 关联角色 nvarchar 50 _ 0 拒绝角色有效。
拒绝角色可以关联多个正向角色,但是不能关联拒绝角色。
正向角色不能关联。
ParentID 父节点ID int 4 1 0 父节点ID。为n级分类做预留
ParentIDPath 父节点ID的路径 nvarchar 30 _ 0 父节点ID的路径。为n级分类做预留
RoleLevel 角色层数 int 4 1 0 第几级的角色
Sort 排序 int 4 1 0 序号
FunctionIDs 节点 nvarchar 500 _ 0 角色拥有的功能节点。1,2,3的形式
AddedDate 添加日期 smalldatetime 4 GetDate() 0 记录添加日期
AddedUserID 添加人 int 4 1 0 记录哪个用户添加的
UpdatedDate 最后修改日期 smalldatetime 4 GetDate() 0 记录最后修改日期
UpdatedUserID 最后修改人 int 4 1 0 记录哪个用户最后修改的

      二、Role_RoleButton ,这个表要记录一个节点里的按钮的权限,就是说一个角色拥有的节点里的按钮的权限。如果他和正向角色关联,则说明可以使用这个按钮,如果和拒绝角色关联则说明不能使用这个节点。

字段名 中文名 字段类型 大小 默认值 是否空 说明
RoleID 角色 int 4 1 0 主键
FunctionID 节点 int 4 1 0 外键
ButtonIDs 人员ID nvarchar 200 _ 0 外键

 

      三、Role_RoleColumn,同上,这个表要记录一个角色拥有的节点里的列表、表单或者查询的字段的权限。如果粒度不需要做得这么细的话,那么这个表就可以省略了。
同样如果他和正向角色关联,则说明可以使用这些字段,如果和拒绝角色关联则说明不能使用这写字段。

字段名 中文名 字段类型 大小 默认值 是否空 说明
RoleID 角色 int 4 1 0 联合主键
FunctionID 节点 int 4 1 0 联合主键。外键
Kind 类型 int 4 1 0 1:列表;2:表单;3:查询
ColumnIDs 字段ID nvarchar 200 _ 0 外键

 

      四、Role_RoleUser,角色里的用户,角色和用户是多对多的关系,即一个人可以有多个角色,一个角色可以有多个用户,角色和UserID关联,但是也要加上PersonID的信息。
一个人可以拥有多个正向角色,也可以拥有多个拒绝角色。拒绝角色优先,只要拒绝了那么就不可以使用。

字段名 中文名 字段类型 大小 默认值 是否空 说明
RoleUserID 编号 int 4 1 0 主键
RoleID 角色 int 4 1 0 外键
UserID 用户 int 4 1 0 外键。角色里面拥有的账号ID
PersonID 人员 int 4 1 0 外键。角色里面拥有的用户ID

 

      五、Role_ResourceListCase,“记录列表”的资源过滤方案,就是记录过滤条件,即SQL语句里面的Where后面的查询条件。这个是给GridView级别的控件准备的,在自然架构里面可以给QuickPager的查询条件的属性赋值。这样就可以实现过滤的效果。这个只有“正向”没有“拒绝”。角色和功能节点起到“联合主键”的功能,一个节点可以有多个方案以供选择。但是一个角色和节点的组合只能选择一个方法。

字段名 中文名 字段类型 大小 默认值 是否空 说明
ListCaseID 编号 int 4 1 0 主键
FunctionID 关联节点 int 4 1 0 外键。0:不限制节点;其他:有效的节点
ResourceName 资源角色名称 nvarchar 50 _ 0 资源角色名称
ResourceDescribe 资源角色描述 nvarchar 50 _ 0 资源角色描述
SQL 过滤条件 nvarchar 200 _ 0 SQL语句里的where后面的查询条件
ParentID 父节点ID int 4 1 0 父节点ID。为n级分类做预留
ParentIDPath 父节点ID的路径 nvarchar 30 _ 0 父节点ID的路径。为n级分类做预留
ResourceLevel 资源角色层数 int 4 1 0 第几级的角色
Sort 排序 int 4 1 0 序号
AddedDate 添加日期 smalldatetime 4 GetDate() 0 记录添加日期
AddedUserID 添加人 int 4 1 0 记录哪个用户添加的
UpdatedDate 最后修改日期 smalldatetime 4 GetDate() 0 记录最后修改日期
UpdatedUserID 最后修改人 int 4 1 0 记录哪个用户最后修改的

 

      六、Role_ResourceControlCase ,控件的资源过滤方案,就是记录过滤条件,即SQL语句里面的Where后面的查询条件。这个是给下拉列表框级别的控件准备的。通过这里的条件可以达到过滤数据的效果。同样,这个也有“正向”没有“拒绝”。
 1、一个控件(比如下拉列表框)可以有多个方案,也可以不使用方案,即显示全部数据。
 2、一个资源方案只能给一个控件使用。
 3、一个功能节点里面有查询和表单,而一个表单(查询)里面有可能有多个下拉列表框。

字段名 中文名 字段类型 大小 默认值 是否空 说明
ControlCaseID 编号 int 4 1 0 主键
ColumnID 关联控件 int 4 1 0 外键。关联的控件,即字段
ResourceName 资源角色名称 nvarchar 50 _ 0 资源角色名称
ResourceDescribe 资源角色描述 nvarchar 50 _ 0 资源角色描述
SQL 过滤条件 nvarchar 200 _ 0 SQL语句里的where后面的查询条件
AddedDate 添加日期 smalldatetime 4 GetDate() 0 记录添加日期
AddedUserID 添加人 int 4 1 0 记录哪个用户添加的
UpdatedDate 最后修改日期 smalldatetime 4 GetDate() 0 记录最后修改日期
UpdatedUserID 最后修改人 int 4 1 0 记录哪个用户最后修改的

      七、Role_RoleResource,角色、节点、资源方案的关系。
这是一个关联表,把角色、和资源方案关联起来,由于一个角色里面会有多个功能节点,一个功能节点可能有多种方案(但是只能选一个),有一个表单、有一个查询,而表单和查询里面会有多个下拉列表框这一类的控件, 所以在关联的时候是角色和功能节点做联合主键的作用。好像没说明白,暂时先这样吧,以后我举几个例子就好办了。

 

字段名 中文名 字段类型 大小 默认值 是否空 说明
RoleResourceID 编号 int 4 1 0 主键
RoleID 角色 int 4 1 0 外键
FunctionID 节点 int 4 1 0 外键
ListCaseID 列表过滤方案 int 4 1 0 外键,给分页控件的查询条件用
ControlCaseID 控件过滤方案 nvarchar 200 _ 0 1,2,3的形式,下拉列表框级别的控件用

 

 

      角色表组里面涉及到了“FunctionIDs”、“ButtonIDs”、“ColumnIDs”三个字段,这三个字段就是“项目描述”里面的,“FunctionIDs”即功能节点的ID,“ButtonIDs”即功能按钮(比如添加、修改、删除等)的ID,“ColumnIDs”即字段的ID,也可以说是控件ID,因为一个字段都可以对应一个控件。可能您看着有点晕,不要着急,下一章写完了,您就不会晕了。

数据库说明文档已经更新,请到这里下载:http://www.cnblogs.com/jyk/archive/2009/06/06/1497616.html

希望大家多提宝贵意见 ,谢谢!

 

时间: 2024-09-20 05:55:43

【自然框架】之通用权限(四):角色表组的相关文章

【自然框架】通用权限的视频演示(一):添加角色,权限到功能节点和按钮

      写了几个关于权限的东东,好像大家都不大理解,也不太清楚我的权限到底能做什么,所以想来想去还是弄点视频吧,就是屏幕录像,这样大家看起来就方便了吧.       为了大家便于观看视频,我先说一下视频的步骤.      1.添加角色,选择角色可以使用的功能节点和按钮.      2.选择用户,就是给角色里面添加用户.      3.用用户的账号登录,查看效果.      4.修改角色可以使用的按钮,查看效果.       这里举了一个很简单的例子--新闻维护,有两个角色,一个是"新闻维护&

【自然框架】 权限 的视频演示(二): 权限到字段、权限到记录

      继续.这里演示权限到字段和权限到记录.            权限到字段有两种安全级别,      1.低安全级别.有些项目不需要做到控制每一个字段是否显示,那么就可以采用这种级别.低安全级别就是:如果一个节点里面没有设置可以访问哪些字段,那么就默认为不需要做到控制字段的程度,就是说节点里的字段都是可以访问的.这么做是为了操作方便.       2.高安全级别.有些项目要求非常严格,要严格控制每一个字段是否可以访问,那么就可以采用这种安全级别.高安全级别:如果一个节点里面没有设置可以

【自然框架 免费视频】资源角色的思路介绍(整理了一下以前帖子的目录,请刷新)

  请大家不要忘记点推荐!   源码下载: 自然框架的源代码.Demo.数据库.配置信息管理程序下载 这里介绍一下资源权限的思路,我们来设计一个场景,这个场景大家比较常见的,也是我遇到过的.我们来通过这个简单的实例,来看看资源权限可以如何实现. 资源权限,就是同样的一个表,一些人可以看到一部分信息,另一些人可以看到另一部分信息,还有些人可以看到全部信息,还有--.总之就是根据员工的权力,进行适当的筛选.可以看到一部分,或者可以看到全部.一级可以做什么样的操作(增删改查,导出等).   这里先只介

【自然框架】之通用权限:用PowerDesigner重新设计了一下数据库,有ER图和表关系图

      好像以前做的那个数据库设计大家都没太看懂,究其原因似乎大家都比较习惯使用PowerDesinger来设计.而我用Excel画出来的图大家看着特别别扭,而且还没有总体的图,也没有ER图,所以大家也就没有心情看了吧.呵呵.      PowerDesinger学习了一下,感谢Hayden Han 写的<PowerDesigner使用教程 -- 概念数据模型 >,通过这个文章学会了如何使用PowerDesinger来画ER图,这回画出来的应该是ER图了吧,呵呵.除了ER图,还有表关联图,

【自然框架】之通用权限(一):简介、数据结构

        这次要写一整套的权限方面的文章了,无论我的想法好与不好,先写出来请大家来评判.这个系列我要详细的说明我的权限的思路.想法.实现方式.代码和Demo.可能有人会说,通用是达不到的,最多只能无限接近.恩,对于我来说,能够无限接近就可以了,当然我知道如果要达到这个目标并不是一件容易的事情,有难度才有挑战,才有意思.所以我会在权限方面不断的努力,不断的无限接近通用.也请大家多多帮忙,毕竟一个人的力量是有限的.              通用权限想要写的文章目录:(这是第一章)   1. 

【自然框架】之通用权限(三):组织结构表组

        继续,这是第三章了.拖得有点长,但是我也是一边写,一边在想办法,想怎么做才能让资源权限也能通用起来.看大家的回复也给了我一些提示,我也在修改我的方案.原来打算用来解决一个人虽然在业务一部,但是却可以看业务一部.业务二部的客户信息的情况,但是仔细想了一下,这么做也不行.不过还好,我又找到了另一个方法来解决,而且可以让资源权限更加通用.不过这个详细的方法要放在下一章的角色表组里面来说明了.(这是写这篇之前的想法,写完之后想法又变了.)    通用权限想要写的文章目录:(这是第三章)

【自然框架】之通用权限(八):权限到字段(列表、表单、查询)

   通用权限想要写的文章目录:(这是第八章)   1. 简介.数据库的总体结构2. 介绍人员表组3. 介绍组织结构表组4. 介绍角色表组5. 介绍"项目自我描述表组"6. 权限到节点7. 权限到按钮8. 权限到列表(表单.查询)9. 权限的验证10. 资源方面的权限11. 角色管理的程序(给客户用的)12. 权限下放13. 个性化设置 A. [自然框架]之通用权限(外传):杂谈     列表 myGrid 先说一下myGrid,我会根据Manage_FunListCol表和Manag

【自然框架】之通用权限(二):人员表组

        继续,这是第二章了.本来想在这一章里面介绍三个表组来着,但是我有点写不好的感觉,还是多分几章吧,这一章就只介绍人员表组.第二章到第五章主要是介绍表结构.我是习惯使用Excel来设计表,一开始的时候只能记录表名.字段名.字段类型.字段说明等信息,但是一直没能找到如何使用Excel来体现出来表之间的关系.前一阵子(好像是去年)突然想到了可以使用"图表"+图形(比如箭头)的方式来做表关系,第一章里的那几个图就是这么弄出来的,看着还凑合吧.       至于为什么不用Power

【自然框架】之通用权限(五):项目描述表组

        继续,这是第五章了.我发现了,写文章比写程序还要有难度.   通用权限想要写的文章目录:(这是第五章)    1. 简介.数据库的总体结构2. 介绍人员表组3. 介绍组织结构表组4. 介绍角色表组5. 介绍"项目自我描述表组"6. 权限到节点7. 权限到按钮8. 权限到列表(表单.查询)9. 权限的验证10. 资源方面的权限11. 角色管理的程序(给客户用的)12. 权限下放13. 个性化设置 A. [自然框架]之通用权限(外传):杂谈         项目描述表组