一.通用权限模型
数据权限和功能权限，分开
1.简版权限
1个用户，有1个角色。1个角色，对应多个权限。
用户:角色 = 1:1
角色:权限 = 1:N
只考虑功能权限：菜单权限和按钮权限。
不考虑数据权限
2.标准版权限
在简版权限的基础上，增加数据权限。
规则1：能看到哪些模型,商品/订单/公司/区域
规则2：能看到模型里的哪些数据
基于规则的：自己创建的。管理员看所有的。
复杂点的规则：自己手下的，也能看到。涉及到组织机构。
2个人跟进同一家公司，2个人共同维护一个店铺，都能看到这个店铺。
基于配置的：灵活配置
用户124，分配公司（102、105、106）。
用户163，分配商品（1356，1357，1359）
配置方式：
定制化配置：新增1个数据维度，增加1张表维护（配置中心之类的也可以）
通用配置：类别模型（商品、公司、订单），数据配置模型（id，categoryId,value,remark）3.灵活版权限
用户直接拥有权限，用户可以有多个角色
3.1 想给用户直接配置权限
用户:权限 = 1:N
用户多了，想给某个用户配置特定的权限。
用户的所有权限 = 用户角色权限（默认权限）+用户特定权限（定制化权限）3.2 一个用户可以有多个角色
用户:角色=1:N
1个用户既是开发，又是运营
用户的所有权限 = 角色1权限+角色2权限
4. 特定版权限
4.1 组织机构和角色啥关系(一般不同时和权限挂钩)
特殊逻辑，特定需求。a、简版，角色名，可以按照组织机构，“开发”、“运营”、“老板”、“财务”。
每个部门属于1个角色，特定权限，可以配置多个角色，或者为某个用户特定功能的权限。
b、复杂版，组织机构（用户、部门、岗位）和角色分离。
给单个用户授权、给某个岗位授权。
或者说，整个部门维护所有权限，用户只能从该部门权限里挑选。
c、常见需求：上级可以看到下级的数据
4.2 测试数据权限
为了方便测试人员，在预发和线上测试，增加测试数据权限。 测试角色，添加的数据，为测试数据。
或者，主要模型数据（商品、公司）增加isTest标记，只有测试角色的才能看到，或者某个用户单独标记是否有isTest权限。
二、权限配置
1.前端配置
前端根据，客户需求，灵活配置。 变化点：是否支持多角色、用户直接授权、是否需要数据权限（模型类别维护，公司、区域等）。
2.后端配置
后端支持各种灵活的配置，不同权限模型提供不同的接口。
表结构、存储数据
3.前后端交互
API，CRUD
三、前端权限控制
1、菜单
登录时，获得该用户所有的菜单权限。
2、按钮
登录时，获得
3、数据权限
不需要。 但有可能提供数据权限的“筛选”功能。
比如，管理员能看到所有区域的权限，增加“华中”、“华北”等区域的筛选。
4、2种模式
vue前后端分离模式：JS控制
前后端页面混合模式：Java控制
四、后端权限控制
登录时，会话里维护所有的权限信息。
1、菜单和URL
权限注解+权限拦截器2、功能
权限注解+权限拦截器3、数据
商品数据里，额外保存系统编码code，区域regionId等数据标记。
sql查询，添加 in(102,104 ) 。4、测试
isTest标记
五、特殊逻辑处理
权限中台，提供标准常见的权限配置。
如果权限需求，过于个性化，本地业务系统存储特定权限配置。
数据的时间范围。
六、最难的数据权限，定制字段
需求：灵活配置某个用户或某个角色或某个岗位能看到哪些字段
公司表：id、名称、级别、地址、跟进人、销售额
A用户：id、名称、级别
B用户：id、名称、级别、地址、跟进人
C用户：id、名称、级别、地址、跟进人、销售额
配置中心
用户：A模型：“id,名称，级别”
角色：A模型：“id,名称，级别”
难点：空段实现，列表和Excel报表，甚至图表
配置表，存储应该是“name”，而非“名称”。 前端字段展示：list方法，有权限 才输出
export报表下载，类似。
class Company{
Integer id;
String name;
String address;
}注意点：为了简化实现，sql查询的时候，不需要根据权限过滤字段。
而是在 展示的时候，再过滤。
字段不涉及到行记录的权限，不需要在sql层面进行过滤，不涉及分页。
