代码改变世界

通用权限的思路。只是一个简单的思路。

2008-04-29 13:36  金色海洋(jyk)  阅读(6752)  评论(25编辑  收藏

面对权限,我们要解决几个的问题。

第一个就是:我们的软件里面有哪些功能? —— 给用户自己维护角色作准备

比如添加新闻、添加产品、客户信息维护、合同管理等等,当然还可以细分一下,
客户信息维护又可以分为:客户基本信息、客户的联系人、客户报价、客户的合同等。

我的习惯是建立一个表,叫做功能结点表。
这个表可以生成左面的功能树,也可以记录项目里面一共有哪些功能。
这里的一个功能指的是两个页面,一个是列表页面,一个是表单页面。
列表页面包括查询、导出数据等功能,表单页面又可以再往下继续划分,就是可以在包含子功能结点。

这样一个项目里的功能就全部记录到了一个表里面。

功能结点表的主要字段
FunctionID
ParentID
Title
URL
...

其它字段略。


第二个问题:哪些人可以访问到那些功能结点?

这个问题呢就要引入“角色”或者“用户组”的概念了。

我们建立一个角色表来记录一个角色拥有的功能结点。
我们可以写一个程序,让客户自己来维护,也就是说用户可以自己添加、修改“角色”。

然后把人员和角色关联起来就可以了。

角色表的主要字段
RoleID
TItle

角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID


第三个问题:详细权限的划分

一个页面可能会有很多的功能,比如可以查看、查询、添加数据、修改数据、删除数据(又可以分为逻辑删除和物理删除)、导出数据等。

而一个人(或者说是角色)来到这个页面后(获得了访问权限),不一定会拥有上面的全部的权限。
这样就需要再详细区分一下。

这样的话我们在加一个字段就可以了,通过这个字段来判断登录人有哪些具体的权限。

角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
详细权限



第四个问题:资源的访问权限

这个我还没有想好怎么解决。

就是说同一个页面,业务员只能看到自己的客户信息、并且可以维护,

然后业务一部门的经理只能看到业务一部门的业务员的客户信息,不能看到其他业务部的客户信息

再然后是业务部的总经理,他可以看到所有业务员的客户信息。

最后就是,不知道大家有没有遇到过“内勤”这个职位,就是说业务员只管联系客户,不用自己录入客户信息,

而往电脑里录入信息的工作就全交给内勤了。

再往下说就更烦了,一个业务部可能只有一个内勤,也可能有多个内勤,一个内勤会对应多个业务员。
好了先不说了,好像有点跑题了,这个就当作是特利吧。


前三个问题都不需要引入部门的概念,但是第四个问题就不得不考虑部门了。


以上是我的思路,不知道能不能把权限的问题,从粗粒度上说清楚。

有不对的请指出,大家一起研究。

2