产品设计中的权限设计

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

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

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

其他

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

总结

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