
微信扫一扫咨询 >
在我们用到的信息化系统里很多都涉及到一个叫权限的功能,不同角色的用户看到的数据或菜单往往都不同,所以在起初权限设计不是技术细节,而是产品安全与业务边界的底层保障。一旦“乱给权限”,不仅埋下隐患,更可能引发信任危机。今天小编将和大家一起来系统梳理权限的核心逻辑、常见误区与产品经理不可忽视的职责边界,帮助你从源头守住产品底线。

有没有遇到过这种尴尬?
新来的同事,对着系统干瞪眼,啥功能也找不着。
你只是想给销售部开个新功能,结果却不得不拉着IT同事,在几十号人的权限列表里一个个勾选……
出现这些问题,可能是因为没搞懂『权限』和『角色』那点事儿,这次就跟大家聊聊什么权限和角色,以及如何应用。
我们先来回忆下用户人机交互的场景,用户在某个应用内使用某些功能,我们来概括下就是【谁能对什么做什么】,这里【做什么】指的就是我们的权限。
我们通常会把权限划分成,功能权限和数据权限。
功能权限,狭义上大家都会认为是某个功能,例如某个按钮功能。实际上功能权限可以划分不同层级来看,例如应用权限/模块权限/页面(菜单)权限/按钮权限等。
例如:运营同学鸣人,有电商管理后台权限,有商品管理模块权限,能够查看商品主档信息页面,能够去创建产品。财务同学佐助,有财务系统后台权限,有资产管理模块权限,能够查看资产登记页面,能够创建资产。
数据权限,实际上就是能够查看或编辑某些数据,这里有个概念要清楚,我们常说的数据权限,基本都是业务数据,也就是用户产生的数据。所以数据权限也就是指的,能查看或编辑哪些人的数据。
例如:运营同学鸣人和小李,只能查看和编辑各自的数据,互相看不到彼此的数据。
虽然上面举了一些,跟管理后台相关的场景,但权限这部分是互联网应用全场景都通用的,包含C端产品,用户能使用哪些功能等。
说完了权限,接着聊一下与权限捆绑在一起的【角色】。
角色实际上就是一个权限的集合。一般使用场景是用户关联角色,角色关联权限:

可能有的同学会说,为什么不直接用户关联权限呢,其实是可以的,但这样操作起来很繁琐,而且很不利于管理。
试想如果企业有10个人,每个人配置权限;如果有100个人,1000个人呢。
所以引用【角色】这个概念,是为了解决以下几点:
我们了解了权限和角色,那我们接下来举一些使用场景。
鸣人在saas平台注册了账号,登录账号后,使用saas上的功能
用户注册账号,被关联平台设置的默认角色(管理员/普通角色等),角色中一般包含了系统权限,所以账号可使用对应的功能。
鸣人在平台上,想要卖商品,付费开通了商品管理功能,鸣人进入商品模块开始维护商品
用户付费后,平台会分配账号应用权限组,这个组里包含了应用内不同的功能权限(或资源)。所以账号可以使用对应的功能。这样的做法是,可以根据不同的业务,打包不同的应用组,根据业务灵活配置。
鸣人运营不过来,在平台上添加小队成员佐助和小樱。鸣人希望佐助能拥有更多的权限,小樱只能使用商品管理功能。所以鸣人分配了佐助和小樱不同的角色。
平台管理员拥有开通账号和分配角色的权限,不同用户分配不同角色和权限后,用户就可以使用不同的功能。
随着业务越来越壮大,鸣人把忍者村的大家拉了进来做业务,由于人数太多不好管理,所有鸣人把大家分成了不同的部门。然后给不同的部门关联不同的角色权限。这样不同部门就可以专注不同的功能。
通过组织管理,创建不同的部门,把用户分配在不同的部门中。相当于给用户,分配了用户组,在给部门关联角色,实际就是把用户组中的用户,批量关联了角色权限。
业务发展的越来越好,也涉及到了平台数据敏感的问题。鸣人把不同的部门,通过忍者等级,做了数据的分权,不同的部门中,上忍能够看中忍和下忍数据,中忍能下忍数据,下忍只能看自己的数据。火影能看到所有部门的所有数据。
上面就是数据分权的场景,上面场景已经维护好了部门层级。角色中设置数据权限,关联部门,再通过部门上下级关系来做管理。
例“销售经理”角色,可查看销售订单页面,数据权限规则为“可查看当前部门以及其下属部门”
不愧是鸣人,现在开始做海外业务,和砂影村建立了合作关系。但由于不是同一个村沟通起来很费劲。所以鸣人和我爱罗达成协议,在平台上做了授权,两个村子的人可以在平台上共同使用某些功能。这样大大节省了协同成本,提高效率
如果涉及到集团或供应链业务时,不同企业需要在平台上共同使用某些应用,传递某些数据。这个时候就需要平台上,不同主体来建立关系,授权某些功能。一般由链主企业,发起邀请,授权某些功能或权限。这样就可以达成不同企业共享某些功能或者数据。
以上是一些可能涉及到的权限相关场景,提到的处理方式也并非绝对的,还是要看公司的业务场景。但归根结底,底层的逻辑不变的。权限是管理用户到底能做什么能看什么,角色是把人按一定规则组来做类别,使你的系统更加灵活,更加安全,更加有拓展性,才能更好的应对各种业务拓展。