工作流审批节点按部门设置审批角色的方法与流程

本发明涉及一种erp等管理软件系统的工作流中审批节点审批角色的设置和管理方法，特别是涉及一种工作流审批节点按部门设置审批角色的方法。

背景技术

基于角色的访问控制（rbac）是近年来研究最多、思想最成熟的一种数据库权限管理机制，它被认为是替代传统的强制访问控制（mac）和自主访问控制（dac）的理想候选。传统的自主访问控制的灵活性高但是安全性低，强制访问控制安全性高但是限制太强；基于角色的访问控制两者兼具，不仅易于管理而且降低了复杂性、成本和发生错误的概率，因而近年来得到了极大的发展。基于角色的访问控制（rbac）的基本思想是根据企业组织视图中不同的职能岗位划分不同的角色，将数据库资源的访问权限封装在角色中，用户通过被赋予不同的角色来间接访问数据库资源。

在大型应用系统中往往都建有大量的表和视图，这使得对数据库资源的管理和授权变得十分复杂。由用户直接管理数据库资源的存取和权限的收授是十分困难的，它需要用户对数据库结构的了解非常透彻，并且熟悉sql语言的使用，而且一旦应用系统结构或安全需求有所变动，都要进行大量复杂而繁琐的授权变动，非常容易出现一些意想不到的授权失误而引起的安全漏洞。因此，为大型应用系统设计一种简单、高效的权限管理方法已成为系统和系统用户的普遍需求。

基于角色的权限控制机制能够对系统的访问权限进行简单、高效的管理，极大地降低了系统权限管理的负担和代价，而且使得系统权限管理更加符合应用系统的业务管理规范。

然而，传统基于角色的用户权限管理和工作流控制方法均采用“角色对用户一对多”的关联机制，其“角色”为组/类性质，即一个角色可以同时对应/关联多个用户，角色类似于岗位/职位/工种等概念，这种关联机制下对用户权限的授权基本分为以下三种形式：1、如图1所示，直接对用户授权，缺点是工作量大、操作频繁且麻烦；审批流程中审批节点的审批操作主体是用户，工作流审批节点直接选择员工/用户作为审批主体，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。

即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。

2、如图2所示，对角色（类/组/岗位/工种性质）进行授权（一个角色可以关联多个用户），用户通过角色获得权限，审批操作主体是组/类性质角色；3、如图3所示，以上两种方式结合。

以上的表述中，2、3均需要对类/组性质的角色进行授权，而通过类/组/岗位/工种性质的角色进行授权和工作流控制的方式有以下缺点：1、用户权限变化时的操作难：在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化时，角色关联的某个员工权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。

员工/用户的审批权限发生变化时，要么员工/用户脱离角色，工作流审批节点直接选择员工/用户作为审批主体，要么新增角色来满足审批流程的要求。第一种方式，当发生员工变动（如调岗、离职等），该员工涉及到的所有流程必须要作相应调整，特别是对于公司管理人员，其涉及到的审批流程多，流程调整的工作量大、繁杂，容易出错或遗漏，影响企业的正常运营，甚至造成不可预估的损失。即使只是员工审批权限发生变化，也需要对该员工涉及到的流程作出相应调整，也存在以上类似问题。第二种方式，新增角色便涉及到角色的新建、关联、授权工作，特别在角色多、角色关联的用户也多的情况下，角色具体关联了哪些用户是很难记住的。

2、要长期记住角色包含的具体权限难：若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，相近角色的权限也很容易混淆；若要关联新的用户，无法准确判断应当如何选择关联。

3、因为用户权限变化，则会造成角色创建越来越多（若不创建新角色，则会大幅增加直接对用户的授权），更难分清各角色权限的具体差别。

4、调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。

现有的工作流的审批节点设置时，通常是选择对应的人，对于人员较多的公司来说，从中选择某个人员进行审批很繁琐。此外，在人员职责调整时，又需要选择新的负责人员，容易出错。

技术实现要素：

本发明的目的在于克服现有技术的不足，提供一种工作流审批节点按部门设置审批角色的方法，在设置审批角色时只需选择相应的部门即可，操作便捷。

本发明的目的是通过以下技术方案来实现的：工作流审批节点按部门设置审批角色的方法，包括：创建系统组织结构中所包含的部门及角色；设置各部门的部门主管角色；对工作流的审批节点进行设置时显示候选部门；从所述候选部门中选择一个或多个部门，则该部门的部门主管角色担任该审批节点的审批角色。

