我对项目可能存在的权限需求的分类

分析的挺好的，只是太少了！

能详细谈一下在复杂业务逻辑的情况下这个是如何实现的吗？

老实说这个实现是有限制的，就是Criteria的封装，动态改变SQL语句的条件。但我并不认为复杂业务逻辑就一定不能处理的。你可以举个例子：）

举例如下：
某公司的雇员有内部雇员和外部雇员2类雇员。内部雇员即所谓的内勤人员，外部雇员(也称渠道人员)一般是跑业务和市场开拓的(有很多分类)，我们把外部雇员的不同分类称之为不同的渠道。
行政架构(DIVISION)维系总公司和分公司之间的关系，内部雇员直接嫁接在行政架构上。
同时，为了保证外部雇员的干劲，在行政架构上我们添加了渠道组织架构(一般添加在行政架构的最底层，比如各分公司)。不同渠道的组织架构是不同的，渠道人员嫁接在该渠道的组织架构中。

权限需要做到的是：
某渠道某分公司的管理角色登入系统，只能看到该渠道该分公司下的渠道角色。
某分公司总管登陆系统可以看到该公司内部雇员以及某些特定渠道的渠道角色。
同时，要为以后外部雇员和内部使用系统预留接口，实现它们登陆只能看到自己的信息的功能。

现在的作法大体上是使用AOP拦截接口方法，动态添加hql语句，或是改变criteria的查询(整个系统中因为查询比较复杂hql使用的比例远大于criteria)，下面我用hql举例来阐述我的困惑。
每个需要控制权限的接口为了权限都在数据库中实现了特定的hql片断以供修改hql语句。乍看之下整个系统的权限是实现了七七八八了，但是有以下几个硬伤：
1.如果某个接口的实现方法改变(特指hql发生了改变)，可能需要去数据库修改权限对应的hql片断，开发人员很不方便。
2.虽然由数据库维护了权限的控制，但是事实上这块的权限和业务高度耦合，不能指望维护人员能够修改什么，甚至开发人员自己来维护的时候也异常麻烦。

------------------------- 数据权限的分割线 --------------------------

顺便谈一下显示权限，这里有一个比较变态的需求。
拿人员录入作例子，某分公司在不同年份中人员的可录入项目是不一样的。
这里的年份描述可能不尽清晰，我们可以把它理解成条例，比如某公司虽然在2007年但是他使用的是05年的条例，条例限制了他的可录入项。该分公司可能在年底整个系统往07年条例过渡，他们希望条例过渡时，录入项可以自动改变。

目前可行的方法是控制整个页面的可视化组件的权限(有页面可视化资源表对应)，根据条例动态渲染组件。

但是存在一个让我很不舒服的问题，当权限从系统中移除时这个页面效果惨不忍睹。有什么好的解决方法吗？

我觉得你虽然描述的比较复杂，但问题的关键还是很清晰，谁（某渠道某分公司的管理角色，某分公司总管）拥有什么样的数据范围权限。而所谓的数据范围无非是在所有记录上以一定规则划分出不同的区域，这个划分目前是以特定的hql片断来实现的。你完全可以把这些hql片断以资源的方式管理起来，根据用户的角色分配不同的资源（这里可以理解为不同的hql片断）。由这些资源构成一个大的抽象资源（因为这些不同的hql片断可能会重复，可能会互相影响），最后再去和业务数据打交道（这里你采用的是动态添加hql语句）。说的很拗口

你描述的这些部分已经都实现了，我主要想要知道的是你如何看待或是解决我下面说的硬伤部分(主要是针对特定的接口实现特定的hql片断同直接把数据权限当作业务逻辑的一部分有什么区别呢？除了留下来一个看上去很美的统一管理的途径)。

为什么需要去数据库修改权限对应的hql片断呢？不能动态修改吗？我刚才也提到了一个大的抽象的资源类，它的作用就是把这些hql片断重新以某种方式组合，同时它的另外一个作用就是实现权限和业务的解耦，它上面可以再增加一个接口，可能是这样一个方法 QueryObject getAuthQueryObject(Principal p);传入当前用户信息，返回他有权限的资源（这里是重新组织过的HQL），然后你AOP业务方法，前拦截把这个QueryObject处理到你的业务hql中去

我大概明白你的意思了，这些HQL片段有些是对应这个业务接口的，比如说用户信息管理对应一些HQL片段，财务信息管理又对应另外一些HQL片段，是这个意思吗？

确实如此，无法抽出共有的部分。我只是描述了项目的一个方面，其实还有很多方面需要这样控制的。

这个你可以考虑给这些hql片段加个标识字段，标识这几个HQL片段是和那些业务挂钩的。在我的实现中是给它们增加了个domain classname.我想这应该不是难事，你可以单独出一个xml来配置这个东西，如果你实现页面配置到数据库中比较麻烦的话