产品经理要做的操作权限/数据权限设计

数据权限决定用户能看到什么数据、多少数据量。

我们常接触到的数据访问权限都通过组织机构去划分，在实际应用中，也可能会根据业务增加其他维度的访问权限，如终端门店管理中单独设置门店访问权限，企业多品牌营销中设置品牌访问权限等。

1、以机构层级向下覆盖

根据组织机构树设定用户默认拥有所属组织及以下的数据访问权限。也是最基础的一种数据权限，对于简单的

2、与角色融合的数据访问权限

在设定角色时，同时设置该角色对应功能权限下的的数据访问权限层级：本人、本部门、本部门及以下、全公司。

用户可视菜单中的数据权限由拥有该菜单的角色数据权限而定，且当一个用户拥有多个角色时，角色菜单有重叠的，取两角色中最大数据权限，或数据权限并集。

3、设置部门访问权限

用户默认拥有所属组织及下级组织的访问权限，同时可以自由配置其他部门的访问权限，使得某些数据可以跨部门查看。

相比常规的基于企业组织架构，权限向下覆盖的方式，采用部门访问权限配置可以根据业务需求灵活地配置用户的访问数据范围，避免了父、子、兄弟甚至其他节点间的数据共享纠结，实现跨部门数据共享。

将数据访问权限分配在用户上，足够灵活但也牺牲了维护便捷性，在用户特殊访问权限不多的情况下可以选择该类方法进行设置。

4、实际应用中根据业务需要划定数据及功能权限范围

在实际应用中，仅通过部门设置数据访问权限不一定能满足业务数据的分界要求，在具体的功能里往往通过部门访问权限+其他条件组合的情况来限制用户数据权限范围。

如【部门访问权限+角色标签】，公司内部有领导类的角色，某种业务的原始单据信息需要给高层领导类角色的查看权限，但涉及到管理分权又不想赋予该类人员所有部门访问权限，此时要么单独开入口查询所有信息，领导类角色功能权限中都配置上该页面，也可以在该页面查询数据时，在部门访问权限之前再加一层角色标签的判断逻辑，若角色标签为领导的则不需要根据部门访问权限过滤。

总结及碎碎念

B端系统权限设计中，系统权限区分为功能权限和数据权限，分别对应系统中的功能模块和系统中的数据，功能权限大多基于RBAC模型，并可根据业务需要引入角色继承、用户组、角色标签等概念，数据权限主要基于用户机构、角色，或单独在页面中根据实际需要进行配置。但最终，所有的设置都是需要基于业务，先有业务、需求后有产品，只是权限配置这一功能模块偏向于公司层面要求，受公司业务形态影响较小，所以能抽象出一套较广泛适用的系统方法。

二者共同构建出应用系统的权限模型，接下来本文详细描述下列权限的设计理念。

column_permission：

column_handler ：

本文着重描写列权限设计的思想，具体祥设参考

通用数据权限设计——列权限（二）

应用：CRM

优点：1.设置简单，选择按照部门选择

缺点：1.需要维护一套岗位体系

2.不够灵活，不能看到跨部门数据（可以了解到其他部门的 价值 ） 也不能看到上级的数据（有个员工需要根据能力恒定自己的职业规划，那么他会以上级为参考点，去观察上级的销售数据如何）（人事 财务需要看到整个部门的数据，他们也不是领导，他们是专员，而且那些人也不是他们的下属 ，无论如何都看不到数据）

针对角色设置数据权限（实习公司也是这样处理：班主任， 助教， 管理员）

优点：不受岗位框架 影响，可以灵活设置，如果短期内 没有负责到这部分数据，我就取消对应角色权限即可，但不用删除掉这个角色以及权限；再比如 可以设置一个角色“宇宙总局xx指挥中心xx副局”，但实际上不存在这个岗位。

再比如，角色可以多层叠加，比如 华南地区xxx就可以看到华南地区的数据；华东地区xxx就可以看到华东地区的数据；总局可以看到xx所有数据，但是 我们不能让这个人看到所有数据， 只需要让他负责华南与华东即可，则给他两个角色 就好

怎么设置 角色权限呢？

采用 数据规则：规则编辑器

如：客户所在地区 等于 AS地区 且 客户状态 等于 带续签 ，输出结果： 交集

