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

编辑：011 时间：2020-02-21

功能权限”控制的是用户登录系统后能看到哪些模块，操作哪些按钮；而“数据权限”控制的是用户能够看到的数据范围。所谓数据范围，不是指能看到的数据字段，而是指能查出来的数据集合。

例如，针对订单管理列表页，数据范围可能是某个城市的全部订单，也可能是某个门店的全部订单，“某个城市”和“某个门店”决定了2种不同的数据范围。

针对数据权限，常见的实现方案有两种：通过组织机构树实现，或者是通过数据共享配置实现。下面，我们通过具体案例来讲解这两种方案。

方案一：通过组织机构树实现

这种方案是根据用户所在组织机构树中的节点位置，来判断用户能够操作的数据范围，利用组织机构树默认的上下级关系，支撑数据权限的配置。

该方案配置简单，是常见的数据权限解决方案，通过下面的2个案例来为大家作具体阐述。

门店管理系统是用来帮助老板管理门店日常库存、销售、会员、促销、营销数据报表的一类软件。

在一个门店管理系统中，我们设定组织机构为：总公司-省级分部-县市级分部-门店4级架构；并创建好“默认管理员”“默认普通用户”“默认经理用户”三个角色；数据权限范围分为：本人、本人及下属、本部门、本部门及下级部门、全部。

如图1所示，不同角色，可以根据实际需要，设置所需的数据权限范围。

如“默认管理员”可配置“全部”数据权限，监管整个公司的数据；“默认普通用户”可配置“本人”数据权限，仅操作自己创建的数据；“默认经理用户”可配置“本部门及下级部门”数据权限，操作本部门及下级部门员工创建的数据……

建议：

在一个门店管理系统中，自上而下设立了5级组织机构，各机构下分别开设账号登录系统。

“账号1”是公司管理员角色，处于根节点的位置，且数据权限范围是“全部”部门（即所有节点）。因此，在订单管理等功能中，“账号1”可以查看总公司及其所有子部门的订单信息。

“账号 2”是山东分公司管理员角色，是“山东分公司”的根账号，且数据权限是“本部门及下级部门”(当前节点及其子节点，即山东分公司及其下属全部部门)。因此，在订单管理等功能中，“账号 2”可以操作山东分公司及其下属部门的全部订单信息。

“账号5”是营业部负责人角色，是末级节点“营业部1”的根账号，且数据权限是“本部门”（当前节点，即营业部1）。因此，在订单管理等功能中，“账号5”可以操作营业部1的所有订单信息，对于上级部门“市南分部”的数据却没有权限查看。

根据不同账号的不同数据权限配置，账号的数据可见范围也不同。依托组织结构的上下级关系，可以迅速配置账号数据权限，满足业务需求。

以账号间的数据共享为例，通过配置某个账号的什么数据共享给某个账号，来解决账号的数据可见范围，默认每个账号仅可操作自己创建的数据。

该方案比较灵活，可以单独设置某个账号每一项功能的数据共享给他人，但是配置起来很麻烦，后期维护也不易，通过案例三，我们来详细阐述。

案例三：

如图3所示，通过数据共享规则，将“账号5”下“销售信息管理”模块的全部销售信息的“只读”权限，赋予“账号6”，这样“账号6”登录系统后，就能查询到“账号5”创建的销售信息，扩大了数据范围。

通过数据共享配置实现的数据权限，数据源可以来自某个账号、某个角色、甚至某个部门等，数据权限也可以共享至某个账号、某个角色或者某个部门，可以根据自身业务情况灵活设置。由于配置起来较麻烦，适合对数据权限有严格把控的业务场景，对于绝大部分公司，通过组织机构树的方式实现数据权限的配置，就足够了。

数据权限一上线，B端功能模块在设计的过程中，就必须要考虑到数据权限的应用场景，如该模块的数据是否需要划分数据权限？数据是默认归属于个人还是部门？如果有人员离职，是否涉及数据转移给他人等。

总之，在权限设计过程中，多思考多尝试，总会总结出一些规则，让我们在后期少走弯路。

————————————————
版权声明：

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

回复列表