产品设计-权限管理体系（跨系统权限管理）、数据权限、功能权限

原文链接：权限管理、权限管理体系（跨系统权限管理）、数据权限、功能权限
原文作者：大魔王001
推荐人：东东方

前言：这部分我研究了半年左右，希望能把这些分享给想做东西的人。看到时候肯定会为你解答。愿你能收获一些东西。
已经更新了数据权限，我讲一下思路，数据权限就是控制菜单下每个功能能看到哪些数据。先要整理好当前功能数据全量，然后勾选能看到哪些数据。
功能权限：有什么按钮，哪些页面可见。（比喻：一个盛水的碗）
数据权限：有什么数据，哪些数据是哪个人可以操作（可见）的。（比喻：碗里的水）

一、需求分析

随着系统的系统越来越庞大，权限管理这个功能也越来越重要，如果我们单纯从权限管理出发讨论，我们不能遍及各个子系统的权限管理，所有我们引入权限体系这个维度，来对整个系统的权限管理作出更宏观的理解和梳理。权限体系是着眼于整个系统的权限管理，实现对权限管理的有逻辑性、有序的使用。举个例子来说，一个车的轮子就像权限管理功能，每个子系统的权限管理，相当于车的一个轮子。而车的驾驶系统就是权限管理体系。深入的了解权限体系，能让整个系统的权限更有逻辑性、更有序，让不同类用户的初始权限及某些权限的变化都比较明确。

二、权限管理和权限体系的区别

首先我们明确一下，权限管理和权限体系的区别，这样也更方便我们后期更好的使用权限，进而更好的服务于整个系统。
权限管理：这个是从功能角度的定位，是通过一系列操作完成用户的权限的分配和管理，实现不同的用户在系统中不同的数据范围、功能、管理等。本系统都过用户、部门、角色、功能之间的关联关系，实现对用户功能、数据授权。具体关联关系如下图：


权限体系：这个概念区别于权限管理，着眼更高一些，是从整个系统实现的角度出发。不局限于某一个部分的权限管理。通过整体的权限管理，实现整个系统的用户结构区分、不同用户的功能区分。举个例子，比如出生的婴儿，会趴会吃东西，这就是基技能，然后通过学习学会了走路，吃饭，说话等技能。我们把某一类用户的基础技能定义为基础角色，把后来通过权限管理添加的“技能”称为个性化角色，后文中便于区分。当然在实际应用中，我们看到的角色都是个性化角色，简称为角色。而基础角色都是通过预先设定好的，在每一次创建用户的时候，已经授权给这个用户了。不同的子系统都通用这一套构建角色原理。结构图如下：

三、权限体系的实现价值

跨系统解决了角色问题，从系统的角度把角色定义和分类，让每一个新建（注册、创建）的用户都有一套默认的角色，让系统分类有序、逻辑通顺。
比如上图，跨几个子系统时，我们可能有不同身份的用户，我们只要通过几个基础角色的组合即可以实现用户身份分类，从系统角度着眼，不要局限某一个子系统，例如下：
身份A=基础角色a+基础角色b+基础角色e
身份B=基础角色a+基础角色d+基础角色e
身份C=基础角色f+基础角色h+基础角色g
。。。。
。。。。
解决了身份问题，我们就可以不考虑身份问题，直接关联个性角色给某个用户，让用户可以控制目标功能，访问目标数据。
用户（小李）={身份（基础角色集合）默认不显示在前端操作页面+个性角色}小李是新建服务管理员，只要关联服务管理的角色给小李就可以了。

四、权限体系可能存在的疑问

附，部分可能的疑问如下：

1.问：为什么权限体系不放在一起对所有的用户进行管理，还要下分几个子系统呢？
答：其实这个主要原因是，不同的用户是由不同的人进行管理，每一部分权限管理都有自己的管理员和有可能不同的功能。

2.问：如果不用角色是否能实现当前的功能？
答：即使你不用角色这个概念，但是实质的实现方式还是类似的。需要对每一个用户都授权一次，然后每次用户访问页面的时候，通过已经授权的列表查用户可访问的资源及可用的功能，用户对展示的资源进行操作和访问。其实角色仅仅是实现了方便管理和方便梳理逻辑，把每一个节点都串联的很有序。是一个中间量。

