权限篇

权限，任何一个系统不可或缺的一部分。权限大致可分为3大类，菜单，数据，字段。先来看权限表结构

笔者接触的权限还有一个更复杂的情况，就是一个表的数据需要按照数据来分组。每一组的权限不一样。如： 员工表工资大于5000为一组权限。小于5000为另一组权限。表结构如下

权限主表字段含义
1，department 部门
2，department_relation 关系部门。如（上一级部门）
3，role 角色
4，user 用户
5，user_relation 关系用户
6，read 读权限
7，create 新增权限
8，update 更新权限
9，delete 删除权限
10，operate 操作权限
……

其中菜单权限，新增权限，字段权限不涉及到关系部门。这里我也不谈兼任的问题。
再谈代码的封装。其中只有读权限是不一样的逻辑。菜单。新增，编辑，删除，操作，字段这些权限都可封装为一个方法。因为这些权限全只需要返回true，false。
而读权限必须要返回一段SQL语句。否则与分页排序这些功能就没有办法整合到一起了。。

此方法三个参数，1，当前登录用户。2，权限数据。3，owner（拥有者）（关系部门与关系用户的权限判断必须要有一个拥有者，如菜单权限，新增权限则无此参数）
例：上一级用户可以修改下一级用户的数据，则在判断权限时逻辑为，查看当前登录用户是否为需要修改数据的拥有者的上一级。。拥有者在系统里一般为cre_user（创建者）这也是为什么每一个表都需要cre_user这个字段的其中一个道理。。笔者为了员工离职后cre_user不能修改的原因。在需要控制权限的表中增加了一个owner字段。用来当表示这条数据的所有者。

接下来就是查看权限了。先上一部分代码。


这个方法有2个参数。第一个是表名。第二个是这个表的全部权限。
查看权限是系统中比较复杂的一部分。我把这部分分成了2部分逻辑
1，不包含关系部门与关系用户是。
如权限数据为：
1，A部门的A角色可以查看数据
2，A部门的B角色可以看数据。
这个表分配了2个权限。为A部门的AB角色可以查看该表数据。
解析逻辑为。查看当前登录用户是否为A部门的A角色或B角色。是则返回null，否则返回 1=2。
为什么返回如此的值。。在判断查看权限时需要拼接SQL 如
select * from 表名 where 1 = 2; 这样则表示该用户不能查看该表的任何数据。

2，包含关系部门与关系用户时的查看权限。
如权限数据为：
1，上一级部门的A角色可以查看下一级部门的数据。
select * from 表名 where 当前用户为数据创建者的上一级部门的A角色。也是上图中的逻辑。上图中有一部分为兼任的逻辑。
若是存在数据分组的权限。只需要全部解析出来。在SQL中用OR拼接则可。

大致权限逻辑就是这样的。。笔者这个权限系统理论上可以应对绝大部分的权限了。至少笔者还没遇到有这个权限系统对应不到的后台管理系统。。