后台设计的基石：用户权限管理（RBAC）及工作流（workf

　　本文作者主要总结后台设计的基石：RBAC和workflow。enjoy
　　后台产品同学在设计后台时，会发现一般后台的各个功能模块总结起来有两大类型：功能类、流程类。在设计功能或流程前都需要预判不同的使用角色对应不同权限，设计流程前则还得思考最基本的工作流原理。
　　用户权限是设计后台普适的基本管理功能，设计系统时几乎都需要考虑权限问题。后台系统在面对不同部门不同岗位的人员时，如何区分授权？在考虑前端不同身份的用户访问时（如普通用户、普通会员、超级会员），如何自动判断权限？工作流则是设计流程需要具备的基本理论，一个完整的流程会会包含哪些节点动作？节点是否可自主配置？
　　本文主要总结后台设计的基石：RBAC和workflow。
　　RBAC
　　1、什么是RBAC
　　RBAC（RoleBasedAccessControl）基于角色的访问控制。这是从传统的权限模型基础上，改进而来并且相当成熟的权限模型。这里强调三个要素：用户、角色、权限。用户与角色是多对多关系，角色与权限是多对多关系。
　　传统模型中无角色概念，直接为用户赋上权限，一是导致配置权限相当麻烦，二来无法快速为多个用户批量删除权限。用户角色权限多对多的关系，解决了这些问题。
　　关键元素：
　　用户：成功认证并登录系统的操作员（主体：who）
　　权限：访问资源的许可（how）
　　角色：权限的集合体
　　资源：引入这第四个概念，包括系统菜单、页面、按钮等（what）
　　主体（who）如何通过权限（how）访问资源（whatresource）。
　　权限是用来访问资源的，为用户赋予权限，则可访问资源；在权限基础上，将权限打包为一个权限集合角色，如财务经理角色，则为用户赋上财务经理角色，用户可访问财务经理角色下的资源集合。
　　2、RBAC模型解读
　　根据RBAC的复杂度不同，可分为RBAC0，RBAC1，RBAC2，RBAC3。最常用的为RBAC0。
　　（1）RBAC0模型
　　将一个或多个权限挂到角色下，在将一个或多个角色赋予用户，权限与角色的关系，角色与用户的关系，均是多对多的关系。
　　场景。为财务经理岗建立财务经理角色，将对账、付款审批、回款确认等权限配置在财务经理角色下，则公司再更换财务经理人员，只需每次为新来的财务经理配置财务经理角色。
　　为客户经理建立客户经理角色，客户管理、客户查询、抢单等权限配置在客户经理角色下，适应于公司流动性高且占比庞大（多的甚至上千人）的客户经理群体，若某个权限不适宜配置给客户经理，直接在角色中删除即可，无需分别对每个人进行权限删除。
　　（2）RBAC1模型
　　引入继承概念，一个角色可以从另一个角色继承许可权。角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多继承，受限继承关系则进一步要求角色继承关系是一个树结构。
　　场景。适用于角色之间的层次明确，如总经理与副总经理，业务部门如总经理团队经理业务员。也适用于用户分级管理，初级用户只能使用部分功能，中级用户能够使用更多功能。
　　（3）RBAC2模型
　　加入了角色的访问控制。规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
　　包括静态职责分离SSD（StaticSeparationofDuty）和动态职责分离DSD（DynamicDSD（DynamicSeparationofDuty）。
　　互斥角色：同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。案例：在审计活动中，一个角色不能同时被指派给会计角色和审计员角色。
　　基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；一个角色的权限数目受限。案例：如VP类角色不可随意分配给多个用户。
　　先决条件角色：指要想获得较高的权限，要首先拥有低一级的权限。案例：先有副总经理全下，才能有总经理权限。
　　运行时互斥：例如，允许一个用户具有两个角色，但不可同时激活这两个角色。
　　（4）RBAC3模型
　　RBAC1RBAC2的集合体。即支持角色间的继承关系，又支持角色间的责任分离关系。一般无需如此全面负责的模型。
　　3、关于一般角色、数据角色、成员角色
　　角色一般可拆分为一般角色、数据角色、成员角色。
　　一般角色：可见功能菜单页、功能操作按钮、数据字段，均可通过颗粒度较细的权限，去组合成一般角色。
　　数据角色：指可查询的数据范围。同一个一般角色，如查看客户数据，大区总监能看到整个大区的数据，上海分公司经理只能看到上海客户数据。上级组织职能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。
　　成员角色：新建成员即自动赋予的角色，即普通用户均有的常规权限，无需再手动配置。
　　4、常见的常规管理功能
　　（1）用户管理
　　用户按架构新建在对应的组织上。一般挂到机构部门（一级部门二级部门）下。
　　对于公司内部管理系统，管理用户的前提，是需要合理的组织架构，只有支持组织架构的灵活配置，才能进一步支持组织内人员的增删调整。
　　（2）角色管理
　　所有角色的管理功能。新建角色时，可将角色建立在某级机构或机构及以下，代表此角色只能适用此级别或此级别以下级别。
　　（3）菜单管理（有的后台叫栏目管理）
　　支持自主配置菜单一级二级，支持新增菜单、修改菜单、删除菜单，更改菜单（修改菜单名、菜单顺序等），每个菜单对应一个权限。
　　（4）组管理
　　用户所属组，用于配置统一组同一部门用户。有了用户组，在新建角色时，可直接将角色赋予某个组，则进入此组的人员自动获得对应角色。
　　workflow
　　一个业务流程包含多个环节的审批确认关系，按照业务流程，将各个节点串接起来，即时工作流。系统实现各个节点的自动流转，解决手工处理工作流程的低效和失误，提高工作效率的同时，还可通过线上直接流程状况进行实时跟踪，实现业务流程流转的自动化。
　　1、工作流常见的路由方式
　　（1）串行路由
　　按顺序一个步骤接着一个步骤走流程：
　　案例：入职流程，人力专员提交HRBP审批人力总监审批，顺序走完流程。
　　（2）并行路由
　　同时可以执行多个不同的节点：
　　（3）条件路由
　　满足条件后导向一个节点，不满足条件的导向另外一个节点。
　　案例：流程提交满足XX模式，则走A节点，不满足则走B节点。
　　（4）分支路由
　　分支路由平行分支出多条线路，多条线路之间是并行的关系。
　　案例：付款申请，提交后判断，对公付款走对公审批，对私付款走对私审批。
　　（5）合并路由
　　并行的多路分支集结到一个点的路由方式，前序分支节点全部都经过处理，最终才到汇合节点处理
　　案例：多个申请项目，同一天提交到终审岗审批。
　　（6）循环路由
　　下一步返回到原来的任意一个步骤，这之间形成的回路就是一个循环路由。
　　案例：发起的流程，条到某岗位后，再流转到自己确认，再提交。
　　（7）自由跳转
　　这种是很特殊的路由方式，在流程实际运行时跳出原来定义的线路，自由跳转到任意的步骤。
　　案例：满足某个条件，则自动跳过某个岗位，无需此岗位再审批。
　　2、常见节点动作
　　提交：每个节点的人将流程提交至下手岗位。
　　回退：可退回到某个节点继续流转，退回到发起岗，或退回到前手岗。
　　撤回：节点执行完后、下一节点执行前，可以收回进行修改然后再提交。
　　取消撤销：流程发起人执行取消流程。
　　中止：流程提前结束，当前节点之后的其它节点不再执行。
　　审批：表单中的某个字段，用于填写审批意见。
　　会签：通常用于审批后给相关的人签字确认，需要签字确认。
　　知会：指定的人知道有这个流程这么回事，并能查看流程，不需要签字确认。
　　加签：审批时，可以征求另一人或多人的意见，然后再回到原审批人。
　　跳签：跳过接下来的一个或连续的多个节点，直接到指定的节点执行。
　　3、上报关系
　　每个节点提交后，下一节点将有谁审批？一般会为对应岗位的人员配置对应的节点。但若涉及到分公司或分地区审批，则需要设计上报关系。
　　上报关系支持灵活配置前一岗与后一岗的对应关系。如北京分公司的审批，提交到财务审核时，只能提交到北京财务部。合作公司的审批，只能提交到综合财务部。此时就需要提前配置上报关系，北京分公司北京财务部；合作公司综合财务部。各个部门均可配置对应上报关系，包括财务，人力，业务等。
　　最后，为用户配置某个财务部的权限，则其仅可接收特定对应的上报关系的审批申请。如权限为综合财务部用户，仅可收到合作公司提交的申请单。
　　BRAC和流程节点，在设计过程中，还需考虑其灵活性。
　　如操作员入职流程完毕后，自动赋予其岗位对应角色权限，当然这可通过对用户组分配角色实现。当操作员调岗时，根据调岗的跨度大小，自主确定是否更改权限或删除权限。流程节点在系统中可根据对应业务，后台预备支撑性较强的节点变量，支持前台配置，由管理员自主根据对应业务流程，配置相应的流转节点。