B端用户中心“功能权限”设计,做门店管理系统

B端用户中心“功能权限”设计,做门店管理系统

上一篇文章给大家介绍了“功能权限”的设计。 本文主要介绍“数据权限”的设计。 我做B端用户中心已经快半年了,从迷茫到产品上线。 我总结了一些经验,希望能给大家一些。 帮助。

“功能权限”控制用户登录系统后可以看到哪些模块、可以操作哪些按钮; 而“数据权限”则控制用户可以看到的数据范围。 所谓数据范围,并不是指能看到的数据字段,而是指能找到的数据集合。

例如数据报告,对于订单管理列表页面,数据范围可以是某个城市的所有订单,也可以是某个店铺的所有订单。 “某城市”和“某商店”确定了两个不同的数据范围。

对于数据权限,常见的实现方案有两种:通过组织树,或者通过数据共享配置。 下面,我们通过具体案例来解释这两种选择。

方案一:通过组织树实施

该方案根据用户所在组织树中的节点位置来确定用户可以操作的数据范围,并利用组织树默认的上下级关系支持数据权限的配置。

该方案配置简单,是一种常用的数据权限方案。 下面通过两个案例来详细说明。

案例一:如何配置系统中各个角色的数据权限

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

在门店管理体系上,我们设定的组织架构为:总店-省分店-县市分店四级结构; 并创建“默认管理员”、“默认普通用户”、“默认管理员用户”三个角色;数据权限范围分为:我自己、我自己和下属、本部门、本部门和下属部门、全部。

图1

如图1所示用户角色权限设计音乐音效,不同角色可以根据实际需要设置所需的数据权限范围。

例如,“默认管理员”可以配置“全部”数据权限,以监管整个公司的数据; “默认普通用户”可配置“我的”数据权限,只能操作自己创建的数据; “默认管理员用户”可配置“本部门”及下属部门的数据权限,可操作本部门及下属部门员工创建的数据...

建议:

案例二:利用组织结构图详细阐述账户的数据权限

图2

如图2所示,在商店管理系统中,从上到下建立了五级组织机构,每个组织下设置了账户登录系统。

“账户1”为公司管理员角色,位于根节点,数据权限范围为“所有”部门(即所有节点)。 因此,在订单管理等功能中,“账户1”可以查看总公司及其所有子部门的订单信息。

“账户2”为山东分公司的管理员角色,“山东分公司”的根账户,数据权限为“本部门及下属部门”(当前节点及其子节点,即山东分公司及所有其下属部门))。 因此,在订单管理等功能上,“账户2”可以操作山东分公司及下属部门的所有订单信息。

“账户5”为销售部门负责人角色,是上一级节点“销售部门1”的根账户,数据权限为“本部门”(当前节点,即、销售部1)。 因此,在订单管理等功能中,“账户5”可以操作销售部1的所有订单信息,但无权查看上级部门“市南分公司”的数据。

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

方案2:通过数据共享配置实现

以账户之间的数据共享为例,通过配置某个账户的哪些数据与某个账户共享,解决了该账户数据的可见范围。 默认情况下,每个账户只能操作自己创建的数据。

这种方案比较灵活,可以设置一个账户的各个功能的数据与其他人共享,但配置起来很麻烦,后期维护也很困难。 我们通过案例3来详细说明一下。

情况三:

图3

如图3所示,通过数据共享规则,将“账户5”下的“销售信息管理”模块中所有销售信息的“只读”权限赋予“账户6”用户角色权限设计,这样“账户6”之后登录系统,可以查询“账户5”创建的销售信息,扩大了数据范围。

通过数据共享配置实现数据权限,数据来源可以来自某个账号、某个角色,甚至某个部门等,数据权限也可以共享给某个账号、某个角色、或者某个部门。某些部门,可以根据自己的业务情况灵活设置。 由于配置比较繁琐,适合数据权限控制严格的业务场景。 对于大多数公司来说,通过组织树配置数据权限就足够了。

结论

数据权限上线后,B端功能模块设计过程中必须考虑数据权限的应用场景。 比如这个模块的数据需要划分数据权限吗? 数据默认属于个人还是部门? 如果有人离开公司,数据会转移给其他人吗?

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

文章来源:https://www.toutiao.com/a6795455838979883528/