我是一个产品,在设计一套B端的权限系统,开发起来很复杂,我的设计是不是有问题?

关键词:权限,角色,用户,部门,岗位用户可以分配权限和角色岗位可以分配权限和角色部门可以分配权限和角色用户继承岗位的权限和角色,岗位继承部门的权限和角色这样的继承是不是有问题?
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 326 浏览
  • 略问用户 提出于 2021-01-16 09:53:12

17 个回答

xxxxxa

业务层面没有问题,产品层面感觉略复杂

最简单的还是标准的RBAC:给角色分配权限,给用户分配角色

然后将部门和岗位当成角色,写一个岗位和角色的映射关系,例如客服部门是一个角色A,客服部门中的客服经理和客服小妹分别是一个继承的角色A1和角色A2,之后这个客服部门新开的角色,都继承于角色A。

如果客服经理下面还有层级,那么客服经理为他的手下新建的角色,就只能继承于角色A1。

例如一个新用户如果入职的时候是客服经理,给他定岗的时候就映射分配了角色A1,但是他又需要其他部门的权限,申请审批通过后,可以新建一个角色B(跨部门的权限),给他同时分配角色A1和角色B,他又招了一个小弟,那么他就可以给小弟新建并分配角色a1和b1,分别继承于他的A1和B。

这样应该没问题吧……



还有数据权限的,分两种,1、一套系统有多套数据源,2、不同角色查看不同的数据

1、如果是偏C端的,例如给商家使用的后台商品管理系统,这样的数据权限应该是绑定商家账号的,每一个商家查看的都是自己的数据,登录的时候通过账号绑定的权限进行读取。

2、如果是内部使用的系统,例如客服部门不能查看财务部门的数据,那么数据权限可以和角色一样绑定。

请先 登录 后评论
xxxxxa

点进来之前我猜测是权限交叉的问题。看了是猜对了。

首先,岗位和部门不需要像用户一样分配权限和角色,这两个直接融合到角色里面。不过有一点需要注意,你的需求我并不清楚,例如为什么要给予岗位继承部门的权限和角色的功能。所以只能结合我的猜想来分析。

1. 用户。这是最简单的直接划一个池子。

2. 角色与部门。部门当做角色的子集,我猜测这样做是不同部门能够看到数据(菜单)要求不一样,如果是这样,那么把部门看做角色的一个子集就行了,属于所有部门(或不属于任何部门)就拥有查看所有部门的权限,属于某一部门就拥有查看某一部门的权限。这样既保证了公司领导、公司管理员、部门管理员、员工的权限适当,又让整个权限划分不那么乱。

3. 角色与职位。其实不建议把职位纳入权限关联当中,原因是即使完全相同部门的相同职位,做的事情有可能是不同的(互补的),可以仅仅作为显示用,不要纳入权限管理。硬要纳入也可以,作为部门的子集。

总结:其实要建立一个超过2维的权限是可行的,如果了解矩阵,理清思路是可以实现的,但一般没必要(你和程序员都得有这个能力)。如果一般不太了解矩阵,建议还是采用上述方式,强行利用树形结构,将2维以上的权限压缩至2维(2维只需要一组多对多的关系,3维需要三组,4维需要6组)。而你的题目的思路比较混乱,是属于从“使用者”的角度去思考问题的,列出的是一个矩阵乘另一个矩阵的关系,在搭地基的时候就搞那么复杂,后期出了问题我保证你都没法分析是哪块的问题。

最后补充一下,权限有三个类型,功能、页面、数据,你可以简单看成都是一类——根据实际情况填Y跟N就好了,这其实并不难。

请先 登录 后评论
xxxxxa

主要看你的权限体系是为了解决多大的问题,除非是超大量级的B端系统,一般的权限设置不需要那么复杂,只要保证数据权限和功能权限的分离即可。

权限挂在角色上控制功能权限,也就是页面可见,功能按钮等的一些权限

人挂在角色上同时继承角色的功能权限(有些系统是可以在单独给人分配权限的,角色只是给了一个初始值,但是这样不便于管理,角色和人的关系就脱离了,不建议这样做)

人本身还有自身的组织架构,也就是部门,用来控制数据权限。也就是通过人与可见数据范围之间的关联关系(一般就是架构)来解决

基本这样的设计可以满足大部分B端需求了。

请先 登录 后评论
xxxxxa

