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

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

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

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

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

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

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

其它字段略。


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

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

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

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

角色表的主要字段
RoleID
TItle

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


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

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

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

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

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



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

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

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

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

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

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

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

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


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


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

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