数据权限设计思路(摘抄)

数据权限决定用户能看到什么数据、多少数据量。

我们常接触到的数据访问权限都通过组织机构去划分,在实际应用中,也可能会根据业务增加其他维度的访问权限,如终端门店管理中单独设置门店访问权限,企业多品牌营销中设置品牌访问权限等。

1、以机构层级向下覆盖

根据组织机构树设定用户默认拥有所属组织及以下的数据访问权限。也是最基础的一种数据权限,对于简单的

2、与角色融合的数据访问权限

在设定角色时,同时设置该角色对应功能权限下的的数据访问权限层级:本人、本部门、本部门及以下、全公司。

用户可视菜单中的数据权限由拥有该菜单的角色数据权限而定,且当一个用户拥有多个角色时,角色菜单有重叠的,取两角色中最大数据权限,或数据权限并集。


3、设置部门访问权限

用户默认拥有所属组织及下级组织的访问权限,同时可以自由配置其他部门的访问权限,使得某些数据可以跨部门查看。

相比常规的基于企业组织架构,权限向下覆盖的方式,采用部门访问权限配置可以根据业务需求灵活地配置用户的访问数据范围,避免了父、子、兄弟甚至其他节点间的数据共享纠结,实现跨部门数据共享。

将数据访问权限分配在用户上,足够灵活但也牺牲了维护便捷性,在用户特殊访问权限不多的情况下可以选择该类方法进行设置。

4、实际应用中根据业务需要划定数据及功能权限范围

在实际应用中,仅通过部门设置数据访问权限不一定能满足业务数据的分界要求,在具体的功能里往往通过部门访问权限+其他条件组合的情况来限制用户数据权限范围。

如【部门访问权限+角色标签】,公司内部有领导类的角色,某种业务的原始单据信息需要给高层领导类角色的查看权限,但涉及到管理分权又不想赋予该类人员所有部门访问权限,此时要么单独开入口查询所有信息,领导类角色功能权限中都配置上该页面,也可以在该页面查询数据时,在部门访问权限之前再加一层角色标签的判断逻辑,若角色标签为领导的则不需要根据部门访问权限过滤。

总结及碎碎念

B端系统权限设计中,系统权限区分为功能权限和数据权限,分别对应系统中的功能模块和系统中的数据,功能权限大多基于RBAC模型,并可根据业务需要引入角色继承、用户组、角色标签等概念,数据权限主要基于用户机构、角色,或单独在页面中根据实际需要进行配置。但最终,所有的设置都是需要基于业务,先有业务、需求后有产品,只是权限配置这一功能模块偏向于公司层面要求,受公司业务形态影响较小,所以能抽象出一套较广泛适用的系统方法。

你可能感兴趣的:(数据权限设计思路(摘抄))