通用权限的思路。只是一个简单的思路。
面对权限，我们要解决几个的问题。
第一个就是：我们的软件里面有哪些功能？ —— 给用户自己维护角色作准备
比如添加新闻、添加产品、客户信息维护、合同管理等等，当然还可以细分一下，
客户信息维护又可以分为：客户基本信息、客户的联系人、客户报价、客户的合同等。
我的习惯是建立一个表，叫做功能结点表。
这个表可以生成左面的功能树，也可以记录项目里面一共有哪些功能。
这里的一个功能指的是两个页面，一个是列表页面，一个是表单页面。
列表页面包括查询、导出数据等功能，表单页面又可以再往下继续划分，就是可以在包含子功能结点。
这样一个项目里的功能就全部记录到了一个表里面。
功能结点表的主要字段
FunctionID
ParentID
Title
URL
...
其它字段略。
第二个问题：哪些人可以访问到那些功能结点？
这个问题呢就要引入“角色”或者“用户组”的概念了。
我们建立一个角色表来记录一个角色拥有的功能结点。
我们可以写一个程序，让客户自己来维护，也就是说用户可以自己添加、修改“角色”。
然后把人员和角色关联起来就可以了。
角色表的主要字段
RoleID
TItle
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
第三个问题：详细权限的划分
一个页面可能会有很多的功能，比如可以查看、查询、添加数据、修改数据、删除数据（又可以分为逻辑删除和物理删除）、导出数据等。
而一个人（或者说是角色）来到这个页面后（获得了访问权限），不一定会拥有上面的全部的权限。
这样就需要再详细区分一下。
这样的话我们在加一个字段就可以了，通过这个字段来判断登录人有哪些具体的权限。
角色拥有的功能节点表得主要字段
Role_FunctionID
RoleID
FunctionID
详细权限
第四个问题：资源的访问权限
这个我还没有想好怎么解决。
就是说同一个页面，业务员只能看到自己的客户信息、并且可以维护，
然后业务一部门的经理只能看到业务一部门的业务员的客户信息，不能看到其他业务部的客户信息
再然后是业务部的总经理，他可以看到所有业务员的客户信息。
最后就是，不知道大家有没有遇到过“内勤”这个职位，就是说业务员只管联系客户，不用自己录入客户信息，
而往电脑里录入信息的工作就全交给内勤了。
再往下说就更烦了，一个业务部可能只有一个内勤，也可能有多个内勤，一个内勤会对应多个业务员。
好了先不说了，好像有点跑题了，这个就当作是特利吧。
前三个问题都不需要引入部门的概念，但是第四个问题就不得不考虑部门了。
以上是我的思路，不知道能不能把权限的问题，从粗粒度上说清楚。
有不对的请指出，大家一起研究。
写完了就要提交了，想向上传一个图片，IE居然死掉了，白写了，还得重来一遍。郁闷。
上篇：通用权限的思路。只是一个简单的思路。
上一篇住要是想说一下大体的思路，就是一个主要的框架，我觉得在做一件事情之前，都需要有一个初略的设计，就是中提的想法，抓住问题的关键点。所以对于权限问题，我觉得需要抓住下面的这四个问题；
1、我们的软件里面有哪些功能？
2、哪些人可以访问到哪些功能结点？
3、访问到了页面后可以做哪些事情？（查询、添加、修改、删除、导出、打印等）
（原来的说法：详细权限的划分）
4、在同一个页面里哪些人可以看到那些信息
（原来的说法：资源的访问权限）
这是我的个人见解，是通过几个项目总结出来的，如果不全面、或者不正确的话，欢迎大家及时指正，共同努力、共同提高！
我设计了下面的这几个表，来解决这些问题。这里我只想表示表之间的关联，至于字段我只是写了几个主要的，字段的设计嘛，大家肯定各有各的方式，我想我写出来主要的就可以了。
我的英文比较差，还是直接用中文吧，这样更直接一些。
如果看图不太清楚的话，可以到这里下载 visio 格式的文件。http://www.cnblogs.com/jyk/archive/2008/04/25/1170979.html
先来看第一个问题，[项目—功能结点] 和 [项目—节点拥有的详细权限] 这两个表记录了项目里面有哪些功能结点和详细的功能，
[项目—功能结点] 功能节点，可以通过这个表来呈现左面的功能树。记录打开的页面和相关的信息。
[项目—节点拥有的详细权限] 按钮组，一个功能节点（主要是列表页面）有哪些按钮，比如“添加”按钮，“修改”按钮等。记录按钮的名称、打开的页面和相关的信息。
这两个表是在设计阶段完成的，程序员可以根据这个来实现功能。
解决了第一个问题后，第二个问题就好办了，[项目—角色] 和 [角色拥有的功能结点] 来 实现。
[项目—角色] 记录项目里面有哪些角色。
[角色拥有的功能结点] 记录一个角色拥有哪些功能结点，功能结点里面有哪些具体的操作（添加、修改等）
不知道大家的项目的角色是在什么时候诞生的，是在设计的时候吗？还是程序做好之后由用户自己设计？我的做法是后者。因为客户比我们更清楚需要多少角色，需要什么样的角色，一个角色里有哪些功能更合适。
我们可以做一个维护程序，让客户自行添加。先在角色表里添加一个角色，然后选择角色可以看到的功能页面，最后选择在这个功能结点里可以做的操作（添加、修改等）。这样一个角色就诞生了。
角色有了之后，就可以给人员分配角色，或者是往角色里添加人员。这样就解决了哪些人可以访问哪些功能节点的问题。
其实在设计角色的时候就把第三个问题也搞定了。
客户添加角色的截图
操作也是比较方便的，当点击“计划和日志”前面的方框（打对号）的时候会自动展开下面的子结点和子子节点，然后这些节点都会被选中，后面的按钮也会被选中。
当选中“工作日志”的时候，上面的节点和后面的按钮也会被选中。
上面的信息全部来自数据库，也就是第一个图里的哪些表。
第四个问题还没有更好的解决方法，目前只能在程序里面硬编码。
