后台系统常用的权限模型-RBAC
Role-based Access Control，基于角色的权限控制模型。
顾名思义，给用户定义角色，通过角色来控制权限。目前来说基于角色权限控制模型是应用较广的一个。特别是2B方向SAAS领域，应用尤其常见。
权限系统为业务系统基础
在工作流中，业务流程的流转，每个节点的办理都是由人或组织共同参与和协作来完成的。若要在系统中实现工作流，需要对“人或组织”进行抽象，这种抽象在系统功能上就是组织权限系统，即权限系统，因此权限系统是业务系统的基础。
权限系统作用
管理要求-人员分工精细化
精细化分工，即专人专事，它的前提是权责利明确。所以系统需要记录每部操作的日志，也需要控制每个操作谁能作，谁不能做。
系统体验要求-目录和页面的简洁
通过权限，控制系统模块或目录，甚至到页面的显示内容，需要对区别用户，显示内容，保证信息聚焦，无干扰信息。
数据安全性要求
业务数据的保密性原则，即那些数据谁可以看
工作流和组织权限在系统关系
在工作流中，业务流程的流转，每个节点的办理都是由人或组织共同参与和协作来完成的。若要在系统中实现工作流，需要对“人或组织”进行抽象，这种抽象在系统功能上就是组织权限系统。因此组织权限系统是业务系统的基础。
权限的组成
主要由两部分组成，组织架构管理和角色权限管理。
组织机构是企业实际存在的，反映机构的组成，人员的管理层次关系，整体较为固定，为企业管理框架；
角色是为了系统对人员操作进行管理而虚拟出来的概念，变化比较频繁，且与实际人员岗位（岗位为组织架构中的人员属性）无一一对应关系。
具体实现机制
1、组织结构
包含部门结构和用户（对应人员）
部门：核心是部门父子关系；
人员：包括人员属性、帐户属性以及人员和部门的归属关系；
2、角色权限
角色：一定数量的权限的集合，权限的载体
权限：包括操作权限（增删改查等接口），数据范围权限（个人，下级数据，部门所有数据），元素权限（目录结构，页面元素的显示隐藏等）
用户组：与角色类似，需要权限授权。这也是与组织架构中的部门区别。
eg1.用户组-学管初一英语组，需要赋予的权限是初一英语的线索都分配给这个用户组的人员。而并不关心这个用户组人员的所属组织或人员角色。
eg2.人员拥有的所有权限，为人员对应的一个或多个角色的权限与该用户所在用户组拥有的权限集合
注意点
1.人员变动对业务数据的影响（数据固化或增加冗余字段）
2.组织机构的设计中，重点考虑人与部门是1对N，还是1对1，还是M对N
3.部门负责人必须唯一
4.角色是否有继承，看业务实际情况
5.销售部门的人员调整的便捷性和可开放性
6.角色的无休止添加
7.权限命名需简单易懂，必要时候可增加描述
8.部门的增删逻辑以及移动
角色权限管理制度
1新增权限
技术部管理员：
根据统一的命名规范，在【操作管理】和【权限配置中】增加的权限；
2角色添加权限
产品经理：
PRD文档增加权限部分，按规定格式提交PRD：
技术部管理员：
根据PRD，给对应角色配置对应权限，进行测试；上线后同步相关的权限配置到对应的角色
3有关新增角色
3.1原则：
1、用户的权限分配应尽量使用系统提供的角色划分。
2、如需特殊的操作权限,应在准确理解其各项操作内容的基础上,
尽可能配给已有角色，
尽可能避免每个人都有一个属于自己的角色，
尽可能避免每个人都需要配置多个角色；
尽可能避免一个角色只是一两个权限的集合；
eg若删除老师为特殊权限，将此权限配置给师资高级管理员或师资运营经理，而并非在拥有师资专员的人员上，增加“删除老师”角色。
3.2新增角色申请流程：
发起人发起邮件申请（新增角色名，页面、按钮、数据范围的要求，主要的工作场景）---》业务主管审批---》PMO审批---》技术权限管理员审批
