产品设计中的权限设计

作者: 耗子吴 | 来源:发表于2015-01-04 20:50 被阅读1672次

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

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

    其他

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

    总结

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

    相关文章

      网友评论

      • 79a4e70506c1:资源可能是有层级关系的,用户组可能也是有层级关系的,权限是资源和用户/用户组之间的映射,角色其实定义的也是用户组,当用户分组是一种矩阵式关系(即不是一颗纯粹的树时),适合将角色引入权限管理中。

      本文标题:产品设计中的权限设计

      本文链接:https://www.haomeiwen.com/subject/thzatttx.html