企业管理系统后台/电商后台的设计：权限设计

  • Z时代
  • 2024-01-10
  • 分类：综合

编程

本文结合具体公司业务场景对企业管理后台设计中的系统权限设计的业务逻辑展开了梳理说明，并对相关问题展开了分析，希望通过此文能够加深你对企业管理后台或者电商后台用户权限设计的认识。

权限设计

一、基本概念

权限设计大概可以分为查询权限、页面表单控制权限、操作权限、数据权限。

1.查询权限

查询权限是指针对系统中具体的页面有访问的权限。例：整个系统中有三十个页面，A员工权限只能查看其中的十个页面。

2.页面表单控制权限

显示和隐藏权限，可以通过指令例如：v-has=“name”，指令值“name”为收钱标识，可对该标识进行“显示/访问”控制，比如Jeecg-Boot就做到的这种权限控制。

3.操作权限

操作权限是指系统中的功能按钮有具体的操作权限。例:A员工在查看到十个页面里，其中一个页面是商户查询页面，但是A不是运营人员，所以只能查询商户信息，而不能对商户进行新增、修改、删除等操作权限

4.数据权限

数据权限是指能够查看或下载的数据范围的权限，例：订单页面中包含订单号、时间、状态成本、毛线、分润、销售提成等。不同角色在同一个页面看到的信息是不同的。财务部门可以查看到全字段的，因为需要进行核算。普通技术人员只能看到订单号、时间、状态等基础信息。

二、功能权限设计

对于不同的用户来说，他们是如何获取到这些权限列表的呢？通常有一下几种方案：

方案一：ACL（Access Control List），权限访问列表

原理：通过直接将用户和权限列表绑定在一起，实现的权限管理。

优点：可以为每个用户个性化的设置访问权限。
缺点：当用户数量多，并且拥有相同职能的用户较多时，修改一次权限，就需要耗费很大力气。如销售部有很多的销售专员，因为他们的职位相同，所有获得的操作权限相同，但后期添加或者删除一个访问权限，那么需要给所有人相同职位的人都操作一遍，管理员估计得累死。所以这种设计方案在开发中使用的频率很低。

方案二：RBAC(Role-Based Access Control)，基于角色的访问控制

原理： 通过先创建一个角色，然后将权限列表在绑定在这个角色上，之后再将角色和绑定到用户身上，用户就可以获得这个角色的所有权限。

优点：首先多人可以公用一个角色；再者如果需要对权限进行调整，只需要调整对应角色的权限即可，也就是只需要一次操作，非常易于操作和管理。
缺点：上面优点也是一个缺点，因为权限的操作是按角色来完成的，所以每次修改含有相同角色的用户都会被影响。

如对于同一职位的职员，正常来说大家的权限都是一样的，但是也会有特殊情况发生，比如给其中一个添加或减少部分权限，这个时候就没有办法了。对于这种情况，在现有的设计功能上也是有办法解决的。

通常的方案就是在给角色绑定权限时，先采用权限最小化原则，能少给就少给，然后再做一个角色绑定多余的权限，再把这个角色也绑定给职员，这个时候两个角色的权限就合并到一起了，也就是用户和角色之间是一对多的关系。

对于RBAC还有几个扩展模型：

第一种：在角色上加入了上下级关系，上级可以继承下级的权限。
第二种：在角色之间加入了多个约束关系，如角色互斥、用户基数限制等。

下面是基于RBAC的原型设计图，角色列表页：

角色授权页：

根据RABC权限模型设计，为了更加方便权限的添加与管理，引入了xx组、角色的概念，一个用户可以是单独某一类角色，也可以加入一个群组。如果两者共同存在时，那么此时该用户的权限则是一个角色+群组的并集，一个用户可以同时拥有用户组和角色。

三、权限模型设计

1. 权限模型梳理

根据新零售系统的组织架构，可以得出的结论是每一个层级会有对应的管理人员、运营人员、库存管理、财务等角色。所以在设计权限管理时，需要考虑每个层级之间属于单独的一个组织。高级别的组织可以查看到低级别组织的数据内容，但是低级别组织不允许跨级查看。同时低级别组织可以继承高级别组织的权限，即高级别组织可以自由分配低级别权限内容。

2. 权限模型

3. 权限模型具体内容解释

（1）上图中1和N代表的是数量关系，1是代表只能有一个，N是可以无限个。例如一个组织架构下有很多用户，但是一个用户只能拥有一个组织机构，所以组织:用户=1:N，其他也是以此类推即可。

（2）根据RABC权限模型设计，为了更加方便权限的添加与管理，引入了用户组、角色的概念，一个用户可以是单独某一类角色，也可以加入一个群组。如果两者共同存在时，那么此时该用户的权限则是一个角色+群组的并集。如下图所示，一个用户可以同时拥有用户组和角色。

 

（3）权限集合包含了页面查询权限、功能按钮、数据权限。其中数据权限、功能按钮是依托于页面查询权限，如果单独配置数据权限或功能按钮权限，不配置相应的页面查询权限，那么数据权限和功能按钮权限则无法展示，也就没有实际用。有些特殊情况可以利用这个方式也处理权限。例如当多个页面的都有相同功能，这些功能又是放置在同一个权限上，可以通过控制页面权限而达到控制这部分按钮的目的。

四、总结

以上讲述了系统整体的权限设计的思路，对整体的流程、权限模型、页面设计做了详细的梳理，总结归纳如下：

  1. 梳理业务中组织架构与相关人员的角色关系，输出相应的组织架构图。

  2. 根据组织架构图设计相关的权限模型，模型中将涉及的参数的数量关系梳理清楚，并且在后续的页面设计中使用。

  3. 了解RABC权限设计体系，理解用户、用户组、角色与权限的关系。根据业务的实际场景，将RABC权限体系适用于自身业务。

以上是 企业管理系统后台/电商后台的设计：权限设计 的全部内容， 来源链接： utcz.com/z/517889.html

回到顶部