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

20 评论 29453 浏览 180 收藏 8 分钟

上一篇给大家介绍了“功能权限”设计,本篇主要介绍“数据权限”设计,做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协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 感谢分享

    来自四川 回复
  2. 感谢分享,大有收获

    来自河南 回复
  3. 好文章,看了有收获,感谢

    来自广东 回复
  4. 本人及下属是什么意思?怎么确定A员工是B员工的下属呢?

    来自浙江 回复
    1. 组织机构树吧

      来自北京 回复
  5. 疑问:
    在没有数据规则的前提下怎么限定义自己所能看到的数据(有的单据是有直接负责人,有的是通过类似区域的规则间接指定负责人)?
    文章提到的:数据范围可能是某个城市的全部订单,也可能是某个门店的全部订单。

    来自广东 回复
  6. 权限是设计完再考虑,还是设计的一开始就要考虑

    来自内蒙古 回复
    1. 还是要看实际业务需求,有的系统体量小,用户角色单一,其实是不需要的;
      但如果业务角色分工明晰,那一开始就需要考虑,哪怕一期不做,也要告知开发同学,架构上做好设计

      来自北京 回复
  7. 写的很精简,没有废话,很不错。目前正在做B端的权限设计,希望能够进一步和大佬交流。

    来自浙江 回复
    1. 谢谢鼓励!

      来自北京 回复
  8. 1、组织的维度过于简单,数据权限有很多自己行业特点的数据权限划分,比如交易金额、行业、地区、行政级别、交易时间等等;
    2、哪些业务对象要使用数据权限,也有自己的行业特点,并非所有的数据都要使用数据权限;
    总之一句话,数据权限要根据自己的行业特点设计

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

      回复
    2. 有些公司的订单就有金额数据权限一说,一定职级的人只能看到一个金额范围的订单。

      来自广东 回复
    3. 恩恩 了解了~

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

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

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

      来自四川 回复
  10. 挺好的,正在做一块,多交流~! 😉

    来自广东 回复
    1. 随时交流呀

      回复