优选的，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

优选的，所述工作流的生成方法包括：构建用户-角色-权限的三层机构模型，其中：角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；用户层：用户通过关联的角色确定工作流中的审批任务，并以关联角色的权限进行审批操作；利用三层结构模型对工作流进行控制，一个审批流程中包括一个开始节点、至少一个审批节点、一个结束节点，其中：开始节点：审批流程开始；审批节点：对相应的审批角色进行审批权限授权（或设置）；结束节点：审批流程结束；用户根据其关联的角色确定所需处理的审批任务，并根据关联的角色的权限进行审批操作。

优选的，有工作流发起权限的角色才能作为提交角色发起/申请/提交工作流。

优选的，所述角色归属于部门，根据角色的工作内容对角色进行授权。

优选的，所述角色的名称在该部门下唯一，该角色的编号在系统中唯一。

优选的，所述用户跨部门调岗时，取消用户与原部门内的角色的关联，将用户与新部门内的角色进行关联。

优选的，所述用户通过其与角色的关联确定权限，一个员工对应一个用户账号，一个用户账号对应一个员工。

优选的，所述候选部门的显示形式包括列表、组织结构树形图、组织结构架构图。

工作流审批节点按部门设置审批角色的方法，包括：创建系统组织结构中所包含的部门及角色；设置各部门的部门主管角色；选择（或设置）以按部门方式进行审批角色的设置；对工作流的审批节点进行设置时显示候选部门；从所述候选部门中选择一个或多个部门，则该部门的部门主管角色担任该审批节点的审批角色。

本发明的有益效果是：（1）系统工作流设置人员在设置审批角色时只需选择相应的部门，则该部门的部门主管角色为审批角色，即使该部门的部门主管角色发生变化，则该部门当前的部门主管角色为审批角色，也不需要重新设置审批角色，操作便捷、不容易出错。

举例：公司的员工请假时都需要行政部门审批，本发明中只需要在审批节点中选择行政部门，行政部的部门主管角色则为审批角色，该部门主管角色对应的职员通过该部门主管角色获取审批任务并根据该部门主管角色的相关权限进行审批，无需选择具体某一职员进行审批设置，操作简单便捷；当行政部的部门主管角色由角色a变为角色b时，则由角色b对应的职员进行审批，不需要重新进行审批角色的设置。

（2）工作流中审批操作的主体是角色，而且这个角色是独立的个体而不是传统组/类性质的角色，即使发生员工/用户变动（如调岗、离职等），只需将员工重新关联到新角色，或者是员工审批权限发生变化，针对性调整该角色审批权限即可，无需重新设置/调整流程，设置方便，不会出错或遗漏，不会影响企业的正常运营，极大提高了工作流的可靠性。以岗位号性质的角色为审批环节节点的审批授权主体，用户通过角色确定其有哪些审批任务，用户通过关联角色的权限进行审批操作即可；理解清晰简单，每个岗位号/工位号性质的角色是工作主体的最小单位，针对每个角色对审批的不同需求，本申请均能够很好满足。

（3）本申请角色对用户是一对一的关系，同一时段一个角色只能关联唯一的用户，这样做的好处是，只要将用户关联到角色即可获得权限（即用户获得其关联的角色的权限），而且角色的权限变更比传统机制中的用户权限变更要少得多。独立体性质（岗位号/工位号性质）的角色数量变化小，虽然员工流动大，但岗位号/工位号的变化小（甚至在一定时段内是没有变化的，即角色没有变化），这样将极大简化用户的权限管理，减少系统的开销。

（4）动态管理、入职调岗等的操作简单方便，效率高，可靠性高：入职/离职/调岗在审批流程中的应用简单，工作流程的审批的操作主体是角色，当员工/用户发生变化时不用重新设置审批流程（用户只需取消或关联角色即可：不再任职该岗位号/工位号的角色的用户就取消该角色关联，接手任职该岗位号/工位号的角色的用户关联该岗位号的角色，则关联该角色的用户自动就获得了该角色在审批工作流中的相关任务和权限，无需对审批工作流进行重新设置或对工作流中的角色进行重新授权，极大地提高了流程设置的效率、安全性和可靠性。

举例：因张三用户离职或调岗等原因，张三不再做“采购员3”这个角色的工作，则张三取消了与该角色的关联；另外李四接手做“采购员3”这个角色的工作，则将李四关联该角色，则李四自动获得了审批流程中“采购员3”这个角色的审批任务和审批权限。