客户所在地区 等于 B地区 且 客户状态 等于 入住   或  客户所在地区 等于 K地区 且 客户状态 等于 签约，输出结果：并集

优点：1. 避免 与岗位直接绑定， 岗位变动 则 权限变动；

2.避免与岗位直接绑定， 僵化 管理，没有角色灵活

3. 可以适合 多种 特殊化场景 （临时需求居多），用完就释放 权限关系，避免数据泄露

缺点：1.需要维护角色 与权限关系

2.数据规则较为复杂，需要进一步管理

3.如果是多层计算，同样数据规则也很复杂

专化 岗位：  提供 岗位 方案  如：销售 （A,B,C都是销售，但A负责a课程的 物料，B负责b课程的人群转化以及转介绍，C负责d项目的引入 ）

不专化岗位：提供 角色 方案    如：销售  人事 （一个月前负责xx项目的招聘工作，一个月后负责xx项目的培训工作）

总结：

数据范围 划分清晰， 准确

尽量减少 维护成本（弄完一套规则体系后尽量不动 维持原态）

设置灵活（可塑，可拆，可整合）

名词解释：

直接下属：辖域 下面一层

所有下属：所有辖域，包括往下一层 往下二层 往下三层，，，

虚拟上级：一个节点

特殊情况处理：

人员变动：  判断人员是否 专化？ if 是，then 岗位；if 不是，then 角色 方案。

部门变动（几乎很少）：

并入新部门： 维持与新部门同个权限位置。

拆分： 经讨论分析，评判每个用户的角色等级。

移出：  撤销原有权限，载入并维持新权限。

角色：特定权限的集合； 

权限：角色可使用的功能，分角色的功能权限和角色的数据权限；

RBAC设计方案：基于角色的权限设计方案,更好的管理用户；

操作类型：对资源可能的访问方法，如增加、删除、修改等； 

 功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等；

 资源：系统中的资源，主要是各种业务对象，如销售单、付款单等； 数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等；

 数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值；权限设计原则：第一：权限的粒度要做到最小，保证在权限分配时，只赋予用户足够完成其工作的权限；第二：避免出现权限互斥的情况

权限设计原则：第一：权限的粒度要做到最小，保证在权限分配时，只赋予用户足够完成其工作的权限；第二：避免出现权限互斥的情况；

所以基于数据的权限设计（数据权限则是控制你可以看到哪些数据，比如市场A部的人只能看到或者修改A部创建的数据，他看不到或者不能修改B部的数据。）

第一步梳理：梳理层级关系（我们可以找出每一个层级的BOSS）

超级管理员：

集团管理员

城市管理员（我们也可对这个城市组织节点授权）

学校管理员（我们也可对学校组织节点授权）

部门管理员（我们也对对这个部门组织节点授权）

 第二步：每一层建立角色

每个后台用户可以自定义角色，给相应的用户授权，每个后台用户的权限是上一个后台用户权限的子集，后台用户创立角色的权限是子集的权限子集；这里也可以首先给城市，学校，部门这个组织节点分配权限，当每一层的管理员建立角色分配权限时只能是这个城市权限的子集；

第三步：给角色授权

     这里我要将所有的权限进行打散：系统功能的筛选无非是从：系统名称-模块名称-功能项（这里的功能项已经拆解到按钮级别了）

第四步：给用户授权

 角色创立了，我们就可以对用户进行授权，角色和用户的关系可以是一对一，也可以是一对多的关系；

总结：

     以上就是本人对如何做权限设计的总结分析，仅供大家参考，希望在工作中能够帮助到大家，也希望大家一起多提意见，指出不足，感谢阅读！

在一套后台管理系统中，系统通常会有多种需求的用户登陆。例如系统维护人员、运营分析人员、文案编辑人员、部门管理人员等等，而系统维护人员登陆要看到日志界面和服务器监控界面，文案编辑人员要看到文章界面等等，不同的用户登陆到后台还需要展示不同的菜单和界面，

单单运营分析人员，在系统中可以可能有A分公司运营助理、B分公司运营主管、C部门运营经理、华东大区运营总监等等类型，A分公司的运营助理只能看A公司的运营数据，C部门运营经理只能看到C部门的运营数据，大区运营总监应该要看到属于华东大区的所有公司以及部门的数据，不同人员能够查看的数据范围应该是不同的

