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

很早就完成了权限系统的编码，在实现过程中对可能存在的权限需求进行了分类，也希望提提意见。
  一是系统权限，主要是对模块为单位的权限划分，具体就是用户对该模块可见不可见，能不能对该模块进行再授权的操作。表现在用户界面就是用户登录系统主页面后，可以看到的顶部菜单和左侧outlookbar菜单的内容控制。它是粒度最大的权限控制。
  二是模块操作权限，在对整个模块的权限做出控制后，这里继续对模块的浏览、增加，修改，删除的操作权限做出控制，也可以理解为对象权限 。还是以车辆管理为例，不同的人员对这个模块的操作是不同的，有些用户可以新增，删除车辆；而有些用户则只是可以对车辆的情况查看不能修改。
  三是数据范围权限，又可以叫做对象实例级权限。事实上不是每个用户都可以看到所有记录的。以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制。数据根据其类型，相应字段数值范围划分为不同的区域。不同的人拥有不同的区域查看权限。
  四是单条数据ACL权限，具体说就是对每条数据都要实现权限控制，每条数据都有一到多条权限数据与其对应。以个人通讯录为例，每个用户都维护自己的一个通讯录，这些数据都只是对本人可见，其他人不可见。但用户可以对这些数据做出授权，将某条联系方式以授权的方式共享给其他人，并赋予不同的权限，包括拥有，修改，删除，浏览四种权限。
  五是数据字段权限，这也是用户的最小粒度的权限控制。每条业务数据权限可以精确控制到每一个字段。包括单个字段的可否浏览以及可否修改。
  六是数据范围操作权限，其实这个是可以和数据范围权限合为一个的。具体的区别在与对已经划分范围的数据再增加操作的权限控制。还是以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制，可以查看所有数据。但是请注意：他们只能对这些数据拥有查看的权限，不能修改或是删除，而财务则拥有修改的权限。在一些情况下可以用模块操作权限和数据范围权限的叠加来满足对该权限的需求，但是在权限复杂的情况下，这个权限独立出来是必须的。

还是以车辆管理为例，不同的人员对这个模块的操作是不同的，有些用户可以新增，删除车辆；而有些用户则只是可以对车辆的情况查看不能修改。
还是以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制，可以查看所有数据。但是请注意：他们只能对这些数据拥有查看的权限，不能修改或是删除，而财务则拥有修改的权限。

能不能说说这些功能是如何实现的？

看来你们的权限系统比较丰富,比较典型.
不过我认为你总结得还不够,各种情况是抓住了,但是它们之间的关系还需要整理.

我认为可以总结为两大类权限:
1.功能权限.
  对某功能是否具有执行的权限,结果只有是和否(这就是其本质特征).
  但具体一个功能,可以由多个参数组合,比如URL地址加若干QueryString参数.
2.数据范围权限
  定义可以访问(查询、修改、删除等)的数据的范围，结果是一个记录集合。

你提及的一些权限可以由功能权限和数据范围权限组合而来。

数据字段的控制要做起来就很复杂了

这个权限分析得够细的了，不过要控制数据字段和数据范围的功能操作权限，实现起来应该很复杂的。不知道用的是什么样的方法。

1用ldap可以只改webxml
2作为一种需求作在SQL中去....

不错！确实抽象的很准确。也许可以抽象出两个统一的权限接口来:idea: 但我这样的分类其实也代表了各类权限所对应的不同处理方法。我是在acegi的基础上做出的扩展。
一是系统权限，用到acegi的web filter 拦截模块url
二是模块操作权限,用到acegi的mothed aop 拦截业务方法，同时加了一套web标签完成页面相应button的隐藏
三是数据范围权限，因为使用hibernate，所以构造了QueryObject对象其实是对Criteria的封装，在用户执行查询时拦截查询方法，改变sql语句条件
四是单条数据ACL权限，用到acegi的acl,对权限的增删改查做了封装，同时我也认为acegi的acl还有很多的扩展可以挖掘，例如所谓大集中模式下的部门数据权限。
五是数据字段权限，每个页面配置了一个xml，在xml里对字段权限做出限定，修改webwork标签，根据xml渲染字段 

权限模型建议不要设计的过细
  控制粒度尽量大一些
    目录级的，url级的，action 级的一般都能满足要求
      粒度过细，控制麻烦，耦合紧密，吃力不讨好地
 

你这么实现，似乎比较复杂。过于复杂。

acegi做ACL的支持现在已经很方便了么？