（5）传统的权限管理机制将角色定义为组、工种、类等性质，角色对用户是一对多的关系，在实际的系统使用过程中，经常因为在运营过程中需要对用户的权限进行调整，比如：在处理员工权限变化的时候，角色关联的某个员工的权限发生变化，我们不能因该个别员工权限的变化而改变整个角色的权限，因为该角色还关联了其他权限未变的员工。因此为了应对该种情况，要么创建新角色来满足该权限发生变化的员工，要么对该员工根据权限需求直接授权（脱离角色）。以上两种处理方式，在角色权限较多的情况下对角色授权不仅所需时间长，而且容易犯错，使用方操作起来繁琐又麻烦，也容易出错导致对系统使用方的损失。

但在本申请的方法下，因为角色是一个独立的个体，则可以选择改变角色权限即可达到目的。本申请的方法，虽然看起来在系统初始化时会增加工作量，但可以通过复制等方法，使其创建角色或授权的效率高于传统以组为性质的角色，因为不用考虑性质为组的角色在满足关联用户时的共通性，本申请方案会让权限设置清晰，明了；尤其是在系统使用一段时间后（用户/角色权限动态变化），该申请方案能为系统使用方大幅度提高系统使用中的权限管理效率，使动态授权更简单，更方便，更清晰、明了，提高权限设置的效率和可靠性。

（6）传统以组为性质的角色授权方法容易出错，本申请方法大幅降低了授权出错的几率，因为本申请方法只需考虑作为独立个体的角色，而不用考虑传统方法下关联该组性质角色的多个用户有哪些共通性。即使授权出错也只影响关联到该角色的那一个用户，而传统以组性质的角色则会影响关联到该角色的所有用户。即使出现权限授权错误，本申请的修正方法简单、时间短，而传统以组性质的角色在修正错误时需要考虑关联到该角色的所有用户的权限共通性，在功能点多的情况下不仅修改麻烦、复杂，非常容易出错，且很多情况下只能新创建角色才能解决。

（7）在传统以组为性质的角色授权方法下，若角色的权限功能点比较多，时间一长，很难记住角色的具体权限，更难记住权限相近的角色之间的权限差别，若要关联新的用户，无法准确判断应当如何选择关联。本申请方法的角色本身就具有岗位号/工位号的性质，选择一目了然。

（8）调岗时，若要将被调岗用户的很多个权限分配给另外几个用户承担，则处理时必须将被调岗用户的这些权限区分开来，分别再创建角色来关联另外几个用户，这样的操作不仅复杂耗时，而且还很容易发生错误。

本申请方法则为：被调岗用户关联了几个角色，在调岗时，首先取消用户与原部门内的角色的关联（被取消的这几个角色可以被重新关联给其他用户），然后将用户与新部门内的角色进行关联即可。操作简单，不会出错。

（9）角色归属于部门，则该角色的部门不能被更换，角色为什么不能更换部门：理由1：因为本申请的角色性质等同于一个工位号/岗位号，不同的工位号/岗位号的工作内容/权限是不一样的，如销售部门下的销售员1角色和技术部门的开发人员1角色是完全不同的两个工位号/岗位号，其权限是不同的；理由2：若将销售员1角色的所属部门（销售部）更换为技术部，其销售人员1这个角色的权限不变，则在技术部存在拥有销售部权限的一个角色，这样会导致管理混乱及安全漏洞。

附图说明

图1为背景技术中系统直接对用户进行授权的方式示意图；

图2为背景技术中系统对组/类性质角色进行授权的方式示意图；

图3为背景技术中系统对用户直接授权和对组/类性质角色授权相结合的方式示意图；

图4为本发明中工作流审批节点按部门设置审批角色的方法的一种流程图；

图5为本发明中工作流的示意图；

图6为本发明中工作流审批节点按部门设置审批角色的方法的又一种流程图。

具体实施方式

下面结合附图进一步详细描述本发明的技术方案，但本发明的保护范围不局限于以下所述。

【实施例1】如图4所示，工作流审批节点按部门设置审批角色的方法，包括：创建系统组织结构中所包含的部门及角色。

角色的定义：角色不具有组/类/类别/岗位/职位/工种等性质，而是一个非集合的性质，角色具有唯一性，角色是独立存在的独立个体；在企事业单位应用中相当于岗位号（此处的岗位号非岗位，一个岗位同时可能有多个员工，而同一时段一个岗位号只能对应一个员工）。

