之前写了一篇权限设计的整理思路的文章，权限设计的难点其实是在数据管理这一块，最近刚好实战了一个项目，刚好可以将数据权限的设计经验分享给大家，希望能给大家有所帮助
数据权限的使用场景分析
所有的产品工作都是基于实际的使用场景，没有场景的支撑的设计方案肯定是毫无依据的；功能权限大家都容易比较理解，功能权限将页面增删改查的操作功能进行分配；数据权限就有些不好理解；还是拿上次的组织结构图来讲，如下图图一，一般大型集团公司组织结构纵深比较长，有平级的部门，有上下的部门，员工也有上下级的关系，往往会出现大家都在操作一样的事情，但事情的范围不一致，我们可以以财务这个这个职能举例子；会出现集团财务部-各城市财务部-各校区财务组 三层关系，我们以财务数据来分析
以组织机构纬度来讲各平行纬度有这样的需求；
1:集团财务总监需求能看到集团的财务数据
2:各城市财务职能需求能看到城市的财务数据
3.各校区财务需求能看到校区的财务数据
若出现各平行纬度有小组情况，如财务组里面有多个组员，各成员只想看到自己的数据，组长能看到全部组员的数据，同时也会遇到非财务职能的管理职能人员也有看财务数据需求
1:本人数据，财务成员只能看到自己关联的数据
2:小组内数据，能查看自己负责小组内成员的所有数据；
3:区域负责人能看到整个区域的数据
所以综合来讲，数据权限要既要满足组织结构各平行纬度的的数据权限需求，也需要解决各平行纬度成员的数据权限需求；用户的群体数量进行划分：校区用户》城市中台用户〉集团用户
数据权限的设计方案
用户数量的背景是校区用户》城市中台用户〉集团用户，所以我们可以先考虑校区用户，对平台的用户进行的背景说明：如下图
A：在创建用户时对用户进行数据权限授权
B：用户登录系统所展示的操纵数据范围不一样
1:机构内（城市）用户在登录系统时会根据用户的数据权限，右边增加数据筛选，优先满足校区内的用户的使用
2：拥有跨机构内的账户我们则在操纵数据上进行这样的设置；
3：小组内的数据实现比较简单，这里就不在这里累赘说明；
4：这样我们可以整体平台页面进行了分类，如下，这样数据权限和页面能有对应关系，用户在使用的时候只考虑自己的场景即可
数据权限设计的反思
1:数据权限具体跟账户绑定，还是给角色绑定，这里做了简单分析
两张图我们能很好的看出，和账户直接绑定相比基于角色间接绑定账户造成的影响页面比较广，这样的话其实不符合我们的使用场景，如某一用户来讲他只负责该集团内的某一业务模块，同时他又只负责某一城市的其它业务模块，这样的直接和账户绑定满足不了其需求，数据权限来将和角色绑定，我们就能实现点对点的权限赋予，手术般的灵活；
2:数据权限能否和用户类型绑定
这是我目前发现表糟糕的数据权限设计方案，与用户类型绑定会导致单个用户来讲在系统只能是一种用户类型，实际来将用户的类型可能是多个，如有的销售可能既是市场又是销售，用户类型绑定导致数据权限不能灵活配置，也增加了代码实现的难度。
以上就是本人对如何做数据权限设计的总结分析，仅供大家参考，希望在工作中能够帮助到大家，也希望大家一起多提意见，指出不足，感谢阅读！
