首先系统权限,每个账号登录后,都需要知道这个账号允许访问哪些api,哪些数据权限(一般是指其他账号的一些数据)
这里就需要通过角色来关联。
--1.角色绑定菜单,每个菜单设计的时候包含了这个菜单会用到的所有api接口,如果菜单里面需要添加子权限,如新增,删除等,则可以继续拆分,新增权限,和对应的新增的api接口,
--2.角色绑定数据权限,配置可见用户范围
--3.角色绑定其他
这套设计方案的优点:灵活性和安全性都能得到比较好的保障
答疑:
1.这套方案后续如果菜单发生调整,如移动层级,新增菜单功能,对已配置的角色有什么影响
答:如果是调整或新增菜单功能后,每个角色有可能都需要重新配置才能生效,或是从数据库刷数据,这可能也算是这套方案的缺点
2.如果某个业务,例如云盘,有群组功能,我被加到某个组,或是选人组件,里面想可以选所有人,岂不是跟整体的数据权限冲突?
答:系统的权限其实是为了多数的业务提供个普适的处理,减少模块权限配置,如果不适用具体的模块,可以按模块的需求单独设计权限,忽略不用系统数据权限即可。
3.如果某个菜单A模块里面包含了其他菜单B模块的ui,只配置了菜单A的权限,没有配置菜单B的权限,那这套方案是不是就不适用?
答:也适用,这种情况属于模块间存在交叉的复杂模块,如果确实是需要在A模块里面使用到B模块的某个ui,例如需要打开B模块的详情,这时候只需要在A模块里面把B模块详情需要api接口权限添加上即可。
参考伪数据结构
用户
did
id
avatar
account
name
dept
pwd
groupIds部门
id
pid
name角色
id
name
menus:[],
powerType:1,
depts //可查看部门
uids:菜单
id
pid
name
path
"meta": {"title": "角色管理","icon": "el-icon-notebook","type": "menu"|"button"
},
"component": "setting/role"
apiList:[]
参考ui