如何在RBAC模型基础上构建了一套“B端、数据、平台”产品的权限体系

刀影

一分自信一分成功，十分自信，十分成功。

2019-03-17

在上一篇文章《复盘 | B端产品中，如何构建权限体系》中，笔者讲解了：如何在RBAC模型基础上构建了一套“B端、数据、平台”产品的权限体系——基于数据集合及角色的权限访问控制模型。那么，在该模型基础上，如何针对“权限申请及审批”流程开展交互设计？下文将详细说明。

在本项目中，产品团队从长远考虑，决定将“权限申请及审批”功能在产品内设计成一个完整的闭环，该闭环主要包括“权限申请”及“权限审批”两个流程，参与的角色有“申请者”、“审批者”及“系统”，各角色定义如下：

各角色之间的串联关系为：申请者发起申请——系统寻找审批者——审批者进行审批——系统传递审批结果给申请者。

据此，进一步可以将“权限申请”及“权限审批”划分为4个环节：发起、流转、审批、反馈。

一、权限申请的“发起”

定义“权限申请”的发起用户为“申请者”，根据上一篇文章中构建的“基于数据集合及角色的权限访问控制模型”，在本环节，申请者只需要确认两个信息：数据集合、角色，然后提交权限申请即可。

一般的申请者在发起一条权限申请的时候（只可以申请“普通用户、产品管理员”两种角色，“平台管理员、超级管理员”则直接通过后台配置），由于是使用内部统一的登录（使用工号），那么TA只需要在界面中确认“数据集合”和“角色”两个内容，就可以完成权限申请的“发起”。

PS：为了保证能顺利通过审核，增加“申请理由”作为必填项。

针对用户需要申请权限的需求，这里有两种场景需要讨论：

这种场景下，用户登录进入产品之后，必然会面临无任何数据的状况，所以这个时候需要第一时间提供给他“申请权限”的入口。

这种场景中，可以通过右上角账号名称下的菜单，使用“申请权限”功能，这样可以保证用户使用产品的过程中，在不中断当前任务的前提下，可以随时申请其他数据集合的权限。

当“申请者”发起一条权限申请的时候，该申请需要流转至对应的“审批者”——即权限申请的接收用户，这一过程由系统自动完成。

那么，谁是审批者？

这里就需要给系统定义权限申请的流转规则：

当权限申请的消息顺利流转至对应的审批者后，作为“审批者”的用户会收到一条系统消息。

此时，审批者可以对其进行“审批”。

审批者可以在“消息”内查看权限申请的详细内容，包括：申请者的姓名、工号、部门、申请产品、申请角色，以及申请理由。

根据申请内容，审批者可以直接操作“通过”或者“驳回”。当操作“通过”后——即表示：给申请者开通对应权限；当操作“驳回”时，需要给出“驳回理由”。

需要注意的是：根据流转规则，同一条申请消息会存在多个接收者，也就是会有多个“审批者”同时收到相同的权限申请消息。

针对这种情况，规定：当第一个“审批者”操作后，无论是“通过”还是“驳回”，此条申请消息由“待审批”的状态变更为“已审批”，其他审批者的操作功能随即失效。

当审批者完成一条权限申请的审批后，系统会将此条权限申请的结果返回给相应的“申请者”。这时，作为“申请者”的用户会收到一条系统消息。

申请者可以在“消息”内查看权限申请的结果：

至此，在产品内形成了“权限申请及审批”的完整闭环。

在本项目中，通过“权限申请及审批”的产品闭环设计，为用户提供了一站式的服务体验，作为交互设计师，采取的策略可以用6个字总结：“先分解、后聚合”

作者：胡欣欣，公众号：吹拉弹唱大师（ID：cltcds）

本文由@吹拉弹唱大师原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议