一二三应用开发平台使用手册——系统管理-用户组-使用说明-编程知识

概述

在RBAC模型中，资源、角色、用户三个关键元素，构成权限体系。在平台设计和实现的时候，以下几个核心问题思考如下：

角色，单层平铺还是树形结构？
在小型应用中，角色数量有限的情况下，单层平铺简单实用，但在大中型应用中，角色数量在几十个甚至上百个，如果依旧平铺则难以管理和使用。采用树形结构后，可以方便地添加虚拟节点（如角色分类）。

角色还是用户组？
角色的称呼偏技术，对于业务用户而言，称为用户组更合适，即一组用户的集合；
业务意义上的岗位和职务，与传统意义的角色含义基本一致，如部门经理、固定资产接口人。
更改为树形结构后，可以进一步扩展其功能，例如，新建通讯（通知）组，将一部分人放到其下，可以供消息模块（短信、邮件、电话）等使用。
涉及到工作流集成，同样存在一部分流程中的环节处理人员，往往也是某些特定用户集合，并非出于功能权限分配目的，放到用户组角色里更合适。
换个角度想，传统意义上用于功能权限控制的角色，更适合作为用户组的一个分支，因此最终方案将平铺的角色，调整为树形结构的用户组。

是否需要权限继承？
构建成树形结构后，面临一个新的问题，即是否要考虑权限继承问题，例如，给某一角色（用户组）分配的某一权限，则其上级角色和权限自动也自动拥有了其权限，也就是通常意义上的员工有的权限，领导也自动有了，这么做看上去会减轻一定的权限初始化工作以及权限维护工作量，但实际上结果可能是相反的，增加权限维护的复杂性，并且某些业务功能并不适配这种模式。例如，某个底层功能，如班组作业，需要获取当前班组编码或数据，这个功能菜单，让部门经理打开会无法正常显示或使用。
上面这个例子，实际深入思考下，并不是权限继承机制的问题，而是使用这种机制，需要从全局好好规划角色，明确哪些角色是继承关系。班组成员和部门经理是上下级关系，但是从角色继承角度而言，并不应该存在继承关系。存在继承关系的角色，应该是部门管理员-》公司管理员-》集团管理员。
引入权限继承，会增加系统设计、实现、运维的复杂性，因此，不考虑权限继承问题，树形结构仅用于组织角色（用户组）。

用户组规划
按照上述用户组的分类考虑，规划如下：
1.角色：传统意义上的岗位和职务，如部门经理、固定资产接口人，其下可以进一步分公共角色和专用角色，公共角色全局公用，如部门经理、固定资产接口人，每个部门都有该角色；专用角色往往是特定部门特定岗位才有的，如采样人员、巡检人员，可以在用户组下建组织机构虚拟节点，将这些专用角色挂靠在下面，更方便管理（使用角色时，不会显示在公共角色下，从而避免展示的总数量过多而影响选择）。
2.通讯组：预置的消息通知用户集合，可供消息模块（短信、邮件、电话）等使用，在某些业务事件发生时，如发生火灾，系统自动发送应急短信给通讯组用户。
3.流程岗位：工作流流程审批专用，如合同审查人员，会签人员，往往是为某条或某几条流程设置的人员集合，与管理上的岗位和职务没有很强的关联性，也不适合在常规功能权限分配是显示出来。
……

属性

名称：用户组的名字，核心属性。
编码：用户组的编码，应用程序中通过编码进行逻辑处理。
上级：父级标识，形成树形结构的依据。
状态：可以通过状态管理，停用或启用某个用户组。

功能项

常规功能

新增：新增单条数据。
修改：修改单条数据。
删除：删除数据，这里的删除跟上文中的设置状态停用不同，是真正的删除（逻辑删除）。对于确认录入错误的数据，尚未被单据使用，应当彻底清理掉而不是将其状态设置为停用。删除时系统会清理用户组关联的用户数据和权限项数据，避免关联表中残留垃圾对应关系数据。
查询：多条件组合，模糊匹配当前系统中的数据。
查看：查看单条数据。
复制新增：以某条数据为基础，拷贝方式快速创建数据。