## 权限设计
权限其实蛮复杂的,这里不同用户,不同类型的使用者都有各自的权限,特别是还涉及到企业微信成员对应用的权限控制。
根据使用对象,我们需要分为几个层面来分别设计权限控制。
>[danger] 权限做得复杂可以很复杂,很完善,也可以做的很简单,初期简单、有效就可以了,不需要做的太复杂。不然就犯了“过早地把系统设计得太复杂”的问题,这和“过早的优化性能是万恶之源”差不多。
* * * * *
### 思考
~~~
有一些东西是基础设施,比如班级管理,有一些是应用,真是傻傻分不清。
还是一刀切算了,直接用应用做,必须班级管理就是应用。
烦,系统,应用,管理,权限,企业微信应用,还没有很好的设计出他们的关系,烦!!!
再来看应用权限
应用前台针对于成员,后台针对于管理员。
同时还有常规的节点权限,应用权限(应用管理/可见权限和应用节点权限)
对于后台管理来说,应用是学校管理员、老师的使用权限(可见权限和后台节点权限)
对前台使用来说,应用是成员的使用权限(可见权限和前台节点权限)
~~~
### 扩展思考
权限分为两类:
后台权限,和前台权限。
后台权限是管理员权限,各项操作或者应用的功能权限。
前台权限是成员使用应用的权限,包括应用可见权限(这个由企业微信成员通讯录可见范围控制),和应用功能的控制。
~~~
-- 权限要注意的是,不仅要控制可见,也要控制实际的应用权限,因为即使应用不可见,用户还是能记住url使用应用,所以要做真实的权限控制
-- 目前接口不能设置应用的可见范围,但是也没事,毕竟应用的使用人群是固定的,比如事先就规定,“校长信箱”只能是家长使用的,那么业务员前期的准备工作就是做这些,将“校长信箱”的可见范围设置为家长部门,我们要做的就是控制谁加入家长这个部门就行了,权限以这种思路来做,如果以后接口支持更强大就方便多了。
-- 【应用更细化的权限控制】(细化到操作)(不同角色可能有统一模块的可见权限,但是具体的操作权限可能不同)
-- 【成员】
-- 前台 应用可见权限(细化到部门和成员,上面已经实现)
-- 前台 操作权限(细化到部门和成员)
-- 【学校管理员】
-- 后台 应用可见(管理)权限(细化到角色和账号)
-- 后台 操作权限(细化到角色和账号)
-- 【老师】
-- 后台 应用可见权限(细化到角色和账号)
-- 后台 操作权限(细化到角色和账号)
-- 应用权限规则(节点,注意这个分为前台和后台) 表
-- 部门/角色/成员/账号 & 规则 关联 表
~~~
* * * * *
### 成员 权限
成员(老师,家长),应用的可见权限,和应用的节点权限。
* * * * *
### 学校管理员 权限(不是老师)
管理员应用的可见权限,和应用节点的权限。
还有常规的节点权限。
* * * * *
### 学校老师 权限
老师应用的可见权限,和应用的节点权限。
同样有常规的节点权限。
(老师和学校管理员类似,也可以管理学校,本可以设计为学校管理员表中的一个角色,但是由于老师和家长一样,都是前台的使用者,都是成员,所以比较特殊,为了方便管理,所以**老师用户账号**表就是成员表,和学校管理员分开设计了。)
**学校中的老师不是用户,成员才是用户,学校中的家长不是用户(一个人可以为好几个学生的家长,甚至可以为好几个学校的学生的家长),对应的成员才是用户,理解这个很重要,这是身份于账号的关系,账号是独立的个体,而身份是依附于账号的。**
* * * * *
### 最终的权限设计
- 应用权限
- 常规权限
**应用权限:**
<table>
<tr >
<th rowspan="2" style="color:red;">应用权限</th>
<th colspan="2" align="center" style="text-align:center;">前台</th>
<th colspan="2" align="center" style="text-align:center;">后台</th>
</tr>
<tr>
<th>可见权限</th>
<th>节点权限</th>
<th>可见权限</th>
<th>节点权限</th>
</tr>
<tr>
<th rowspan="2">权限</th>
<td>成员的可见权限</td>
<td>成员的节点权限</td>
<td>管理员的可见权限</td>
<td>管理员的节点权限</td>
</tr>
<tr>
<td></td>
<td></td>
<td>老师的可见权限</td>
<td>老师的节点权限</td>
</tr>
</table>
**常规权限:**
<table>
<tr >
<th rowspan="2" style="color:red;">常规权限</th>
<th align="center" style="text-align:center;">前台</th>
<th align="center" style="text-align:center;">后台</th>
</tr>
<tr>
<th>节点权限</th>
<th>节点权限</th>
</tr>
<tr>
<th rowspan="2">权限</th>
<td></td>
<td>管理员的节点权限</td>
</tr>
<tr>
<td></td>
<td>老师的节点权限</td>
</tr>
</table>
前台都是应用,所以只有应用权限没有常规权限。权限都是在后台设置。(设置权限 的 程序节点 是 常规权限 的 节点权限)
**<span style="color:red;">这些节点需要自己创建(系统定义),而应用的节点需要开发者提供,如:</span>**
`XX操作:do=xxAction`
>[danger] 权限节点(应用如果要支持精细的权限节点,就可以进行配置)
* * * * *
### 关于内建应用 的权限
内建应用可能没有应用后台,而是通过系统后台直接管理的。
所以内建应用的节点规则可能包含了应用前台和系统后台,或者应用后台。
总之内建应用比较灵活,不像常规应用那么标准。
内建应用定义 **非常规的应用节点** 时怎么定义呢?
常规定义是:`XX操作:do=xxAction`
如果内建应用想定义 **非常规的应用节点** 是这样定义的:
直接定义完整节点就可以:module/controller/action
* * * * *
### 权限控制所需要的表
#### 应用权限
**节点权限**
- 成员(前台)-应用权限节点 关联表:`学校ID,应用ID,节点名称(XX操作),节点名(前台xxAction),成员ID`
- 管理员(后台)-应用权限节点 关联表:`学校ID,应用ID,节点名称(XX操作),节点名(后台xxAction),管理员ID`
- 老师(后台)-应用权限节点 关联表:`学校ID,应用ID,节点名称(XX操作),节点名(后台xxAction),老师ID(其实是成员表ID)`
(应用节点一般比较少,所以这里没有角色,用户直接和节点关联)
**可见权限**
- 成员(前台)-应用可见权限表:`学校ID,应用ID,obj_id,type(部门或成员ID)`
- 管理员-应用可见权限表:`学校ID,应用ID,管理员ID`
- 老师-应用可见权限表:`学校ID,应用ID,老师ID(其实是成员表ID)`
应用权限需要6张表。
#### 常规权限
管理员节点权限(auth的四张表)
老师的权限节点表(auth的四张表)
* * * * *
last update:2017-9-21 14:06:25