今天和大家一起探讨权限管理方面的设计心得。权限管理，是B端后台系统一个重要的组成部分，属于底层的支撑功能，系统内所有的功能，甚至字段的增减都涉及到权限的分配和管理。因此怎样配置后台的权限系统，以适应多变业务需求，是今天笔者和大家分享的内容。

文章目录

• 控制权限的主体
• 权限管理模型
  • 通过角色控制账号权限
  • 通过简档控制账号权限
• 权限管理的分类
  • 菜单权限
  • 操作权限
  • 数据权限

一、控制权限的主体

后台系统是通过账号登录的，账号用户控制每个员工的权限。

二、权限管理模型

1. 通过角色控制账号权限
   除非后台账号数量很少（20个以内），，否则一般不会直接对账号配置权限，因为用户基数比较大的情况下，很多人的权限都是一样的，如果管理员给100人甚至更多授权，工作量巨大，因此引入了“角色”的概念。一个角色可以与多个用户关联,管理员只需要把该角色赋予用户，那么用户就有了该角色下的所有权限。角色起到了桥梁的作用，这样设计提升了效率。这种权限管理的设计模型如下，一个账号可以对应多个角色，每个角色对应不同的权限。

   
   
   角色-权限管理模型

2. 通过简档控制账号权限
   一些大型的公司，用户数量较大，不同部门下的角色，权限是一样的，比如英国部下的销售人员和美国部下的销售人员权限一致，如果每个新增一个功能，所有角色都需要修改权限，那么对于管理员来说，维护成本巨大，因此可以引入简档的概念。笔者所在的公司，后台账号大约有500个，角色有80多个，简档仅有10个，权限变更时，只需要修改这10个简档就可以了，效率非常高。这种权限管理的设计模型如下，一个账号对应一个简档，每个简档对应不同的权限。这种模型还有一个好处就是，可以利用上下级的角色关系，控制数据的权限，这方面在下面详细说。

   
   
   简档-权限管理模型

3. 通过账号、角色、简档都可以实现系统权限的控制，没有说哪种方式是最好的，如果公司少于100人，角色不多，完全没有必要采用简档控制权限的方式，关键是根据自己公司的业务特点选择最合适的方案。

三、权限管理的分类

上面说到的是控制权限的媒介，下面重点讲解权限管理都包含哪些内容，应该怎样进行设计。

1. 菜单权限
   即用户在系统中可以看到的页面,由菜单来控制,菜单包括一级菜单、二级菜单,只要用户有一级和二级菜单的权限,那么用户就可以访问页面。如图所示，即对应该角色/简档的用户对于分销管理、运营管理等在菜单栏没有入口。

   
   
   菜单权限配置

2. 操作权限

   1. 操作权限分为对对象的操作权限和对字段的操作权限。对象的操作权限包括查看，创建，编辑、删除。用户点击删除按钮时，后台会校验用户角色下的所有权限是否包含该删除权限，如果是，就可以进行下一步操作，反之提示无权限。如图所示，即对应这个角色/简档的账号对接送机订单仅有查看的权限，没有创建、编辑和删除的权限。

      
      
      对象操作权限配置

   2. 字段权限是指对记录对应属性的操作权限，字段的操作权限一般有2种，可查看权限和可编辑权限。配置了可查看全看，即用户可以查看该字段，没有配置该权限的账号，不能在页面上看到该字段。配置了可编权限的账号，可以编辑该字段的属性。如图所示，对应该角色/简档的用户只可以查看该对象的客户字段，不能对客户进行修改。

      
      
      字段操作权限配置

3. 数据权限
   1. 通过角色/简档控制数据的查看和编辑权限： 数据权限是指每个账号可查看的数据是不同的，可以通过角色/简档配置对不同对象的数据全新，这种设计方式上面的操作权限已经详细介绍过。
   2. 通过对象控制公用权限和专用权限： 在新建对象时，可以设置对象的公用权限和专用权限，公用权限是指该对象下的记录，所有账号都可以访问。专用权限是指只有创建人可以查看记录，其他人没有权限查看。
   3. 通过角色控制上下级数据权限： 在实际的场景中，上级往往需要查看下级的数据，设置数据的专用性无法满足该需求。比如美国部销售总监需要看到其部门下的用户数据,英国部销售总监需要看到英国部下的用户数据。解决方案是通过角色判断账号间的上下级关系，上级可以查看下级的角色。这也是通过简档而不通角色关联权限的好处，因为通过账号关联角色，再通过角色关联账号的话，账号和角色间一般是多对多的关系，这样就无法分辨账号间的上下级。通过账号关联简档，简档关联权限，可以保证一个账号只有一个角色，从而可以判断出账号间的上下级关系。
   4. 通过共享规则控制数据权限： 有些情况，账号需要查看某个对象下的一些记录，但是该账号和创建记录的账号在组织架构上没有上下级关系，比如美国财务部需要查看美国销售部下的订单数据，同时为了数据的安全性，不能给美国财务部的账号查所有业务部门的订单数据。这时就需要用到共享规则。共享规则的本质是把符合一定条件的记录共享给一些账号，共享后这些账号可以查看或者编辑这些数据。共享规则的配置，需要确定以下四要素：
      1. 共享的对象：确定共享的是哪个对象的数据。
      2. 共享数据的条件：确定该对象下的哪些数据需要共享。
      3. 共享的账号：确定这些数据需要贡献给哪些账号。
      4. 共享权限：确定共享后，账号对这些数据的权限，分为只读和编辑权限。

总结：今天和大家探讨了权限设计的2种模型和权限设计包含内容。大家可以结合公司的特点，选择合适的设计方法。在实际项目中,会遇到多个系统,多个用户类型,多个使用场景,这就需要具体问题具体分析,但最核心都离不开这些方法，我们可以在其基础上进行扩展来满足需求。