经验总结端产品的数据权限设计

　　上一篇给大家介绍了功能权限设计，本篇主要介绍数据权限设计，做B端用户中心近半年，从一头雾水到产品上线，总结出来一些经验，希望能够给到大家一些帮助。
　　功能权限控制的是用户登录系统后能看到哪些模块，操作哪些按钮；而数据权限控制的是用户能够看到的数据范围。所谓数据范围，不是指能看到的数据字段，而是指能查出来的数据集合。
　　例如，针对订单管理列表页，数据范围可能是某个城市的全部订单，也可能是某个门店的全部订单，某个城市和某个门店决定了2种不同的数据范围。
　　针对数据权限，常见的实现方案有两种：通过组织机构树实现，或者是通过数据共享配置实现。下面，我们通过具体案例来讲解这两种方案。
　　方案一：通过组织机构树实现
　　这种方案是根据用户所在组织机构树中的节点位置，来判断用户能够操作的数据范围，利用组织机构树默认的上下级关系，支撑数据权限的配置。
　　该方案配置简单，是常见的数据权限解决方案，通过下面的2个案例来为大家作具体阐述。
　　案例一：如何配置系统中各角色的数据权限
　　门店管理系统是用来帮助老板管理门店日常库存、销售、会员、促销、营销数据报表的一类软件。
　　在一个门店管理系统中，我们设定组织机构为：总公司省级分部县市级分部门店4级架构；并创建好默认管理员默认普通用户默认经理用户三个角色；数据权限范围分为：本人、本人及下属、本部门、本部门及下级部门、全部。
　　图1
　　如图1所示，不同角色，可以根据实际需要，设置所需的数据权限范围。
　　如默认管理员可配置全部数据权限，监管整个公司的数据；默认普通用户可配置本人数据权限，仅操作自己创建的数据；默认经理用户可配置本部门及下级部门数据权限，操作本部门及下级部门员工创建的数据
　　建议：
　　数据权限的配置，可以根据操作系统用户量的多少来决定，给账号还是给角色配置数据权限。如果操作系统的用户少的话，可以直接给账号配置数据权限，更灵活。
　　数据权限的范围也不完全为本人、本人及下属、本部门、本部门及下级部门、全部这5种范围，可以根据实际业务需求调整。
　　案例二：通过组织机构图来详细阐述某个账号的数据权限
　　图2
　　如图2所示，在一个门店管理系统中，自上而下设立了5级组织机构，各机构下分别开设账号登录系统。
　　账号1是公司管理员角色，处于根节点的位置，且数据权限范围是全部部门（即所有节点）。因此，在订单管理等功能中，账号1可以查看总公司及其所有子部门的订单信息。
　　账号2是山东分公司管理员角色，是山东分公司的根账号，且数据权限是本部门及下级部门（当前节点及其子节点，即山东分公司及其下属全部部门）。因此，在订单管理等功能中，账号2可以操作山东分公司及其下属部门的全部订单信息。
　　账号5是营业部负责人角色，是末级节点营业部1的根账号，且数据权限是本部门（当前节点，即营业部1）。因此，在订单管理等功能中，账号5可以操作营业部1的所有订单信息，对于上级部门市南分部的数据却没有权限查看。
　　根据不同账号的不同数据权限配置，账号的数据可见范围也不同。依托组织结构的上下级关系，可以迅速配置账号数据权限，满足业务需求。
　　方案二：通过数据共享配置实现
　　以账号间的数据共享为例，通过配置某个账号的什么数据共享给某个账号，来解决账号的数据可见范围，默认每个账号仅可操作自己创建的数据。
　　该方案比较灵活，可以单独设置某个账号每一项功能的数据共享给他人，但是配置起来很麻烦，后期维护也不易，通过案例三，我们来详细阐述。
　　案例三：
　　图3
　　如图3所示，通过数据共享规则，将账号5下销售信息管理模块的全部销售信息的只读权限，赋予账号6，这样账号6登录系统后，就能查询到账号5创建的销售信息，扩大了数据范围。
　　通过数据共享配置实现的数据权限，数据源可以来自某个账号、某个角色、甚至某个部门等，数据权限也可以共享至某个账号、某个角色或者某个部门，可以根据自身业务情况灵活设置。由于配置起来较麻烦，适合对数据权限有严格把控的业务场景，对于绝大部分公司，通过组织机构树的方式实现数据权限的配置，就足够了。
　　结语
　　数据权限一上线，B端功能模块在设计的过程中，就必须要考虑到数据权限的应用场景，如该模块的数据是否需要划分数据权限？数据是默认归属于个人还是部门？如果有人员离职，是否涉及数据转移给他人等。
　　总之，在权限设计过程中，多思考多尝试，总会总结出一些规则，让我们在后期少走弯路。