数据权限的使用场景分析

所有的产品工作都是基于实际的使用场景，没有场景的支撑的设计方案肯定是毫无依据的；功能权限大家都容易比较理解，功能权限将页面增删改查的操作功能进行分配；数据权限就有些不好理解；还是拿上次的组织结构图来讲，如下图图一，一般大型集团公司组织结构纵深比较长，有平级的部门，有上下的部门，员工也有上下级的关系，往往会出现大家都在操作一样的事情，但事情的范围不一致，我们可以以财务这个这个职能举例子；会出现集团财务部-各城市财务部-各校区财务组三层关系，我们以财务数据来分析

以组织机构纬度来讲各平行纬度有这样的需求；

1:集团财务总监需求能看到集团的财务数据

2:各城市财务职能需求能看到城市的财务数据

3.各校区财务需求能看到校区的财务数据

若出现各平行纬度有小组情况，如财务组里面有多个组员，各成员只想看到自己的数据，组长能看到全部组员的数据，同时也会遇到非财务职能的管理职能人员也有看财务数据需求

1:本人数据，财务成员只能看到自己关联的数据

2:小组内数据，能查看自己负责小组内成员的所有数据；

3:区域负责人能看到整个区域的数据

图一

图二

所以综合来讲，数据权限要既要满足组织结构各平行纬度的的数据权限需求，也需要解决各平行纬度成员的数据权限需求；用户的群体数量进行划分：校区用户》城市中台用户〉集团用户

数据权限的设计方案

用户数量的背景是校区用户》城市中台用户〉集团用户，所以我们可以先考虑校区用户，对平台的用户进行的背景说明：如下图

平台用户说明（第一期没有考虑集团用户）

A：在创建用户时对用户进行数据权限授权

穿件用户

B：用户登录系统所展示的操纵数据范围不一样

1:机构内（城市）用户在登录系统时会根据用户的数据权限，右边增加数据筛选，优先满足校区内的用户的使用

机构内账户

2：拥有跨机构内的账户我们则在操纵数据上进行这样的设置；

跨城市账户

3：小组内的数据实现比较简单，这里就不在这里累赘说明；

4：这样我们可以整体平台页面进行了分类，如下，这样数据权限和页面能有对应关系，用户在使用的时候只考虑自己的场景即可

页面分类

数据权限设计的反思

1:数据权限具体跟账户绑定，还是给角色绑定，这里做了简单分析

和账户直接绑定

基于角色间接绑定账户

两张图我们能很好的看出，和账户直接绑定相比基于角色间接绑定账户造成的影响页面比较广，这样的话其实不符合我们的使用场景，如某一用户来讲他只负责该集团内的某一业务模块，同时他又只负责某一城市的其它业务模块，这样的直接和账户绑定满足不了其需求，数据权限来将和角色绑定，我们就能实现点对点的权限赋予，手术般的灵活；

2:数据权限能否和用户类型绑定