产品设计中的权限设计

但凡包含多人协作的系统都会涉及到权限,尤其是商业系统,对权限的要求非常严苛,有的甚至精确到表单的字段级别,这里我们先研究一下常见产品的权限设计,对比其中的异同点,总结一些权限设计的规律。

QQ 群的权限

大部分人对 QQ 群的权限应该再熟悉不过,在一个群中,只有固定的三种角色:创建者、管理员、普通成员,这里简单说明一下:

角色 说明
创建者 创建者可以解散群,设置指定成员为管理员,添加和删除群成员,修改群资料以及正常发言
管理员 添加和删除群成员,修改群资料以及正常发言
普通成员 正常发言

Gitlab 的权限

在代码库管理平台 Gitlab 中,也是固定的几种角色:

角色 说明
Guest 创建 issue、评论
Reporter 创建 issue、评论、克隆项目代码
Developer 创建 issue、评论、克隆项目代码、提交代码、创建分支…
Master Developer 的所有权限、修改项目信息、添加成员
Owner Master 的所有权限、删除项目

在以上两个系统中,在一个资源下(QQ 群、代码库)一个用户对应一个角色。

角色对应的权限点是固定的,无法进行修改和自定义,在这样的设计下,角色不宜超过 5 个,权限点也不宜过多,好处就是清晰明了,学习成本低,比较适合于用户产品。

Discuz 的权限设计

在论坛中,出于运营策略,用户会被分为很多个等级,用户通过发帖获取积分来提升等级,高等级用户可以获得更多的权限,这时的需求就是:

  1. 可以定义角色(用户组)的名称
  2. 可以定义角色的权限点

在 Discuz 中,每个板块下的权限设置是这样的,也就是所谓的“权限矩阵”:

Discuz 的权限结构如下图:

Discuz 的权限结构

一个用户对应一个角色,一个角色对应多个资源(论坛板块),管理员可以编辑角色和资源之间的权限点,以此来实现对权限的自定义。

在论坛的结构中,角色一般不会变化,板块也不常变化,所以角色可以直接和资源关联在一起,如果是资源经常要新增的业务场景,这种设计就很不合理,因为每增一个资源,管理员就要为它新添加权限。

Google Analytics 的权限

在 Google Analytics 中,资源分为 3 级结构

  • 账户层级:一般代表一个公司的所有站点
  • 媒体资源层级:一般代表一个网站
  • 配置文件层级:一般代表网站的某个频道或某个部分数据
Google Analytics 的用户管理

在每个层级下都有用户权限的设置(如上图),如果在账户层级下新增了某个人的权限,那么这个用户在这个账户下的所有站点都有相同的权限,即使未来新建的站点也不用重复设置,如果在媒体资源层级新增了某个人的权限,那么这个用户在这个媒体资源下的所有配置都有相同的权限,即使未来新建的配置也不用重复设置。

Google Analytics 的权限结构

Google Analytics 的权限结构

Google Analytics 的权限设置中并没有引入角色或者用户组的概念,而是在对应的用户旁把所有的权限点都列了出来,也许是考虑到目前的权限点还很少,不需要归组。

在 GA 中,账户和媒体资源是属于资源组的范畴,为一个资源组分配权限后,组内新增或者修改资源,不需再重新赋予权限,比较适合经常要新增资源的业务场景。

其他

在实际的产品设计中,我还遇到过这样的情况:通过角色对权限点进行归组,然后分别给每个账号设置关联的资源和资源组,这样做的缺点是无法对关联的资源分别进行权限点管理。

总结

以上几种类型囊括了常见的系统的权限设计类型,概括下来,权限设计就是用户、资源、权限点、角色的分配与结合,所谓角色,就是权限或者权限 + 资源的自定义和归组,具体如何关联和组合还要看具体的业务场景。



产品设计中的权限设计》上有1条评论

评论已关闭。