3.问：角色与功能关联（授权），有什么规则么？
答：首先看一下角色本身的组成，一部分是当前角色下，都具有那些功能或者数据权限，一部分就是可以关联用户和部门。针对于角色，把这个角色与用户关联后，达到的结果就是这个用户可以控制和浏览这个角色所关联的功能和数据。某一个用户通过几个角色的组合（取功能和数据权限合集），达到一个目的，就是让当前用户可以操作目标功能和浏览目标数据。所以在组合的前提下，角色的关联的功能尽量可复用性比较强，然后通过其他的觉得来组合达到目的。尤其是基础角色，让角色通过几次组合，可以覆盖到所有用户身份。

4.问：除了权限管理，还有那些地方会涉及到角色变化？
答：比如用户认证、创建企业、加入企业后，可操作的功能增加、可访问的数据增加，都是通过角色来实现的，每次通过后，把一个基础角色与用户关联起来，实现用户功能和可访问数据范围增加。

用户权限

身份变化

以上身份变化对应的功能变化，都是依靠基础角色和个性化角色来转换。
如果没有权限体系，画红色部分的地方就需要单独授权。
附：
权限管理（跨部门）简单设计思维导图：

单平台权限管理设计思维导图：
这
以上权限管理设计比较简单，还有更加复杂的情况，可以自己研究一下，我简单提出一下思路。
职位（角色包）、组织（为了某个目的建立起来的人员集合，方便授权管理）、数据授权（连同角色可以一起授权，也可以放在部门中直接设置某个人为管理员）
还有很多，大家可以自己思考，比如一个人管理两个部门怎么办，更换部门怎么办，邀请怎么办。封闭平台可以随意创建用户，如果把权限管理应用于可以注册的平台怎么办。
在公司架构下，默认的部门是否要有。比如“其它部门”，导入后进入其它部门进行再分配。
公司根节点是否可以放一些领导层和管理层如CEO.

数据权限新增阐述

以下是数据权限，数据权限可以控制组织、可以控制数据域（比如，10个门店，有的人能看到1个门店的数据，有的人能看到10个门店的数据），但功能权限可以是相同的。功能权限决定了你能操作什么，数据权限决定了你能看到什么。
做个比喻，功能权限就像是容器，决定了有什么功能，数据权限就像水，决定了你容器内放的是什么。功能权限和数据权限是相互独立的。

数据权限如上图所示，就是在创建角色的基础上，增加了控制数据的范围。数据可分为两部分，一部分是组织关系数据，即某些部门和人在权限管理中的可见性。另一部分是作用域数据。
组织关系数据
举例：针对企业管理平台，A公司有100人两个部门（a和b），原来我们做的是，把权限管理授权给某个人（user）时候，把所有的部门和人员可见性都授权给user，包括对a部门和b部门及两个部门内的人员。现在我们可以分开授权，可以授权数据a部门及里边的人给user1管理，授权数据a部门和b部门及里边的人员给user2管理，等等。比较灵活。
域数据
举例：因为数据比较零散，组织关系数据，直接授权某个人或者某些部门即可。域数据不好针对某几条数据进行授权。需要有一个域来限定范围。比如，我授权服务管理这个角色给用户a，a可见全部数据，但我们不好授权给a某几条数据，因为数据是不断产生和变化的。
所以我们授权一个域，域内的数据都是a可见的，我可以授权某一类服务审批给a管理，比如科技类服务审批。

如果做数据权限。角色列表只能看到与自己关联的角色，不能删除与自己关联的那个角色。可以自己创建，新建的角色都是小于等于自己的数据权限。可操作的角色都是小于等于自己的权限。
超级管理员可以新建角色。超级管理员以下的权限管理员，所创建的角色都是自己角色的子角色。这样做的原因是，避免角色共享时带来很多大家互相不了解的角色。角色树也逐步完善了。


针对数据权限可以解决user1授权给user2、user3之后，如果授权时，user2也在授权给user3的部门里。数据可见、功能可操作。就能删除。数据授权，不包含授权给自己的人的数据权限。User2，user3看不到user1.

父子角色、复制角色

某一个角色的父角色一定是大于等于子角色的功能权限和数据权限。
在角色树父角是子角色的根。
复制角色就是把某个角色的功能权限和数据权限完全复制过来。复制后为同一个父节点。复制角色可以更改功能权限和数据权限，但不能大于根节点功能权限和数据权限。
必要性阐述：当A把权限管理授权给B时，B的角色列表能看到的角色为B所关联的角色，此时B一定有一个角色（a、b、c、d至少有一个）。B所创建的角色必为自己所关联的角色的子角色。不能超越自己的角色。这样下来有两个好处。1.B的角色范围可以控制，2角色列表比较清晰。（这个维度可以从整体看，超级管理员的部分不会增加很多角色，而所增加的都是自己创建角色的子角色）