通用权限的思路。只是一个简单的思路。
2008-04-29 13:36
218 查看
面对权限,我们要解决几个的问题。
第一个就是:我们的软件里面有哪些功能? —— 给用户自己维护角色作准备
比如添加新闻、添加产品、客户信息维护、合同管理等等,当然还可以细分一下,
客户信息维护又可以分为:客户基本信息、客户的联系人、客户报价、客户的合同等。
我的习惯是建立一个表,叫做功能结点表。
这个表可以生成左面的功能树,也可以记录项目里面一共有哪些功能。
这里的一个功能指的是两个页面,一个是列表页面,一个是表单页面。
列表页面包括查询、导出数据等功能,表单页面又可以再往下继续划分,就是可以在包含子功能结点。
这样一个项目里的功能就全部记录到了一个表里面。
功能结点表的主要字段
FunctionID
ParentID
Title
URL
...
其它字段略。
第二个问题:哪些人可以访问到那些功能结点?
这个问题呢就要引入“角色”或者“用户组”的概念了。
我们建立一个角色表来记录一个角色拥有的功能结点。
我们可以写一个程序,让客户自己来维护,也就是说用户可以自己添加、修改“角色”。
然后把人员和角色关联起来就可以了。
角色表的主要字段
RoleID
TItle
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
第三个问题:详细权限的划分
一个页面可能会有很多的功能,比如可以查看、查询、添加数据、修改数据、删除数据(又可以分为逻辑删除和物理删除)、导出数据等。
而一个人(或者说是角色)来到这个页面后(获得了访问权限),不一定会拥有上面的全部的权限。
这样就需要再详细区分一下。
这样的话我们在加一个字段就可以了,通过这个字段来判断登录人有哪些具体的权限。
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
详细权限
第四个问题:资源的访问权限
这个我还没有想好怎么解决。
就是说同一个页面,业务员只能看到自己的客户信息、并且可以维护,
然后业务一部门的经理只能看到业务一部门的业务员的客户信息,不能看到其他业务部的客户信息
再然后是业务部的总经理,他可以看到所有业务员的客户信息。
最后就是,不知道大家有没有遇到过“内勤”这个职位,就是说业务员只管联系客户,不用自己录入客户信息,
而往电脑里录入信息的工作就全交给内勤了。
再往下说就更烦了,一个业务部可能只有一个内勤,也可能有多个内勤,一个内勤会对应多个业务员。
好了先不说了,好像有点跑题了,这个就当作是特利吧。
前三个问题都不需要引入部门的概念,但是第四个问题就不得不考虑部门了。
以上是我的思路,不知道能不能把权限的问题,从粗粒度上说清楚。
有不对的请指出,大家一起研究。
第一个就是:我们的软件里面有哪些功能? —— 给用户自己维护角色作准备
比如添加新闻、添加产品、客户信息维护、合同管理等等,当然还可以细分一下,
客户信息维护又可以分为:客户基本信息、客户的联系人、客户报价、客户的合同等。
我的习惯是建立一个表,叫做功能结点表。
这个表可以生成左面的功能树,也可以记录项目里面一共有哪些功能。
这里的一个功能指的是两个页面,一个是列表页面,一个是表单页面。
列表页面包括查询、导出数据等功能,表单页面又可以再往下继续划分,就是可以在包含子功能结点。
这样一个项目里的功能就全部记录到了一个表里面。
功能结点表的主要字段
FunctionID
ParentID
Title
URL
...
其它字段略。
第二个问题:哪些人可以访问到那些功能结点?
这个问题呢就要引入“角色”或者“用户组”的概念了。
我们建立一个角色表来记录一个角色拥有的功能结点。
我们可以写一个程序,让客户自己来维护,也就是说用户可以自己添加、修改“角色”。
然后把人员和角色关联起来就可以了。
角色表的主要字段
RoleID
TItle
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
第三个问题:详细权限的划分
一个页面可能会有很多的功能,比如可以查看、查询、添加数据、修改数据、删除数据(又可以分为逻辑删除和物理删除)、导出数据等。
而一个人(或者说是角色)来到这个页面后(获得了访问权限),不一定会拥有上面的全部的权限。
这样就需要再详细区分一下。
这样的话我们在加一个字段就可以了,通过这个字段来判断登录人有哪些具体的权限。
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
详细权限
第四个问题:资源的访问权限
这个我还没有想好怎么解决。
就是说同一个页面,业务员只能看到自己的客户信息、并且可以维护,
然后业务一部门的经理只能看到业务一部门的业务员的客户信息,不能看到其他业务部的客户信息
再然后是业务部的总经理,他可以看到所有业务员的客户信息。
最后就是,不知道大家有没有遇到过“内勤”这个职位,就是说业务员只管联系客户,不用自己录入客户信息,
而往电脑里录入信息的工作就全交给内勤了。
再往下说就更烦了,一个业务部可能只有一个内勤,也可能有多个内勤,一个内勤会对应多个业务员。
好了先不说了,好像有点跑题了,这个就当作是特利吧。
前三个问题都不需要引入部门的概念,但是第四个问题就不得不考虑部门了。
以上是我的思路,不知道能不能把权限的问题,从粗粒度上说清楚。
有不对的请指出,大家一起研究。
相关文章推荐
- 通用权限的思路。只是一个简单的思路。
- 通用权限的思路。只是一个简单的思路。
- 通用权限的思路。只是一个简单的思路。
- 如何给多个子系统设计一个简单通用的权限管理方案?(详细讲解及源代码下载)
- 通用权限管理系统组件 (GPM - General Permissions Manager) 中最简单的例子程序,如何时间通讯录管理
- 一步一步写一个简单通用的makefile(二)
- 一步步实现一个简单的下拉刷新上拉加载的通用框架
- 一个简单的通用序列数据结构
- 一个简单的实现不同权限的用户登录后看到不同的菜单设计的数据库表清单
- SSH实现一个简单的权限控制实例(三)
- 一个基于RBAC0的通用权限设计清单
- 【Linux系统 简单分配权限】以root的身份 分配 某用户 的一个文件权限
- iOS开发:代码通用性以及其规范 第二篇(猜想iOS中实现TableView内部设计思路(附代码),以类似的思想实现一个通用的进度条)
- 随机数模拟数据变化,只是我自己的一个小思路
- 走火入魔通用权限管理之权限设计入门整体思路图解
- 通用权限的思路。带有数据库关系图
- 一个简单的以User权限启动外部应用程序
- 一个简单的通用协议测试软件(平台)
- 编写一个简单通用的makefile
- SSH实现一个简单的权限控制实例(二)