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