讨论数据权限
大多应用系统中会有如下需求：
1、普通员工可以对自己建立的业务对象有权限，而上级对所有下级建立的业务对象有权限；
2、员工A对区域A的业务对象有权限，员工B对区域B的业务对象有权限；
3、领导A可以看所有销售纪录，而大领导只关心金额超过1000K的销售纪录；
... ...
这些应该都属于数据权限的范畴，如何来抽象、设计和实现才能够尽可能灵活高效？
不讨论功能权限
Thanks
[解决办法]
可以做一个层次树来管理员工之间的关系，这样可以在查询的时候判断一下是不是自己的领导
想看自己的所有的下属的记录也可以做到了
[解决办法]
[解决办法]
功能过滤相对简单，数据过滤很麻烦，需要根据身份（角色）过滤数据，难做
[解决办法]
应该还是权限树之类的设计,但这树比较复杂的了,父权根有好几个子权限,子权限要有子权限,以此类推,个人想法.
[解决办法]
长见识了。我们一般在业务逻辑中控制。
[解决办法]
1、建立职位树，为每个员工设置一个上级关系，登录时获取当前用户的所有上级ID列表和所有下级ID列表。
在Users表中增加字段IDList，
如果ID=1 ParentID=0 IDList=,1, 说明 1没有上级
如果ID=2 ParentID=2 IDList=,1,2, 说明 2的上级是1
如果ID=4 ParentID=4 IDList=,1,2,4, 说明 4的上级是2，2的上级是1
如果ID=1登录时，通过IDList like '%,1,%'获取所有子ID。
2、通过配置设置，建立区域表、用户表、用户区域权限表(用户可以1对多个区域)。
3、a)领导A可以看所有销售纪录；
用户表中增加是否是数据管理员字段IsDataAdmin，为true则可以访问任何数据。建议增加一个所有数据查询页面，IsDataAdmin=true的用户就有权访问此页面，而不用从数据源上控制。
b)而大领导只关心金额超过1000K的销售纪录；
增加一个查询条件，金额大于1000K就可以，其中1000K数值做成可配置的。
[解决办法]
lz可以了解一下基于角色管理的系统访问控制.通用抽象实体在那里边都有定义.Users-->Roles-->Permissions
[解决办法]
[解决办法]
[解决办法]
2. 动态授权及权限控制(URL,业务方法,[b]领域对象). [/b]
领域对象= 数据字典 + AOP
经过几年的思索和不断的技术验证，算是攻克数据权限的难题。
可以在不牺牲性能的前提下支撑各种复杂数据结构的业务场景。
[解决办法]
我做的用户权限一般通过在数据库中增加权限字段来实现
[解决办法]
用户--组--角色--功能--功能中各种操作的控制
按位&运算可以简单的实现功能权限管理，这是一个很成熟的方法，限制就是根据机器的位数限制了功能个数，比如32位的机器有32个，增、删、改、查......，不过似乎这种功能很少
对于部门业务数据控制方面，涉及到数据的安全性，我这边曾经做个项目，方案和jinxfei说的类似，用组绑定
对于领导数据检索统计方面，属于一个综合的子系统：领导查询。这是一个很复杂的业务系统，给领导做决策支持用的，最好别和权限混到一起
[解决办法]
参与抛砖、上述的：
“功能权，解决 谁 能够 做什么 的问题。
数据权，解决 谁 能够在什么 对象 上 做什么 的问题。 ”
——功能权是识别谁能够做什么，实际使用当中由于有角色这个集中点，使得对多个用户分配多项权限更方便。
但是楼主说的数据权范畴之中没有角色这么一个“集中点”，如果还是和功能权一样“解决 谁 能够在什么 对象 上 做什么”这样势必使得实现出来的系统使用上过于累赘，如果用户数量很多你可以想象必须对所有用户一个个分配数据权限、而且数据权限最基本也得分为对数据的增删改查四项，对一个数据对象一个用户至少得做四项配置...我认为应该把数据权限的定义改为：
数据权，标识 谁 不能在什么 对象 上 做什么 的问题
这样数据权限的内涵完全变了，要以功能权为主数据权为辅，数据权仅仅用于补充，也就是配置哪位用户不能对什么数据做什么操作。
“用户可以属于多个组、多个角色”——属于多个组的实用意义似乎不大，国内的组织结构也少见这样，不如使系统能够绕过角色直接将某权限配机用户功能实用。
另外：数据权限已经和具体数据相关联了，而这个数据必然是在我们的权限系统之外由客户在使用系统期间录入的某些数据，这就已经超出了“通用”权限系统的范畴，引入新的复杂性。
[解决办法]
哪位用户不能对什么数据做什么操作 这个也可以叫做反权限，在宫力的书里讲过jaas没有反权限因为正反权限共存将使复杂性大增而且实用价值不大。
另外也别再想在数据权中再添加个类似角色的东东了，因为功能权就解决了大部分访问控制，常见系统有此控制机制足矣。只是在客户后期使用时期如果要添加控制谁不能访问什么（这个可能比较常见）的时候，可以用数据权来补充解决，因为此时的功能权限做这件事很别扭。
[解决办法]
上述数据权限可以用aop来解决，功能权限用j2ee 的 filter
[解决办法]
数据字典 + AOP
不会牺牲性能.
AOP 事前装备负责对数据的操作拦截,
AOP 事后装备负责对结果集进行拦截,可以动态增加原始的查询条件,从最原始层进行过滤.
比如: 动态给一个Hibernate查询增加条件,那查询结果就是符合权限的数据集合.
不用写任何代码.
不用依赖数据库表.
权限系统是独立于应用的.
感觉来这里的都不具备讨论这个的基础! 不要浪费时间了!