一个案例,三个角色,简单说下B端产品的权限设计

时间:2021-09-25 06:16:58

权限管理不仅仅是整个系统的一个小小的模块,它一直贯穿整个系统,从登陆到操作到最后的登出。说它相当的复杂真不为过。对于权限,如果从控制力来分的话,可以分为功能级权限和数据级权限。从控制方向来分的话又可以分为从系统获取数据和向系统提交数据。一般来说,权限管理无非是围绕着用户,角色和资源三个方面来进行权限管理操作。

首先,设计的时候要面向开发人员友好,让他们能够很好的理解需求和流程。不至于因为权限的问题影响开发。实际上,一般权限设计都会让在最后进行实现。因为前期考虑太多的权限会严重影响产品开发的流畅性。当然最重要的还是面向用户友好,毕竟产品的使用者是用户,所以逻辑清晰,结构完整的权限体系就显得越发重要。

举例:

派单系统

业务:系统的客户在前台提交一个订单,后台对应的接收到该订单并分派给业务员给客户完成服务。

角色:

  • 老板—查看报表和人员角色修改
  • 业务经理—1.业务管理(接单后对订单进行派发)。2.对业务员进行行政管理(增删改查)
  • 业务员—接单处理,反馈订单信息

第一种情况,简单的完成权限设计

整理一下,从业务流程来看,涉及到的角色其实就是前台的用户,业务经理和业务员。

一个案例,三个角色,简单说下B端产品的权限设计

然后从功能来看:

一个案例,三个角色,简单说下B端产品的权限设计

这样子系统的架构就能够比较清晰的进行设计了。

菜单的总体结构如下:

1 订单管理

  • 1.1未处理订单
  • 1.2已派发订单
  • 1.3已处理订单
  • 1.4处理下派订单
  • 1.5提交已完成的下派订单

2 系统设置

  • 2.1密码修改
  • 2.2个人信息设置

3员工管理

  • 3.1查看下级员工信息
  • 3.2修改下级员工信息
  • 3.3员工角色设置

4 报表管理

  • 4.1查看报表

通过登录的时候对账号类型进行判断或者不同角色通过不同的登录页面进入相应的系统页面

老板的菜单显示为:

2系统设置

  • 2.1密码修改
  • 2.2个人信息设置

3员工管理

  • 3.1查看员工信息
  • 3.2修改员工信息
  • 3.3员工角色设置

4报表管理

  • 4.1查看报表

业务经理的菜单显示为:

1订单管理

  • 1.1未处理订单
  • 1.2已派发订单
  • 1.3已处理订单

2系统设置

  • 2.1密码修改
  • 2.2个人信息设置

3员工管理

  • 3.1查看下级员工信息
  • 3.2修改下级员工信息

业务员的菜单显示为:

1订单管理

  • 1.4处理下派订单
  • 1.5提交已完成的下派订单

2系统设置

  • 2.1密码修改
  • 2.2个人信息设置

这是第一种简单的权限设计思路。但是,如果,如果boss对系统的扩展性要求较高,而非一个过渡性的系统。那边就需要改变思路。重新设计系统了。

第二种情况,完成更加灵活且复杂的权限设计

在这种情况下就要考虑下现有的各种角色以及各种角色对应的操作是否是可修改的。未来是否会变更。

比如查看报表的权限后期业务经理业务查看?随着业务的扩大,业务经理是否变成多个?boss是否能够禁止业务经理的派单权限?在这种情况下,各种权限其实是变成可配置的了。

这个时候就需要转化思路了。首先将所有的功能全部抽离并罗列出来。如下就是简略的功能列表

一个案例,三个角色,简单说下B端产品的权限设计

其中,boss角色一开始就具备所有的功能。他可以创建下级角色—业务经理,创建的同时给业务经理这个角色分配权限(实现方式可以类似技能树0.0)。也可以创建一个归属业务经理的业务员。这样,权限,角色都是可进行灵活配置,扩展性和实用性也更强。

Step1:角色管理-添加角色

一个案例,三个角色,简单说下B端产品的权限设计

一个案例,三个角色,简单说下B端产品的权限设计

在这一步中进行角色的添加并分配权限。

Step2:用户管理-添加用户

一个案例,三个角色,简单说下B端产品的权限设计

一个案例,三个角色,简单说下B端产品的权限设计

在这个步骤中重点是给添加的用户分配角色(即权限)

这样子就将角色,用户,权限分离开,管理也就更加的方便和灵活了。

但是值得注意的是,这三者之间的关联性,对某一个的删除,修改等操作是否会对其他部分产生影响。这个就需要产品经理在后面进行慢慢的梳理了。