您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识
超级管理员英文_超级管理员英文怎么写
权限,用户,角色超级管理员英文_超级管理员英文怎么写
发布时间:2016-12-08加入收藏来源:互联网点击:
以众包B端的几个管理角色为例,进行“角色行为穷举”:
关联属和权限:属也可以通过同样的方式来进行权限点转化和连接。
以众包C端的规则为例,进行“属群组行为穷举”:
通过盘点,我们在该步骤可以得出一份「角色属权限对应表」。
2.3 设计赋权流程在明确了角色属与权限的关系后,需要去设计赋权的交互方式。
B端管理账号赋权
众包B端用户以产品和运营为主,用户数量和权限数量一般(100以内),有明确的管理职能划分,主要负责管理和监控平台内的多个子模块进展,因此较适用于RBAC基于角色的权限模型。
第一步:明确流程方案
首先,我们需要确认B端数据权限是否需要做分隔处理:
通常仅服务于单个业务的后台数据权限,不需要做分隔处理,可以直接通过角色赋权账号;涉及到多业务的保密数据时,需要做权限分隔处理,数据权限不可以和角色直接关联绑定。如下为数据权限不需要隔离的流程方案:
如下为数据权限隔离的流程方案:
考虑到众包平台期望未来接入更多业务的愿景,我们选用数据权限隔离的流程方案,之后就可以开始设计角色配置方案了。
第二步:创建角色并配置操作权限
首先,我们需要新增一个角色管理页,通过该页面进行角色数据的创建和管理,当业务接入平台时,我们会提供一些默认角色供业务使用。
如果提供的默认角色无法满足业务诉求,那么业务运营可以在该页面内编辑默认角色或新增角色,为角色自定义页面权限和操作权限。 操作项必然依托于页面,因此我们在设计角色配置交互时:
通过Table设计将页面权限与操作权限进行关联配置,在用户提交配置时将页面权限赋予角色,这样可以保障拥有该角色的账号能够查看到相应导航页面并对相关页面进行操作;以嵌套子表格的设计表现一级页面和二级页面的父子关系,当勾选一级页面的操作权限时视为勾选其所有子页面的操作权限;从系统的运行逻辑角度出发,对查看权限(可以看到该页面导航)和操作权限(可以看到该页面内的操作项)进行交互关联,当用户仅勾选某页面的查看权限时,不会联动选中操作权限;当用户勾选操作权限时,会联动选中查看权限。完成角色配置设计后,就需要考虑如何将角色权限与管理员账号进行关联了。
第三步:对账号配置角色和数据权限
前文提到,考虑到业务自有数据的私密诉求和安全考量,因此不能将数据权限直接赋予多业务通用的角色身份,而选择与私密更好的账号进行绑定配置,为此我们需要新增一个账号管理页,通过该页面可以对管理账号和用户账号数据进行创建和管理。
在设计管理账号配置交互时:
遵循RBAC权限模型,通过角色配置项实现对账号页面操作权限的集中赋予,角色配置项采用映射展示项的Checkboxes+Table设计,便于用户勾选角色后能够直观看到对应的角色所拥有的页面权限和操作权限;考虑到频繁请求全量数据权限容易造成接口崩溃,因此在配置管理员权限时,将角色配置和数据权限控制拆成了2步,通过增加环节数降低全量数据请求的频次;众包的数据权限分为项目-车间两级,因此在配置数据权限时会优先引导用户先为账号选择项目数据权限,完成项目选择时会在下方展示项目下的子级权限控制入口,用户可以在项目下继续为账号选择车间数据权限(低频操作)。完成以上角色配置 + 管理账号配置的2步操作后,我们完成了对管理账号的赋权,之后通过将管理账号分发给业务运营,实现业务接入平台后的管理成员就位。
C端生产账号赋权
众包C端的用户分为Freelancer和供应商两类,用户数量大(数千人),权限需要依赖多类复杂的属组合因素(任务类型 x 职能 x 语言 x 学科 x 年级),且需要根据不同业务要求进行调整(随着业务数量增多,调整次数将持续翻倍),且部分业务仍有跨国合规诉求和权限定制诉求,需要根据变量条件来灵活调整,因此较适用于ABAC基于属的权限访问模型。
第一步:明确流程方案
C端用户的赋权设计可以基于推荐渠道用户和普通用户两个角度进行考量。 我们通常会通过线下招募、熟人转推荐和供应商签约3种渠道来招募定向的高质量用户,这部分用户通常会具备相应的基础生产能力,我们可以直接对这类用户进行批量赋权。
当批量渠道用户无平台账号时,我们可以采用如下邀请赋权的流程:
当批量渠道用户有平台账号时,我们可以继续采用邀请赋权的方式,但考虑到减少对用户的干扰,我们也可以采用如下管理员手动赋权的流程:
而针对普通用户,因为我们不了解这类用户是否具备完成任务生产的能力,所以我们需要面向这类用户增加培训考试环节,因此会采用如下考试赋权的流程:
第二步:创建用户群组
因C端用户数量较多,通常我们会基于某类属规则对用户进行标签分组(如高质量数学生产组、高效率英语质检组、低成本知识点标注组),也就是我们熟称的“用户群组”。
角色和用户群组的概念区分: 角色赋予的是主体,主体可以是用户,也可以是用户群组 ;角色是权限的集合 ;用户群组是用户的集合 。
基于“用户群组”进行批量赋权可以极大的提升平台配置效率。 因此,我们需要新增一个群组管理页,通过该页面进行群组数据的创建和管理,当业务接入平台时,业务可以通过该页面将目标用户批量导入对应用户群组内。
第三步:对用户群组配置操作权限
完成群组的创建后,我们需要赋予群组相应的任务操作权限,但C端任务操作权限需要依赖于组合复杂的能力标签(任务类型 x 职能 x 语言 x 学科 x 年级),为此我们需要将相应任务的能力标签具象为易于用户理解的“证书”,而C端用户要获得这些“证书”,则需要进行相应的培训“考试”。
基于“能力证书”的逻辑,我们首先需要新增一个证书管理页,证书管理页用于配置要获得一个任务的操作权限需要用户拥有哪些能力证书。为了满足灵活多变的业务场景,通常一个任务会包含多个属变量组(如工作职责 x 学科 x 学段 x 人群组),因此证书配置的设计也会以规则组的形式,来提供用户对属变量条件进行设置的能力。
在完成配置后,C端的用户在领取任务时将基于任务的属条件来确认当前用户是否已具备所需的证书,若已具备则进入任务操作界面,若未具备则弹出如下的考试引导,需要用户通过考试后才能获得相应的证书。
完成能力证书与任务操作权限的关联后,我们需要基于用户类型来展开不同的路径设计,前文提到,C端用户的赋权设计需要基于推荐渠道用户和普通用户两个角度来进行考量:
推荐渠道用户指通过线下招募、熟人转推荐和供应商签约等渠道来招募的高质量用户,这部分用户通常会具备相应的基础任务生产能力,我们可以直接对这类用户进行批量赋权。因此,我们需要新增一个能力管理页,能力管理页用于配置哪些用户可以通过白名单直接拥有哪些能力证书(任务操作权限),当业务接入平台时,业务可以通过该页面将证书(即任务操作权限)分配给对应用户或群组。
下一篇:返回列表
相关链接 |
||
网友回复(共有 0 条回复) |