先讨论下权限。
第一步:
经典的大家都知道的，基于角色的权限控制。通过以下表
资源表（标明项目内资源）
资源行为表（要被用来授权的客体)
权限表（记录资源行为和角色的关系表,存储行为id和角色id）
角色表(人员群组)
角色人员关系表(存储人员id,角色id,类型[管理员还是成员])
人员表(人员明细表)
比如画面是个资源，菜单是个资源，其他自定义的比如模块是个资源。然后对于画面可能有新增，修改，删除的行为，对菜单有浏览,模块有增删改等。。。
为了区分资源中的菜单,画面,模块等,添加类型列,同时新增一张表：资源类型表（标注资源的一个分类），再增一张表：资源类型默认行为表（标注某一分类的资源默认拥有的行为）。当新增一条某类型的资源时，同时会按 类型默认行为表新增 相应的资源行为信息。。。
根据需要，比如菜单拥有自己的菜单表，那只需要通过一个类似guid的菜单id字段关联菜单表 和资源表，保持同步。。
这样可满足常用的需求统一授权：开一个默认系统级角色：系统管理员，系统管理员的成员拥有类似administartor的权限，能够操作所有资源,用户，权限信息。
根据需要添加相应的角色组，然后把相关人员加到相关角色组,然后在权限表中存储角色组id,跟资源行为id即可。。。如现有角色组不满足，增加新的角色即可。
查询权限先查询用户所在的组,然后查询改组拥有的权限,合集即可..
第二步:
下放授权功能,为角色添加角色管理员,授权同时标注是否可再授权
为了下放授权功能,角色人员关系中添加一个类型列(标注是管理员还是成员),角色管理员可以操作角色.
1. 任何用户如果有角色维护页面权限,都可新建角色，当新建一个角色时，该用户默认为角色的管理员。该角色管理员可维护该角色。（包含修改角色，删除角色，维护角色管理员，维护角色成员，维护角色资源）。
2. 角色管理员可新增的对应角色的管理员或者成员.人员从系统成员中选择。
为了
3. 角色管理员，删除成员或者管理员，或者删除角色资源不受限制。
为了控制可授权的资源,在权限表中新增一列是否可再授权,当授权的时候同时可标注是否允许拥有该资源权限的人继续授给其他人
3. 角色管理员可新增的资源，为当前管理员自身所拥有的可授权的资源{在权限表有一个字段用来标注，相应权限是否可继续再授权}。
优点:很简单啦，大多数人稍讲解下都知道的。。。
不足:
1. 用户不限制，即每个管理员都可为角色新增 任何用户
2. 角色不分级，即所有角色是平等的，平铺开的，没有上下高低之分.
3. 角色不嵌套，即角色不设置父角色，比如。现有一个角色A，新增一个角色B归属于这个角色A，那么任何用户只要属于角色B,则同时拥有角色A和B的权限。不能嵌套，那么就需要把用户拉入A角色和B角色，或者把A所有资源拉入B角色。。
4. 资源不分组，比如现有一堆资源属于同一类，可将资源分组，然后可将改组授给多个角色。授一次即可，如果资源不分组，那表示需要将一堆资源分别多次拉入角色。或可通过先加入一个角色，然后复制新增该角色内资源到其他角色。
第三步：
授权的资源信息可通过是否再授权维护了,那么人员信息呢?考虑为添加人员管理员的概念
为了维护成员，限制角色管理员可管理的用户？（此处有个疑问，如果对可操作用户限制了，那么是不是如果角色管理员A不能管理用户B，不单新增角色用户时看不到B,而且不能将B从角色中删除？？疑问？。{暂定可见就可删，谁让人家是角色管理员呢}。）
新增部门信息表。默认情况下每个用户都是归属于某一个部门的（或称组织机构）。。数据库初始化时，默认有一条不定部门 的记录，则当用户还不确定部门时可归属不定部门。部门设置部门管理员，部门管理员可管理该部门下的用户。
那么，角色管理员，通常同时是部门管理员，则可新增部门下的用户，如果角色管理员不是部门管理员，则不能新增角色用户。但能删除用户，或者维护资源.
优点：解决了角色管理员限制用户的目的。。比如一些顶级用户是不希望 其他的用户能够看到自己或者随便把自己加到 某些角色的。
缺点：虽把用户分开了，但资源不分级。。比如有些用户可操作的资源，只能是其他一些用户的子集。。
第四步：
添加分级授权的功能,比如给A授权的100个资源,那么A的下级只能授这100之内的,如果A的某一权限被收回,则下级默认全收回
为了分级，在权限表再增一个字段，授权主体类型。即除了为角色授权外，也可针对部门授权，但针对部门的授权，只用来做 分级授权使用，即子部门所能拥有的权限只能是父部门权限的子集。。
这样角色管理员，再新增角色资源时，他所拥有的可授权的资源。就不单来源于他所在的角色， 还有可能来自部门（当他是某一部门的管理员时，他就默认拥有了该部门的权限）。切记该部门的权限只用来授权使用，此处暂定不用来享有权限（也即，如果部门管理员没加入任何角色，则不拥有任何资源。只是当把他设为某一角色的管理员时，他可以为角色添加部门下的资源，以及挑选部门下的用户）
---优点：解决了资源分级，这样的话就可限制，某些角色管理员可见的资源。。比如，如果没有部门授权，那么当新增3个角色A,B，C并设置的相应 的角色管理员A1,B1，C1那么当A B C角色所能访问的资源有包含关系时，就需要再新建三角色来放置A1,B1，C1,这样A1,B1，C1就可访问不同资源。。相当于为角色管理员设置 角色管理员角色，来限制角色管理员可授权的资源。。
--=缺点：嵌套关系还没有
第五步：
考虑权限嵌套,类似角色套角色的功能 权限嵌套，可发生在部门，比如部门A下有个角色，那么部门A下的子部门AA1，如果在AA1内挂角色，那么该角色默认拥有父部门A的角色所有的权限。
这样就可实现嵌套，那就加一张部门角色表。。也即当新增一个角色时，可以指定角色的部门（0至多个）。。如果指定了部门，则只是为了做权限嵌套使用。同一个角色可指定多个部门 包含父子或者平级的部门。。
只有角色管理员才能把他所管理的角色添加到 他所管理的部门下，也即 操作用户需要即是部门管理员，且是角色管理员，才可拖拉角色到部门
优缺点:与单纯的角色套角色比,有何优缺点,还待讨论?
综上。。暂定如此。。。 可能理解上稍有难度，主要纠结一些细节，比如角色挂在了部门下，但并不表示该角色的权限 是部门权限的子集。完全没关系，只是为了嵌套使用。。当为角色添加成员时，跟角色所在部门无关，只跟当前操作的角色管理员有关。
其实很多是操作方式是否方便，是否有重复操作等问题。。人为的不要去做一些 理论上可行，但没意义的操作即可。。
无论如何设计授权模式,操作界面,最终只是为了权限查询.而查询,最终是落在了到权限表查询上..
针对以上模式，当获取登录用户id后，要查询他所拥有的权限，先查询它所在的角色，包括直属角色，以及嵌套角色(角色父部门下的所有角色)。等获取到角色的并集时，再去查询相应权限的并集。。