举例：某个公司系统中可创建如下角色：总经理、副总经理1、副总经理2、北京销售一部经理、北京销售二部经理、北京销售三部经理、上海销售工程师1、上海销售工程师2、上海销售工程师3、上海销售工程师4、上海销售工程师5……用户与角色的关联关系：若该公司员工张三任职该公司副总经理2，同时任职北京销售一部经理，则张三需要关联的角色为副总经理2和北京销售一部经理，张三拥有了这两个角色的权限。

传统角色的概念是组/类/岗位/职位/工种性质，一个角色能够对应多个用户。而本申请“角色”的概念相当于岗位号/工位号，也类同于影视剧中的角色：一个角色在同一时段（童年、少年、中年……）只能由一个演员来饰演，而一个演员可能会分饰多角。

每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色。

所述角色归属于部门，根据角色的工作内容对角色进行授权；所述角色由名称和编号构成，该角色的名称在该部门下唯一，该角色的编号在系统中唯一。

所述用户跨部门调岗时，取消用户与原部门内的角色的关联，将用户与新部门内的角色进行关联。在创建角色之后，可以在创建用户的过程中关联角色，也可以在用户创建完成后随时进行关联。用户关联角色后可以随时解除与角色的关联关系，也可以随时建立与其他角色的关联关系。

所述用户通过其与角色的关联确定权限，一个员工对应一个用户账号，一个用户账号对应一个员工。

设置各部门的部门主管角色。

对工作流的审批节点进行设置时显示候选部门。所述候选部门的显示形式包括列表、组织结构树形图、组织结构架构图。

如图5所示，所述工作流的生成方法包括：构建用户-角色-权限的三层机构模型，其中：角色层：工作流中流程审批的操作主体为角色，每个角色是独立的个体，而非组/类，同一时段一个角色只能关联唯一的用户，而一个用户关联一个或多个角色；权限层：由工作流执行中所需要使用的权限构成，权限直接授权给角色；用户层：用户通过关联的角色确定工作流中的审批任务，并以关联角色的权限进行审批操作；利用三层结构模型对工作流进行控制，一个审批流程中包括一个开始节点、至少一个审批节点、一个结束节点，其中：开始节点：发起/申请/提交工作流作为开始节点，或者由第一个审批节点作为开始节点；审批节点：对相应的审批角色进行审批权限授权（或设置）；结束节点：审批流程流转到此节点时该审批流程结束，该结束节点不进行审批操作；或者以最后一个审批节点作为结束节点，该结束节点需要进行审批操作；用户根据其关联的角色确定所需处理的审批任务，并根据关联的角色的权限进行审批操作。

从所述候选部门列表中选择一个或多个部门，则该部门的部门主管角色担任该审批节点的审批角色。

【实施例2】本实施例以一个请假工作流的审批角色设置为例对本发明进行说明。

一个公司包括行政部和销售部，销售部下面有角色a、角色b和角色c，行政部下面有角色d、角色e和角色f，其中，角色a为销售部的部门主管角色，角色d为行政部的部门主管角色。公司所有请假都需要行政部进行审批，请假工作流的审批节点的设置具体包括以下步骤：创建销售部和行政部，销售部下面有角色a、角色b和角色c，行政部下面有角色d、角色e和角色f。

将角色a设置为销售部的部门主管角色，角色d设置为行政部的部门主管角色。

在请假工作流中选择一个审批节点，此时显示出候选部门，候选部门包括销售部和行政部。

选择行政部，此时，行政部的部门主管角色担任该节点的审批者，即角色d担任该审批节点的审批角色。

假设行政部中由于工作分工调整，将角色e作为行政部新的部门主管角色，则此时角色e为该审批节点的审批角色，不需要重新再设置审批角色。

假设角色d关联的用户由张三变为李四，同样不需要重新设置审批角色。

【实施例3】如图6所示，工作流审批节点按部门设置审批角色的方法，包括：创建系统组织结构中所包含的部门及角色；设置各部门的部门主管角色；选择（或设置）以按部门方式进行审批角色的设置；对工作流的审批节点进行设置时显示候选部门；从所述候选部门中选择一个或多个部门，则该部门的部门主管角色担任该审批节点的审批角色。

以上所述仅是本发明的优选实施方式，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。