其次，上述提到的的文案编辑人员，还会区分出总编辑，和文案撰稿人，虽然同样能看到文章管理界面，但总编辑拥有添加、编辑、删除、审核、发布等功能，普通文案只有有添加、修改的权限。

本文将对上述提到的场景提出一种基础的解决方案。

【 角色】： 系统运维、运营分析、部门职员这类拥有不同权限功能的标签，我们称之为“ 角色” 。

【 组织部门】： A分公司、C部门、华东大区、无论大小我们统称为“ 组织部门” 。

【岗位】： 运营助理、运营主管、运营经理、运营总监我们统称为“ 岗位” 。

【 数据权限】： 大区运营和部门运营所能看到的数据范围不同，我们称之为“ 数据权限”。

【 资源权限】： 文章管理撰稿人比总编辑少了审核、发布的功能，这些功能我们称之为“ 资源权限” 。

有了角色，部门组织，岗位，数据权限，资源权限这5个概念的结合就可以结合出满足一般使用场景的权限设计。

      我们将数据权限、资源权限接关联在一个角色上，然后将关联好的角色与用户绑定，这样就完成了权限对用户的分配。另外，我们也可以将角色关联在某个部门的岗位上，然后用户只要填写所属部门和岗位即可获得权限。

     比如文案总编辑、撰稿人、审稿人、编辑助理这类有特定的功能职能的用户群体，我们能就可以创建成角色。但要注意的是，角色一般是可以多个同时并存的。比如创建一个新文案负责人，组织允许他既可以自己撰稿，也可以帮助别人审稿，这时候往往不会在当独为他设计一个撰稿审稿人角色，而是同时为他分配撰稿人+审稿人两个角色。这样，该用户的权限就变成了他所有角色关联的权限之和。从而减少因为权限的交叉带来的冗余角色。

    岗位和角色的概念其实是挺相似的，一个岗位一定程度上代表了他在组织中的角色。然而同样的岗位在不同的组织部很可能是不同的：   例如A部门的采购主管和B部门的采购主管。同样是主管的岗位，但A采购公司规定可以查看整个部门数据、不允许查看订单，而B采购可以查看订单数据、但不允许查看部门其他采购主管的数据，从而造成了同岗不同权。

    这时，我们可以单独为这些部门各自创建岗位，并将角色组直接关联在各自的岗位上。例如在A分公司中分配一个岗位叫做采购主管， 然后我们为这个岗位预设好 “采购数据分析员”，“采购数据录入员”，“订单审核人员”的角色。 这样以来，当A公司来了一位新的采购主管，我们只要为他创建好账号，然后为他设置这个岗位就可以实现权限的绑定。

    撰稿人可以编写文章，审稿人只能查看和标记审核结果，区分两者权限不同，依靠的就是资源权限的不同。我们可以在撰稿人角色上绑定“文章:编辑、文章:查看、文章:添加”这三个资源权限，为审稿人角色绑定“文章:查看、文章:审核”两个资源权限，然后在系统中判断用户的权限来控制相应的入口显示。例如判断用户的权限中不包括“文章:审核”权限，页面就隐藏掉审核的开关按钮。

    数据权限我们目前只分三种，“仅自己数据”，“部门数据”，“全部数据”。如字面含义一样，“仅自己数据”只能查看与自己直接关联的数据，比如自己的销售额，自己的考勤记录。“部门数据”允许用户看到整个部门乃至下级部门的所有成员的数据，比如整个部门的销售额，部门中某个用户的考勤记录。“全部数据”属于最高级别的数据权限，一般是平台的总公司总经理、或者某个系统的总负责人可以使用的到。需要注意的是，数据权限需要结合“资源权限“以及下面将提到的“组织部门“一起组合使用才能发挥效果。

   组织部门可以区分用户在系统中的不同组织、不同等级关系。比如一个平台往往可以接入众多的公司，如图

组织与组织之间有明显的层级架构关系，结合数据权限、资源权限、角色、岗位、就可以灵活配置出例如图中销售部门A的销售经理权限，以及销售团队1的队长权限等等。

上述的结构只是一种方案，当然方案不可能是万能的，具体的实现还需要结合实际项目需求进行设计开发。