方案一
按照岗位体系建立 数据权限
权限——>岗位<——员工
应用：CRM
优点：1.设置简单，选择按照部门选择
缺点：1.需要维护一套岗位体系
2.不够灵活，不能看到跨部门数据（可以了解到其他部门的 价值 ） 也不能看到上级的数据（有个员工需要根据能力恒定自己的职业规划，那么他会以上级为参考点，去观察上级的销售数据如何）（人事 财务需要看到整个部门的数据，他们也不是领导，他们是专员，而且那些人也不是他们的下属 ，无论如何都看不到数据）
方案二
针对角色设置数据权限（实习公司也是这样处理：班主任， 助教， 管理员）
权限——>角色<——人
优点：不受岗位框架 影响，可以灵活设置，如果短期内 没有负责到这部分数据，我就取消对应角色权限即可，但不用删除掉这个角色以及权限；再比如 可以设置一个角色“宇宙总局xx指挥中心xx副局”，但实际上不存在这个岗位。
再比如，角色可以多层叠加，比如 华南地区xxx就可以看到华南地区的数据；华东地区xxx就可以看到华东地区的数据；总局可以看到xx所有数据，但是 我们不能让这个人看到所有数据， 只需要让他负责华南与华东即可，则给他两个角色 就好
怎么设置 角色权限呢？
采用 数据规则：规则编辑器
如：客户所在地区 等于 AS地区 且 客户状态 等于 带续签 ，输出结果： 交集
客户所在地区 等于 B地区 且 客户状态 等于 入住 或 客户所在地区 等于 K地区 且 客户状态 等于 签约，输出结果：并集
优点：1. 避免 与岗位直接绑定， 岗位变动 则 权限变动；
2.避免与岗位直接绑定， 僵化 管理，没有角色灵活
3. 可以适合 多种 特殊化场景 （临时需求居多），用完就释放 权限关系，避免数据泄露
缺点：1.需要维护角色 与权限关系
2.数据规则较为复杂，需要进一步管理
3.如果是多层计算，同样数据规则也很复杂
方案三
岗位方案 + 角色 方案
专化 岗位： 提供 岗位 方案 如：销售 （A,B,C都是销售，但A负责a课程的 物料，B负责b课程的人群转化以及转介绍，C负责d项目的引入 ）
不专化岗位：提供 角色 方案 如：销售 人事 （一个月前负责xx项目的招聘工作，一个月后负责xx项目的培训工作）
总结：
数据范围 划分清晰， 准确
尽量减少 维护成本（弄完一套规则体系后尽量不动 维持原态）
设置灵活（可塑，可拆，可整合）
名词解释：
直接下属：辖域 下面一层
所有下属：所有辖域，包括往下一层 往下二层 往下三层，，，
虚拟上级：一个节点
特殊情况处理：
人员变动： 判断人员是否 专化？ if 是，then 岗位；if 不是，then 角色 方案。
部门变动（几乎很少）：
并入新部门： 维持与新部门同个权限位置。
拆分： 经讨论分析，评判每个用户的角色等级。
移出： 撤销原有权限，载入并维持新权限。
