通用权限的思路
2008-11-26 13:35:45 来源:WEB开发网面对权限,我们要解决几个的问题。
第一个就是:我们的软件里面有哪些功能? —— 给用户自己维护角色作准备
比如添加新闻、添加产品、客户信息维护、合同管理等等,当然还可以细分一下,
客户信息维护又可以分为:客户基本信息、客户的联系人、客户报价、客户的合同等。
我的习惯是建立一个表,叫做功能结点表。
这个表可以生成左面的功能树,也可以记录项目里面一共有哪些功能。
这里的一个功能指的是两个页面,一个是列表页面,一个是表单页面。
列表页面包括查询、导出数据等功能,表单页面又可以再往下继续划分,就是可以在包含子功能结点。
这样一个项目里的功能就全部记录到了一个表里面。
功能结点表的主要字段
FunctionID
ParentID
Title
URL
...
其它字段略。
第二个问题:哪些人可以访问到那些功能结点?
这个问题呢就要引入“角色”或者“用户组”的概念了。
我们建立一个角色表来记录一个角色拥有的功能结点。
我们可以写一个程序,让客户自己来维护,也就是说用户可以自己添加、修改“角色”。
然后把人员和角色关联起来就可以了。
角色表的主要字段
RoleID
TItle
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
第三个问题:详细权限的划分
一个页面可能会有很多的功能,比如可以查看、查询、添加数据、修改数据、删除数据(又可以分为逻辑删除和物理删除)、导出数据等。
而一个人(或者说是角色)来到这个页面后(获得了访问权限),不一定会拥有上面的全部的权限。
这样就需要再详细区分一下。
这样的话我们在加一个字段就可以了,通过这个字段来判断登录人有哪些具体的权限。
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
详细权限
第四个问题:资源的访问权限
这个我还没有想好怎么解决。
就是说同一个页面,业务员只能看到自己的客户信息、并且可以维护,
然后业务一部门的经理只能看到业务一部门的业务员的客户信息,不能看到其他业务部的客户信息
再然后是业务部的总经理,他可以看到所有业务员的客户信息。
最后就是,不知道大家有没有遇到过“内勤”这个职位,就是说业务员只管联系客户,不用自己录入客户信息,
而往电脑里录入信息的工作就全交给内勤了。
再往下说就更烦了,一个业务部可能只有一个内勤,也可能有多个内勤,一个内勤会对应多个业务员。
好了先不说了,好像有点跑题了,这个就当作是特利吧。
前三个问题都不需要引入部门的概念,但是第四个问题就不得不考虑部门了。
以上是我的思路,不知道能不能把权限的问题,从粗粒度上说清楚。
赞助商链接