权限管理是B端的基础功能的之一,权限功能设计不好,会大大增加项目的实施难度;
为了适应不同客户的组织架构及业务权限管理需求,通常情况下,权限设计包括了“功能权限”和“数据权限”,以下描述的“功能权限”和“数据权限”的理解及设计方法。
1.功能权限
功能权限是指用户登录到系统后能看到的功能模块,功能模块中哪些菜单以及用户是否有新增、删除、编辑、导出数据的功能
1.1基于用户的功能权限设计
针对每个用户指定其访问的模版、功能,系统中每新建一个用户,都需要为用户配置一遍权限,可以想象一下管理员也是工作巨大。
1.2.基于角色的功能权限设计
针对权限管理我们需要引入了“角色”的概念,就是RBAC模型,其思路就是,对所有的系统功能权限不直接授予用户,而是将用户集合和功能权限之间增加一个角色的关联,每个角色对应一组功能权限,给用户分配某一个角色,这个用户就可以拥有这个角色所对应的功能权限,一个可以设置一个角色或多个角色;
1.3.角色继承模型
如果在一个部门内分为稽核主管和稽核员,稽核主管的功能权限只比普通员工的功能多了一个统计功能,这个时候我们引入了“角色继承”模型
2数据权限
2.1组织架构数据权限配置
在项目的业务场景中,信息永远是做不到全部公开透明的,每个用户根据所在组织架构的位置不同,所看到的数据都是不一样的,所以需要引入“数据权限”的概念;
几种数据权限的设置方式:
1.本用户数据(例如门店稽核员只能看到自己所参与稽核的数据)
2.本部门数据(例如门店经理只能看到自己的门店数据权限)
3.全部数据(例如稽核主管及公司高层可以看到全部的数据)
4.本部门及下属部门数据(例如大区经理可以自己下级所有门店的数据)
5.本部门及兄弟部门数据(例如如小区经理可以自己门店及兄弟区域的门店的数据)
另外一个场景,业务有些状态是不能允许特定的用户所查看的,我门引入了“数据状态”的权限逻辑
还有一种业务场景,用户不在组织架构内,例如一个部门下多个角色各自管理不同的供应商,而供应商并不在企业组织架构内,这个时候我门就用角色对应供应商的数据维护方式。
总结
在设计系统时,业务场景的不同,权限的管理方式也不同;总之,必须设计好权限,少走弯路,否则后患无穷!