系统开发中,一个树形结构的系统是最稳定,友好,且易拓展的。系统是基于产品的需求开发,故一个好的产品结构也是树形的。你的系统中,权限没有一条依附的主线,比如:我的系统里人是核心,角色是核心,那么不同的角色对应不同的权限,而部门和岗位则是这个角色的描述,描述可以不同。如果部门是核心,那么不同级的部门拥有不同的权限,人和岗位则是这个权限的描述。

根权限表必须是条理清晰的,不要掺杂过多的互相交互,这样既方便你的后来接手者,也可以给你自己少挖坑

请先 登录 后评论
xxxxxa

我们设计的功能要看其商业价值与实现难度孰轻孰重了。

难以实现的功能还少吗?淘宝的千人千面,头条的个性化推荐,游戏中的各种炫酷技能,都是不很容易实现的,但是如果该功能的产生的价值影响相当大,耗费大量人力也要做。

我们需要迎合的是用户,甚至都不是老板。

而在实际的设计过程中,确保主要功能或者是主要逻辑是基础和前提,其他的可以再优化。所以要看你这个功能的重要性了,有些时候也需要和时间和人做妥协,都是难免的,如果设计的太过复杂,降低一些要求,然后再去优化,大家都可以接受。

请先 登录 后评论
xxxxxa

刚好不久前设计过平台的权限系统,强答一波

目前市面上大部分系统权限设计都是基于RBAC模型设计的。

不同的组织架构和业务也是在设计权限系统时需要考虑到的点,所有大部分的平台都是在RBAC模型的基础上做特殊化的处理。

比如,A和B是同级领导,功能权限相同、数据权限相同,但实际上管理的下级组织是不同的情况;比如,A是B的上级组织,当B组织内的权限不变的情况下,和A组织平级的跃升;

采用权限继承也需要考虑,组织内的用户权限变动的情况,比如上级组织的权限变动,组织内的用户权限是否也会改变?

之前设计时就遇到继承问题,公司的实际情况是组织的权限改变,数据权限改变,但组织用户的权限不能改变。后面就果断放弃继承的方式设计。采用最原始的  用户---角色---权限方式

请先 登录 后评论
xxxxxa

首先看你ToB产品的行业,档案管理类,OA类,CRM类,等等,对内部用户权限管理的要求都是不一样的。比如说,有些产品要求有超级管理员,业务管理员,超级用户,一般用户,他们的设置和要求是不一样的。

通用而言,角色为主,刚才举例的4种都是角色,那么围绕角色权限的设置就包括了:
1.角色叫什么:决定默认控制范围,比如超级管理员,一看就知道是管理所有功能的,但不一定能看到业务数据

2.角色是谁:是某一组织,是某个人,是某个level的人群,是某类特殊title的人

3.角色能干什么:这块就可以设置从细到粗了,单个页面上的按钮,展示效果,是否能全选等;某项功能是否可用,某些数据是否可见;某些板块是否可见等等。增删改查。

可能遇到的问题是交叉问题,由几种情况带来:

1.跨部门的管理者和业务员,看到和能操作的功能和数据在不同部门可能不一致.

2.同一人拥有不同审批权限,对A部门有5000元审批权限,对B部门只有3000.

要解决的话,有时需要冗余设计,比如角色上有部门约束等。

请先 登录 后评论
xxxxxa

突然看到,先说结论,有空再补充问题分析:

你这只考虑了一个页面权限控制问题:

用户、角色、岗位、部门

细节性的还要考虑:一人多岗兼职的权限,外来人员的权限,临时组织的权限等等。

但是,在B端系统上,还要有对应的数据权限的问题,也就是:

表单数据权限

字段级字段权限

表单按照某个字段值去判定权限问题

数据权限管理的设计,比页面更要繁琐、复杂。

请先 登录 后评论
xxxxxa

不能说复杂,根据现有的业务情况,留好未来可扩展的地方。权限和用户也不能完全的分开,实际操作中离不开还有审核的过程。如果体量大,有人分配好权限还要有人审核,确保实操时严谨不出错。

image.png

供参考

请先 登录 后评论
xxxxxa

有点复杂,但不能说有问题,主要看你们的实际场景是不是需要这么灵活。

这样实际使用配置和调整权限的都会比较复杂,如果使用的人少可能反而效果是反的,大家都简单配置高权限,或者就使用几个固定的权限。

请先 登录 后评论