一直想写一下关于数据权限的配置问题。权限系统的两大体系--功能权限和数据权限之中，功能权限的设计相对简单清晰，而数据权限就比较杂乱，是许多权限设计人员的隐痛。

什么是数据权限？

数据权限就是对用户所查看的业务数据范围进行权限控制。

例如：销售人员只能看到他自己所对接的客户单据；运营人员只能看到自己所管理的商家信息；店长只能看到自己所在的门店的订单信息；采购人员只能看到自己所负责的品类商品等。

在后台系统中，数据权限是支撑工作分工的基础，更是信息安全的重要保障。

数据权限的配置方式

数据权限的各种配置功能眼花缭乱，其实抽象来看基本上不外乎以下两种情况：

1、用人员直接绑定数据资源。

例如用人员绑定门店；用人员绑定品类；用人员绑定客户或商家等。下游各业务系统通过登录后的账号（对应一个人员）从权限系统查询到该账号对应的门店范围/品类范围/客户列表/商家列表……等等。这个比较好理解。

但是需要注意的是：数据权限与人员的组织架构有时看起来会有着千丝万缕的关系，往往在设计中容易混在一起越弄越迷糊。

例如小王是A门店的员工，那他拥有的数据权限就是A门店的不是吗？其实这两者从概念上首先要区分清楚，小王从组织架构上属于A门店，但是有可能由于其他新店开业时人手不足，需要小王同时兼任B门店的工作。

所以组织架构和权限需要分开设计，这是两个不同的系统模块，只是如果为了节省操作的话系统模块之间可以做一些自动同步，例如小王添加为A门店员工后，自动调用权限接口开通A门店的权限。

人员直接绑定数据资源的方式比较清晰，不过缺点就是维护的工作量大，假如品类特别多，每个人都要直接绑定品类的话，得勾选好多次。于是产生第2种方式。

2、将人员通过一个分组的方式绑定权限

这种方式也比较常见。先将数据资源分组，然后用人员绑定分组。常见的分组方式有按照组织架构中的部门，或者岗位，或者单纯的新建分组。说明如下：

1）按组织架构中的部门。

例如门店中经常会按照营业课组进行管理。营业课组是组织架构下的一种部门，一般是按照品类划分的，例如肉品课、果蔬课、水产课等等。每个营业课组中的人只能操作本营业课组所包含的品类业务（业务包含采购、盘点、移库等）。

所以营业课组可以作为一种分组来绑定品类。人员通过绑定营业课组这个分组便与品类关联起来。

这里还是需要注意那个问题：组织架构和数据权限的系统模块要分开。小李是肉品课组的人，但是他不一定只拥有肉品课的权限，有可能需要兼职熟食课的工作。意思就是在人员设置组织架构功能中，一个人只会属于一个部门，但是在人员的数据权限授权功能中，一个人可以同时分配两个分组（部门）。

2）按照岗位分工

岗位它也是人员组织架构管理中的一个信息，每个人入职的时候都会入职到一个岗位。有一些岗位可能自带数据分组属性，例如果蔬采购经理，肉品采购经理等。类似这样的岗位，也可以用来充当分组。岗位跟部门类似，分别于品类和人员相关联，而且也需要从系统边界上与数据权限区分清楚。

3）单纯新建分组

用户当然也可以通过自建一些分组的形式来关联人员和数据资源，分组的名称可以按自己的想法定义。要记得分组的目的是为了人员与数据资源绑定时更快捷，如果资源数据量不大，或分工也不是特别清晰时，就没有必要使用分组。

以上所述的人员直接绑定数据资源和通过分组来绑定数据资源是两种基本的数据资源配置方式，除此之外还有两种较为复杂的权限拓展：

第一种是上级拥有下级的权限

在数据权限的管理中这也是非常常见的一类情况，有些人员本身不绑定太多权限，而是直接拥有他所有下级的权限。

例如一个采销部门的总监或者总监助理，他要拥有查看本部门所有采销管理的供应商所产生采购单的权限。或者一个大区的大区经理，他要拥有下属所有城市的销售经理的客户订单查看权限。

具体的处理方式：在人员身上可以配置以下的权限选项：仅本人、仅本部门、本人及下级 、本部门及下属部门。

一般像组织架构中拥有直接上下级关系的，比如部门总监，可以将权限设置为本人及下级。而像一些助理岗位，比如总监助理、经理助理，或者一些业务支持类岗位的人，他不属于任何人的上级，但是他也要查看本部门所有的数据。所以就用本部门或本部门及下属部门比较合适。

这个权限的配置还可以配置到功能角色或者岗位上。

接口封装的内部逻辑会比较复杂一些。对外提供的接口还是通过用户账号查询数据资源，但是内部就需要通过组织架构查询到人员信息再查询到权限来进行统一封装。

第二种拓展是支持更灵活的兼职情况。

例如小张同时兼任采购经理和销售经理两个职责，但是他做采购时负责的是水果品类，而做销售时销售的是水果和蔬菜两个品类。一般来说这种情况并不是特别多，但是一旦存在的话我们的权限系统要怎么来支持更灵活的配置呢？那么就需要在他的功能权限下面来选择数据资源。功能权限一般是通过功能角色来体现，所以就需要在功能角色下面直接挂数据资源或者数据资源的分组。

这样设计之后，权限系统对下游输出接口时就需要做一层非常复杂的封装逻辑。同时接口中还需要下游传入当前操作的功能是哪个。

需要注意的是，开始也说过这种兼职的情况在企业中并不太常见。系统设计时需要兼顾考虑灵活性和用户操作以及理解的复杂性，取一个平衡点。如果在企业中这种情况只是一个两个的特例，数据资源的量又大时，建议不要设计的这么复杂。

好了，以上就是对数据权限设计的一些经验浅谈，主要是将数据权限的配置逻辑梳理了一下，到设计具体功能原型时其实又是一个考验，有时候一个公司涉及的数据资源特别多，又按品类又按门店又按商家又按客户还要兼容下级权限，怎样让用户清晰理解且便于操作是产品经理的职责所在。不过一定首先要把握住底层配置逻辑不要乱，才能慢慢梳理清楚前端展示。

最后祝大家的系统权限都能灵活健壮。