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

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

上一篇给大家介绍了“功能权限”设计,本篇主要介绍“数据权限”设计,做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端功能模块在设计的过程中,就必须要考虑到数据权限的应用场景,如该模块的数据是否需要划分数据权限?数据是默认归属于个人还是部门?如果有人员离职,是否涉及数据转移给他人等。

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

 

本文由 @菡子同学 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 1、组织的维度过于简单,数据权限有很多自己行业特点的数据权限划分,比如交易金额、行业、地区、行政级别、交易时间等等;
    2、哪些业务对象要使用数据权限,也有自己的行业特点,并非所有的数据都要使用数据权限;
    总之一句话,数据权限要根据自己的行业特点设计

    回复
    1. 请教下大佬,比如,交易金额,按照行业特点划分是什么意思,项目经历得还是太少😂

      回复
  2. 过于简单权限设置,组织机构+商业业态的话,无法把控,数据权限,功能权限,字段权限,敏感数据权限等,可以到特殊独立用户角色,通用是到权限组

    回复
    1. 回复
    2. 功能性的平台,没有特殊场景要求,做的不够深入,多接触多学习,谢谢大佬指点~

      回复
    3. 是的,与业务场景匹配的

      回复
  3. 挺好的,正在做一块,多交流~! ;-)

    回复
    1. 随时交流呀

      回复