OA19306A - Workflow control method and system based on one-to-one correspondence between roles and users. - Google Patents

Abstract

Disclosed in the present invention are a workflow control method and a system based on one-toone correspondence between roles and users. The workflow control method includes: building a user-role-authority with three-dimensional structural model, each role being an independent individual, one role being only allowed to be associated with a single user in the same time period, and one or more roles; controlling the workflow by using the three-layer structural model, selecting an approval role, and authorizing the approval role; The determination of the use of the product by the user. The subject of the approval operation in the workflow of the present invention is the roles: even if there is an employee / user change, or in the approval authority of an employee, it is only necessary to re-associate an employee with the roles or specifically adjust the approval authority of the roles: and the flow is not required to be reset / adjusted, so that setting is convenient; mistakes or omissions hardly occur: normal operation of an enterprise would not be affected; and the reliability of the workflow is greatly improved, normal operation of an enterprise would not be affected; and the reliability of the workflow is greatly improved, normal operation of an enterprise would not be affected; and the reliability of the workflow is greatly improved.

Description

WORKFLOW CONTROL METHOD AND SYSTEM BASED ON ONE-TO-ONE CORRESPONDENCE BETWEEN ROLES AND USERS

BACKGROUND

Technical Field

[0001] The présent invention relates to a woïkflow control method in a management software System such as an ERP system, and more particularly to a workflow control method and system based on a one-to-one correspondence between rôles and users.

Related Art

[0002] P.ole-based access control (RBAC) is one of the most researched and mature 10 management mechanisms for data in recent years. It is considered to be an idéal candidate to replace conventional mandatory access control (MAC) and discretionary access control (DAC). Conventional discretionary access control has high flexibility but low security. Mandatory access control is highly secure but too restrictive. Role-based access control combines both above, and not only is easy to manage, but also reduces complexity, costs, 15 and probability of errors. Therefore, it has been greatly developed in recent years. The basic idea of role-based access control (RBAC) is to divide different rôles according to different functional positions in the enterprise organization view, encapsulate the access permission of database resources in rôles, and allow users to indirectly access database resources by assigning different rôles to the users.

[0003] A large number of tables and views are often built in large application

Systems which makes the management and permissions of database resources very complicated. It is very difficult for the user to directly manage the access and permissions of the database resources. It requires the user to hâve a very thorough understanding of the database structure and to be familiar with the use of the SQL language. Once the 25 application system structure or security requirements hâve changed, a large number of complex and cumbersome permission changes are required, and the security vulnerabilities caused by unexpected authorization errors are very likely to occur. Therefore, designing a simple and efficient permission management method for large-scale application Systems has become a common requirement for Systems and system users.

[0004] The role-based permission control mechanism can manage the access permissions ofthe system simply and efficiently, which greatly reduces the burden and cost of the system permission management, and makes the system permission management more compilant with the business management spécifications of the application system.

[0005] However, the conventional role-based permission management and workflow contrcd methods for a user adopt the role-to user one-to-many relation mechanism, where the rôle is a group or class in nature. That is, one rôle can simultaneously correspond to or be related to multiple users, and the rôle is similar to a post or a position or a type of work or other concepts. The permission granted to a user under this relation mechanism is basically divided into the following three forms:

[0006] 1. As shown in FIG. 1, the permission is directly granted to the user, where the disadvantage is that the workload is large and the operation is frequent and cumbersome. In the approval process, the approval operation subject of the approval node is the user, and at the workflow approval node, the employée or user is selected directly as an approval subject. When changes on an employée hâve occurred (such as transfer or résignation), ail processes related to the employée shall be adjusted accordingly. Especially, for changes on the employée in a management position of an enterprise, many approval processes are involved. As the adjustment of the processes involves large workloads, and is cumbersome, errors or omissions are likely to occur, affecting the normal operation of the enterprise and even causing unpredictable losses.

[0007] Even if the change only occurs in the approval permissions of the employée, it is still necessary to correspondingly adjust the processes related to the employée, and similar problems described above still occur.

[0008] 2. As shown in FIG. 2, the rôle (of a class/group/post/work type nature) is authorized (one rôle may be related to multiple users), the user obtains permissions through its rôle, and the approval operation subject is the rôle of a group or class nature.

[0009] 3. As shown in FIG. 3, the above two methods are combined.

[0010] In the above descriptions, as both 2 and 3 need to authorize the rôle of a class or group nature. The way of authorization and workflow control through the rôle of a class/group/post/work type nature has the following disadvantages:

[0011] 1. Operations are difficult when the user's permission has changed: In the actual process of using a System, the user's permissions often need to be adjusted during the operation process. For example, in processing of the change of an employee's permissions, when the permissions of an employée related to the rôle hâve changed, it is improper to change the permissions of the entire rôle due to the change of the permissions of the individual employée, because the rôle is also related to other employées whose permissions remain unchanged. In response to this situation, either a new rôle is created to fit the employée whose permissions hâve changed, or permissions are directly granted to the employée (disengaged from the rôle) based on permission requirements. The above two processing methods not only take a long time but also cause mistakes easily for the rôle authorization in the case of a large number of rôle permissions. It is cumbersome for a user to operate, and errors occur easily, resulting in loss to the System user.

[0012] When the approval permissions of the employée or user hâve changed, either the employée or the user is disengaged from the rôle, and at the workflow approval node, the employée or the user is directly selected as an approval subject, or a new rôle is added to meet the requirements of the approval process. In the first way, when changes on an employée hâve occurred (such as transfer or résignation), ail processes related to the employée shall be adjusted accordingly. Especially, for changes on an employée in a management position of an enterprise, many approval processes are involved. As the adjustment of the processes involves large workloads, errors or omissions are likely to occur, affecting the normal operation of the enterprise and even causing unpredictable losses. Even if the change only occurs in the approval permissions of the employée, it is still necessary to correspondingly adjust the processes related to the employée, and similar problems described above still occur. In the second way, adding a rôle involves création, relation, and authorization of the rôle. Especially when there are many rôles and many users related to the rôles, it is difficult to remember which users are related to the rôle.

[0013] 2. It is difficult to remember the spécifie permissions contained in a rôle for a long time: If the rôle has many permission function points, over time, it is difficult to remember the spécifie permissions of the rôle, and it is even harder to remember the différences of permissions between rôles with similar permissions. The permissions of similar rôles are also easily confusable. If a new user needs to be related, it is impracticable to accurately détermine how to select a relation.

[0014] 3. Because user permissions change, it results in more rôles created (if new rôles are not created, it greatly increases direct authorization to the user), and it is more difficult to distinguish spécifie différences of the permissions between the rôles.

[0015] 4. When a user is transferred from a post, if many permissions of the transferred user need to be assigned to other users, separating the permissions of the transferred user and creating rôles to relate to the other users are necessary. Such operations are not only complicated and time-consuming, but also prone to errors.

SUMMARY

Technical Problems

[0016] The object of the présent invention is to overcome the deficiencies of the prior art, and provide a workflow control method and system based on a one-to-one correspondence between rôles and users. One rôle can only be related to a unique user during the same period, thus greatly improving the efficiency of the permission management of a system in use, making the dynamic authorization simpler, more convenient, clearer, and more explicit, and improving the efficiency and reliability of the permission setting. The subject of the approval operation in the workflow is the rôle. When an employée or a user has changed, it only needs to re-relate the user to a rôle or adjust the role's permissions accordingly. There is no need to reset the process, and the setting is convenient.

Solutions to Problems

Technical Solutions

[0017] The object of the présent invention is achieved by the following technical solutions. A workflow control method based on a one-to-one correspondence between rôles and users includes the following steps:

[0018] SI: building a three-layer structure model of user-role-permission that includes:

[0019] a rôle layer, wherein an operation subject of process approval in a workflow is a rôle, each rôle is an independent individual rather than a group or class, one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles;

[0020] a permission layer including a permission required to be used in the execution of the workflow, wherein the permission is directly granted to a rôle, and

[0021] a user layer, wherein a user détermines an approval task in the workflow through a related rôle, and performs an approval operation with the permission of the related rôle;

[0022] S2: using the three-layer structure model to control the workflow, wherein one approval process includes:

[0023] one start node initiating or requesting or submitting the workflow;

[0024] at least one approval node selecting an approval rôle and authorizing the approval rôle; and

[0025] one end node, to which the approval process cornes and then is ended;

[0026] S3: determining, according to a user's related rôle, an approval task to be processed, and performing an approval operation with the permission of the related rôle.

[0027] When a workflow is initiated or requested or submitted at the start node, a start rôle initiâtes or requests or submits the workflow, where only a rôle having the permission to start a workflow can initiate or request or submit the workflow as the start rôle.

[0028] When a workflow is initiated or requested or submitted at the start node, a system détermines an approval process according to a form submitted by the start rôle.

[0029] When a workflow is initiated or requested or submitted at the start node, one or more approval processes are designed for a form that requires a workflow, but one rôle can only select one approval process under the form.

[0030] One or more approval rôles are selected at the approval node, one rôle can exist at different approval nodes in one approval process, and the approval rôle may own different (or same) permissions for viewing and modifying a form field at different approval nodes. Exemplary advantages: A rôle is a Chengdu sales manager 3. In a contract approval workflow, the rôle exists at both approval nodes of Chengdu sales contract and Shanghai sales contract. At the approval node of the Chengdu sales contract, the rôle can view a customer name, a contact person, contact information, a product quantity, a unit price of products. a contract amount and other fields of the contract at the time of approval and may modify the unit price of products and the contract amount. However, at the approval node of the Shanghai sales contract, the rôle cannot view the content of sensitive fields such as the customer name, contact person, and contact information, and the like, and cannot make any modifications (alternative!y, the rôle may be set to hâve the view permission but no modification permission).

[0031] One or more approval rôles are selected at the approval node, an approval role's permission is set at the approval node, and the permission can be independently set for each approval rôle of each approval node (the permission of each approval rôle at an approval node can be set to be the same). For example, two approval rôles, namely, a rôle A and a rôle B, are set at an approval node in the approval process of a contract form. Rôle A may be allowed to view a contract amount field in the contract form and the value of the field, and view a customer address field in the contract form and the value of the field. Rôle B is not allowed to view the contract amount field in the contract form, or is allowed to view the contract amount field but not allowed to view the value of the field. The value not allowed to be viewed may be shown as other symbols such as *. Rôle B can view the customer address field in the contract form and the value of the field.

[0032] Step SI includes the following sub-steps:

[0033] S101 : creating a rôle, wherein each rôle is an independent individual rather than a group or class;

[0034] S102: authorizing rôles created in step S101 respectively; and

[0035] S103: relating a user to a rôle, wherein one rôle can only be related to a unique user during the same period, and one user can be related to one or more rôles.

[0036] Step S101 is preceded, but step S102 and step S103 hâve no sequential relationship.

[0037] Said rôle belongs to a certain department, said rôle is unique under the department, and said rôle is authorized according to work content of said rôle.

[0038] The workflow control method based on a one-to-one correspondence between rôles and users further includes a step of managing cross-department transfer of a user, specifically including:

[0039] (1) cancelling the user's relation to the rôle in the original department; and

[0040] (2) relating the user to a rôle in a new department.

[0041] A workflow control system based on a one-to-one correspondence between rôles and users includes a model building unit, a workflow control unit, and an approval operation unit, wherein,

[0042] Said model building unit is used to build a three-layer structure model of user-role-permission that includes:

[0043] a rôle layer, wherein an operation subject of process approval in a workflow is a rôle, each rôle is an independent individual rather than a group or class, one rôle can only be related to a unique user, and one user is related to one or more rôles;

[0044] a permission layer including a permission required to be used in the execution of the workflow, wherein the permission is directly granted to a rôle; and

[0045] a user layer, wherein a user détermines an approval task in the workflow through a related rôle, and performs an approval operation with the permission of the related rôle.

[0046] Said workflow control unit Controls the workflow by using the three-layer structure model, wherein one approval process includes:

[0047] one start node initiating or requesting or submitting the workflow;

[0048] at least one approval node selecting an approval rôle and authorizing the approval rôle; and

[0049] one end node, to which the approval process cornes and then is ended.

[0050] In said approval operation unit, the user détermines, according to the rôle related to the user, the approval task to be processed, and performs the approval operation with the permission of the related rôle.

[0051] Said model building unit includes:

[0052] a rôle création submodule used to perform rôle layout according to posts and create system rôles, wherein each rôle is an independent individual rather than a group or class;

[0053] a rôle authorization submodule used to authorize the rôle according to work content of the rôle;

[0054] a user-role relation submodule used to relate the user to the rôle, ensuring that one rôle can be related to a unique user during the same period, and one user is related to one or more rôles.

[0055] Said system rôle is composed of: a post name + a post number.

Bénéficiai Effects of the Invention

Bénéficiai Effects

[0056] (1) The subject of the approval operation in the workflow is the rôle that is an independent individual rather than a conventional rôle of a group or class nature. Even if changes on an employée or a user hâve occurred (such as transfer or résignation), or if the approval permissions of the employée hâve changed, it is only necessary to relate the employée to a new rôle, or adjust the approval permissions of the existing rôle accordingly, but not necessary to reset or adjust processes. As setting is convenient and no errors or omissions will occur, the normal operation of the enterprise will not be affected, and the reliability of the workflow is greatly improved. The rôle is taken as the subject of the approval authorÎ2:ation according to the nature of the post number at the approval node. The user détermines which approval tasks are available according to the rôle. The user only needs to perform approval operations based on the permission of the related rôle. It is clear and simple to understand. Each rôle that is a post number or a work station number in nature is a minimum unit of the subject of work. The présent application can well satisfy different approval requirements of each rôle.

[0057] (2) In the présent application, the rôle is one-to-one related to the user. One rôle can be related to a unique user during the same period. The advantage of this is that whenever a user is created, no operation of assigning permissions is required any more, as long as the user is related to the rôle, and changes in the permissions of the rôle are much fewer than the changes in the permissions of the user in a conventional mechanism. Few changes occur in the quantity of rôles that are each an independent individual in nature (a post number or a work station number in nature). Although there is large employée turnover, few changes occur in the post number/work station number (even if there is no change in a certain period, that is, the rôle does not change). This greatly simplifies user permission management and reduces system overheads.

[0058] (3) The operations such as dynamic management, recruitment, and transfer are simple, convenient, efficient and highly reliable. The application of recruitment or departure or transfer in the approval process is simple. The subject of the approval operation of the workflow is the rôle. When an employée or a user has changed, the approval process does not need to be reset (it only needs to cancel the relation or relate the user to the rôle). For the user who is no longer in the rôle of the post number or work station number, the relation to the rôle is cancelled, and the user who takes over the post number or work station number is related to the rôle of the post number. Therefore, the user related to the rôle automatically obtains related tasks and permissions of the rôle in the approval workflow, without resetting the approval workflow or re-authorizing the rôle in the workflow, thus greatly improving the efficiency, security, and reliability of the process setting.

[0059] For example, because Zhang San user is transferred or départs from a post, Zhang San no longer works as a rôle of purchaser 3, and Zhang San cancels the relation to the rôle. Meanwhile, Li Si takes over the work in the rôle of purchaser 3, and then Li Si is related to the rôle, so Li Si automatically obtains the approval tasks and the approval permissions ofthe rôle of purchaser 3 in the approval process.

[0060] (4) The conventional permission management mechanism defines the nature of a group, a work type, a class or the like as the rôle. The rôle is in a one-to-many relation to the user. In the actual process of using a system, the user's permissions often need to be adjusted during the operation process. For example, in processing of the change of an employee's permissions, when the permissions of an employée related to the rôle hâve changed, it is improper to change the permissions of the entire rôle due to the change of the permissions of the individual employée, because the rôle is also related to other employées whose permissions remain unchanged. In order to respond to this situation, either a new rôle is created to fit the employée whose permissions hâve changed, or permissions are directly granted to the employée (disengaged from the rôle) based on permission requirements. The above two processing methods not only take a long time but also cause mistakes easily for the rôle authorization in the case of a large number of the rôle permissions. It is cumbersome for a user to operate, and errors occur easily, resulting in loss to the system useir.

[0061] However, under the method of the présent application, as the rôle is an independent individual, the object can be achieved by changing the permissions of the rôle. Although the method in the présent application seems to increase a workload during system initialization, by means of copying or the like, the rôle can be created or authorized more efficiently than the conventional rôles of a group nature. As it does not need to consider the commonality ofthe rôles of a group nature when satisfying the related users, the solutions in the présent application makes the permission setting clear and explicit. Especially after the system has been used for a period of time (after the permissions of the user/role hâve changed dynamically), the solutions in the présent application can significantly improve the efficiency of the permissions for the system user during the use of the system, make the dynamic authorization simpler, more convenient, clearer and more explicit, and improve the efficiency and reliability of the setting.

[0062] (5) The conventional group-based rôle authorization method is prone to errors. The method provided in the présent application significantly reduces the probability of authorization errors, because the method of the présent application only needs to consider the rôle as an independent individual, without considering the commonality of multiple users related to the rôle of the group nature under the conventional method. Even if the authorization errors occur, only the user related to the rôle is affected. However, in the case of the conventional rôle of the group nature, ail users related to the rôle are affected. Even if the authorization errors occur, the correction method in the présent application is simple and takes a short time, while in the case of the conventional rôle of a group nature, the commonality of the permissions of ail users related to the rôle needs to be considered during the error correction. The modification is cumbersome, complex, and error-prone when the rôle has many function points, and in many cases, the problem cannot be solved unless a new rôle is created.

[0063] (6) In the conventional group-based rôle authorization method, if the rôle has many permission function points, over time, it is difficult to remember spécifie permissions of the rôle, and it is even more difficult to remember the différences of permissions between rôles that hâve similar permissions. If a new user needs to be related, it cannot be accurately determined how to select a relation. In the method in the présent application, the rôle itself has a nature of a post number or work station number, and the sélection can be made easily.

[0064] (7) When a user is transferred from a post, if many permissions of the transferred user need to be assigned to other users, in processing, separating the permissions of the transferred user and creating rôles to relate to other users are necessary. The operations are complicated, time-consuming, and prone to errors.

[0065] The method in the présent application is as follows: The transferred user is related to several rôles. When the user is transferred, the relation between the user and the rôles in the original department is first cancelled (the cancelled rôles may be re-related to other users), and then the user is related to a rôle in a new department. The operation is simple and not error-prone.

[0066] (8) The rôle belongs to a certain department, the department cannot be replaced. Reasons that the department cannot replaced for the rôle are as follows.

[0067] Reason 1: As the rôle in the présent application is équivalent to a work station number or a post number in nature, different work station numbers or post numbers hâve different work content or permissions. For example, a rôle of a salesperson 1 under a sales department and a rôle of a developer 1 under a technical department are two completely different work station numbers or post numbers, and hâve different permissions.

[0068] Reason 2: If the department (sales department) to which the rôle of the salesperson 1 belongs is replaced by the technical department without changing the permissions of rôle of the salesperson 1, a rôle that owns the permissions of the sales department exists in the technical department. This leads to management confusion and security vulnerabilities.

[0069] (9) One rôle can exist at different approval nodes in one approval process.

The permissions can be set for each approval rôle of each approval node independently. The approval rôle may own different permissions of viewing and modifying the form field at different approval nodes. Exemplary advantages: A rôle is a Chengdu sales manager 3. In a contract approval workflow, the rôle exists at two approval nodes: an approval node of Chengdu sales contract, and an approval node of Shanghai sales contract. At the approval node of Chengdu sales contract, the rôle can view the content of ail fields of a contract, such as a customer name, a contact person, contact information, a product quantity, a unit price of products, and a contract amount, and can modify the unit price of products and the contract amount. However, at the approval node of Shanghai sales contract, the rôle cannot view the content of sensitive fields such as the customer name, contact person, and contact information, and cannot make modifications thereto. In this way, the permissions ofthe rôle set in the approval process can be customized.

BRIEF DESCRIPTION OF THE DRAWINGS

DESCRIPTION OF THE DRAWINGS

[0070] FIG. I is a schematic diagram in which a system directly authorizes a user in the prior art;

[0071] FIG. 2 is a schematic diagram in which a system authorizes a rôle of a group or class nature in the prior art;

[0072] FIG. 3 is a schematic diagram in which a system both directly authorizes a user and authorizes a rôle of a group or class nature in the prior art;

[0073] FIG. 4 is a flowchart of a workflow control method according to the présent invention;

[0074] FIG. 5 is a schematic diagram in which a system authorizes a user through a rôle of an independent individual nature according to the présent invention;

[0075] FIG. 6 is a schematic diagram of a workflow approval process according to the présent invention; and

[0076] FIG. 7 is a flowchart of a user-role authorization method according to the présent invention.

DETAILED DESCRIPTION

Description of Embodiments

[0077] The technical solutions of the présent invention will be described in further detail below with reference to the accompanying drawings, but the protection scope of the présent invention is not limited to the following.

[0078] [Embodiment 1] As shown in FIG. 4, a workflow control method based on a one-to-one correspondence between rôles and users includes the following steps:

[0079] SI: Building a three-layer structure model of user-role-permission that includes:

[0080] a rôle layer, wherein an operation subject of process approval in a workflow is a rôle, each rôle is an independent individual rather than a group or class, one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles;

[0081] a permission layer including a permission required to be used in the execution of the workflow, wherein the permission is directly granted to a rôle, and

[0082] a user layer, wherein a user détermines an approval task in the workflow through a related rôle, and performs an approval operation with the permission of the related rôle.

[0083] S2: As shown in FIG. 6, using the three-layer structure model to control the workflow, wherein one approval process includes:

[0084] one start node initiating or requesting or submitting the workflow,

[0085] at least one approval node selecting an approval rôle and authorizing the approval rôle, and

[0086] one end node, to which the approval process cornes and then is ended.

[0087] S3: determining, according to a user's related rôle, an approval task to be processed, and perform an approval operation with the permission of the related rôle.

[0088] When a workflow is initiated or requested or submitted at the start node, a start rôle initiâtes or requests or submits the workflow, wherein only a rôle having the permission to start a workflow can initiate or request or submit the workflow as the start rôle.

[0089] When a workflow is initiated or requested or submitted at the start node, a System détermines an approval process based on a form submitted by the start rôle.

[0090] When a workflow is initiated or requested or submitted at the start node, one or more approval processes are designed for a form that requires a workflow, but one rôle can only select one approval process under the form (the same rôle can exist in only one of the processes of the same form).

[0091] For example, there are two processes such as a PI process and a P2 process in a purchase contract. If a rôle A is selected at a start node of the PI process, the rôle A cannot be selected any more at the start node of the P2 process. In this case, approval of the purchase contract is added to the rôle A, and the purchase contract submitted for approval enters the PI process automatically.

[0092] One or more approval rôles are selected at the approval node, one rôle can exist at different approval nodes in one approval process, and the approval rôle may own different permissions for viewing and modifying a form field at different approval nodes. Exemplary advantages: A rôle is a Chengdu sales manager 3. In a contract approval workflow, the rôle exists at both approval nodes of Chengdu sales contract and Shanghai sales contract. At the approval node of Chengdu sales contract, the rôle can view a customer name, a contact person, contact information, a product quantity, a unit price of products, and a contract amount, and may modify the unit price of products and the contract amount. However, at the approval node of Shanghai sales contract, the rôle cannot view the sensitive fields such as the customer name, contact person, and contact information, and the like, and cannot make any modifications (altematively, the rôle may be set to hâve the view permission but no modification permission).

[0093] One or more approval rôles are selected at the approval node, an approval role's permission is set at the approval node, and the permission can be independently set for each approval rôle of each approval node. For example, two approval rôles, namely, a rôle A and a rôle B, are set at an approval node in the approval process of a contract form. It may be set that the rôle A is allowed to view a contract price field in the contract form and the value of the field, and allowed to view a customer address field in the contract form and the value ofthe field. The rôle B is not allowed to view the contract amount field in the contract form, or allowed to view the contract amount field but not allowed to view the value ofthe field, The value not allowed to be viewed may be shown as other symbols such as *. The rôle B can view the customer address field in the contract form and the value of the field.

[0094] [Embodiment 2] As shown in FIG. 5 and FIG. 7, step SI includes the following sub-steps:

[0095] S101 : creating a rôle, wherein each rôle is an independent individual rather than a group or class;

[0096] S102 : authorizing rôles created in step S101 respectively; and

[0097] S103: relating a user to a rôle, wherein one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles.

[0098] Step S101 is preceded, but step S102 and step S103 hâve no sequential relationship.

[0099] The user détermines the permissions through its relation to the rôle. If the permissions of user need modification, the permissions possessed by the rôle are adjusted to achieve to the purpose of changing the permissions of the user related to the rôle. Once the user is related to the rôle, the user owns ail operation permissions of the rôle.

[0100] A rôle is in a one-to-one relation to a user (when the rôle is related to one user, other users can no longer be related to the rôle; if the rôle is not related to the user, the rôle can be selected to be related to another user). A user is in a one-to-many relation to rôles (one user can be related to multiple rôles at the same time).

[0101] Définition of a rôle: A rôle is not in the nature of a group/class/category/post/position/work type or the like, but is of a non-collective nature. The rôle is unique and is an independent individual. Applied in an enterprise or an institution, the rôle corresponds to a post number (the post number herein is not a post, one post may hâve multiple employées at the same time, but one post number can only correspond to one employée during the same period).

[0102] For example, in a company system, the following rôles may be created: a general manager, a deputy general manager 1, a deputy general manager 2, a manager of Beijing sales department 1, a manager of Beijing sales department II, a manager of Beijing sales department III, a Shanghai sales engineer 1, a Shanghai sales engineer 2, a Shanghai sales engineer 3, a Shanghai sales engineer 4, a Shanghai sales engineer 5, and so on.

[0103] The relation between users and rôles is as follows: If Zhang San, the company's employée, serves as a deputy general manager 2 of the company and also serves as a manager of Beijing sales department I, rôles to which Zhang San needs to be related to are the deputy general manager 2 and the manager of Beijing sales department I, and Zhang San has the permissions of the two rôles.

[0104] Authorization for a rôle: the system's authorization for a rôle includes, but is not limited to, authorization of a form, authorization of a menu, or authorization of a function. Authorization for the operation of a form includes, but is not limited to, addition, délétion, insertion and modification.

[0105] The concept of conventional rôles is a group/class/post/position/work type in nature, and one rôle can correspond to multiple users. In the présent application, the concept of rôle is équivalent to a post number/work station number, and is also similar to the rôle in the film and télévision drama: one rôle (in childhood, juvénile, middle-age...) can be played by only one actor or actress at the same time, but one actor may play multiple rôles.

[0106] Authorization for a rôle includes, but is not limited to, authorization of a form, authorization of a menu, or authorization of a function.

[0107] The rôle belongs to a certain department, the rôle is unique under the department, and the rôle is authorized according to work content of the rôle.

[0108] If the user wants to change a department, it involves cross-department transfer. The spécifie operation process includes:

[0109] (1) cancelling the user's relation to the rôle in the original department; and

[0110] (2) relating the user to a rôle in a new department.

[OUI] After the rôle is created, the rôle may be related to a user in the process of creating the user, or may be related to at any time after the user is created. After the user is related to the rôle, the user can be released from the relation to the rôle at any time, and the relation between rhe user and another rôle may be created at any time.

[0112] [Embodiment 3] Step SI includes the following sequential sub-steps:

[0113] S101 : creating a rôle, wherein each rôle is an independent individual rather than a group or class;

[0114] S102: relating a user to a rôle, wherein one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles; and

[0115] S103: authorizing rôles created in step S101 respectively.

[0116] The rôle belongs to a certain department, the rôle is unique under the department, and the rôle is authorized according to work content of the rôle.

[0117] The workflow control method further includes a step of managing cross-department transfer of a user, which specifically includes:

[0118] (1) cancelling the user's relation to the rôle in the original department; and

[0119] (2) relating the user to a rôle in a new department.

[0120] [Embodiment 4] A workflow control system based on a one-to-one correspondence between rôles and users includes a model construction unit, a workflow control unit, and an approval operation unit.

[0121] The model building unit is used to build a three-layer structure model of user-role-permission that includes:

[0122] a rôle layer, wherein an operation subject of process approval in a workflow is a rôle, each rôle is an independent individual rather than a group or class, one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles,

[0123] a permission layer including a permission required to be used in the execution the workflow, wherein the permission is directly granted to a rôle, and

[0124] a user layer, wherein a user détermines an approval task in the workflow through a related rôle, and performs an approval operation with the permission of the related rôle.

[0125] The workflow control unit Controls the workflow by using the three-layer structure model, wherein one approval process includes:

[0126] one start node initiating or requesting or submitting the workflow;

[0127] at least one approval node selecting an approval rôle and authorizing the approval rôle; and

[0128] one end node, to which the approval process cornes and then is ended.

[0129] In the approval operation unit, the user déterminés, according to the rôle related to the user, the approval task to be processed, and performs the approval operation with the permission of the related rôle.

[0130] The model building unit includes:

[0131] a rôle création submodule used to perform rôle layout according to posts and create system rôles, wherein each rôle is an independent individual rather than a group or class;

[0132] a rôle authorization submodule used to authorize the rôle according to work content of the rôle; and

[0133] a user-role relation submodule used to relate the user to the rôle, ensuring that one rôle can be related to a unique user during the same period, and one user is related to one or more rôles.

[0134] The system rôle is composed of: a post name + a post number, for example, a workshop worker 1, a workshop worker 2, a workshop worker 3, and so on. A rôle is an independent individual, and is équivalent to a concept of a post number or a work station number, but different from a rôle in a conventional permission management System. The concept of a rôle in a conventional permission management system is of a group or class nature such as a post, a position, a work type or the like.

[0135] [Embodiment 5] The following example shows the relationship among an employée, a user, and a rôle after Zhang San, an employée, enters a company.

[0136] 1. Recruiting: after the employée is recruited, he is directly related to the rôle ofthe corresponding post number or work station number for the user (employée). For example, when Zhang San has joined the company (the company has assigned a user for Zhang San) and works at the sales department I to be responsible for sales of refrigerator products in Beijing area (the corresponding rôle is sales engineer 5 under the sales department I), then the user Zhang San directly selects and is related to the rôle sales engineer 5.

[0137] 2. Adding position: After Zhang San has worked for a period of time, the company will arrange Zhang San to be responsible for sales of TV products in Beijing area (the corresponding rôle is sales engineer 8 under the sales department I) and to serve as a superviser of an after-sales department (the corresponding rôle is after-sales department superviser 1). Therefore, two rôles, that is, sales engineer 8 under the sales department I and after-sales department superviser 1 under the after-sales department, are additionally related to the user Zhang San. In this case, the employée Zhang San is related to three rôles: sales engineer 5 and sales engineer 8 under the sales department I, and after-sales department superviser 1 under the after-sales department. Therefore, the user Zhang San owns the permissions of the three rôles.

[0138] 3. Reducing position: After a while, the company has decided to let Zhang

San serve as an after-sales department manager (corresponding to a rôle after-sales manager under the after-sales department) without taking up other positions any more. Therefore, the user Zhang San is related to the rôle after-sales department manager under the after-sales department, and is released from the relation to the previous three rôles (sales engineer 5 and sales engineer 8 under the sales department I, and after-sales department supeivisor 1 under the sales department). In this case, the user Zhang San owns only the permissions of the rôle after-sales department manager under the after-sales department.

[0139] 4. Adjusting permission of a rôle (adjusting the permissions of the rôle itself): If the company has decided to add permissions to the after-sales department manager, the permissions only need to be added to the rôle of the after-sales department manager. With the increase in the permissions of the rôle of the after-sales department manager, the permissions of the user Zhang San are also increased.

[0140] 5. Resigning: After one year, Zhang San resigns. It only needs to cancel the relation between the user Zhang San and the rôle after-sales department manager under the after-sales départaient.

[0141] For example, during the dynamic operation of the company, recruiting and resigning of staff often occur continuously, but post numbers or work station numbers seldom change (or even remain unchanged within a period of time).

[0142] Conventional authorization method: In the case of a large quantity of system fonctions, authorizing a rôle conventionally as a group or class in nature involves a large and cumbersome workload and is very error-prone, and errors are not easily détectable in a short time and tend to cause loss to a system user.

[0143] Authorization method of the présent application: in the présent application, the rôle being a post number or work station number in nature is authorized, and the user is related to the rôle to détermine its permissions. Therefore, the permissions of the user are controlled by only a simple user-role relation. Controlling the permissions is simple, easily opérable, clear, and explicit, thereby significantly improving the efficiency and reliability of authorization.

[0144] The conventional role-based user permission management and workflow control methods adopt a role-to-user one-to-many relation mechanism, where the rôle is a group or class in nature. To be spécifie, one rôle may correspond to or be related to multiple users at the same time. The rôle is similar to a concept such as a post or a position or a work type. Basically, the user’s permissions under this relation mechanism may be granted in the following three ways:

[0145] 1. As shown in FIG. 1, the permission is directly granted to the user, where disadvantage is that it leads to large workloads and frequent and cumbersome operations. In the approval process, the approval operation subject of the approval node is the user, and the workflow approval node directly selects the employée or user as the approval subject. When changes on an employée hâve occurred (such as transfer or résignation), ail processes related to the employée shall be adjusted accordingly. Especially, for the change of the employée in the management position of a company, many approval processes are involved, and the adjustment of the processes involves large workloads, and is cumbersome and prone to errors and omissions. This affects normal operation of the company, or even causes unpredictable losses.

[0146] Even if the change occurs only in the approval permissions of the employée, it is still necessary to correspondingly adjust the processes related to the employée, and the similar problems described above still occur.

[0147] 2. As shown in FIG. 2, the rôle (of a class/group/post/work type nature) is authorized (one rôle may be related to multiple users), the user obtains permissions through its rôle, and the approval operation subject is the rôle of a group or class nature.

[0148] 3. As shown in FIG. 3, the above two ways are combined.

[0149] In the above description, as both 2 and 3 need to authorize the rôle of a class or group nature. The way of authorization and workflow control through the rôle of a class/group/post/work type nature has the following disadvantages:

[0150] 1. Operations are difficult when user permissions hâve changed: In the actual process of using a System, the user's permissions often need to be adjusted during the operation process. For example, in processing of the change of an employee's permissions, when the permission of an employée related to the rôle has changed, it is improper to change the permissions of the entire rôle due to the change of the permissions of the individual employée, because the rôle is also related to other employées whose permissions remain unchanged. In order to respond to this situation, either a new rôle is created to fit the employée whose permissions hâve changed, or permissions are directly granted to the employée (disengaged from the rôle) based on permission requirements. The above two processing methods not only take a long time but also cause mistakes easily for the rôle authorization in the case of a large number of rôle permissions. It is cumbersome for a user to operate, and errors occur easily, resulting in loss to the System user.

[0151] When the approval permissions of the employée or user hâve changed, either the employée or the user is disengaged from the rôle, and at the workflow approval node, the employée or the user is directly selected as an approval subject, or a new rôle is added to meet the requirements of the approval process. In the first way, when changes on an employée hâve occurred (such as transfer or résignation), ail processes related to the employée shall be adjusted accordingly. Especially, for changes on an employée in a management position of an enterprise, many approval processes are involved. As the adjustment of the processes involves large workloads, errors or omissions are likely to occur, affecting the normal operation of the enterprise and even causing unpredictable losses. Even if the change only occurs in the approval permissions of the employée, it is still necessary to correspondingly adjust the processes related to the employée, and similar problems described above still occur. In the second way, adding a rôle involves création, relation, and authorization of the rôle. Especially when there are many rôles and many users related to the rôles, it is difficult to remember which users are related to the rôle.

[0152] 2. It is difficult to remember the spécifie permissions contained in a rôle for a long time: If the rôle has many permission functions, over time, it is difficult to remember the spécifie permissions of the rôle, and it is even harder to remember the différences in permissions between rôles with similar permissions. The permissions of similar rôles are also easily confusable. If a new user needs to be related, it cannot be accurately determined how to select the relation.

[0153] 3. Because user permissions change, it results in more rôles created (if new rôles are not created, it greatly increases direct authorization to the user), and it is more difficult to distinguish spécifie permission différences between the rôles.

[0154] 4. When a user is transferred from a post, if many permissions of the transferred user need to be assigned to other users, separating the permissions of the transferred user and creating rôles to relate to other users are necessary. The operations are complicated, time-consuming, and prone to errors.

[0155] The above is only a preferred embodiment of the présent invention, and it should be understood that the présent invention is not limited to the forms disclosed herein, and is not to be construed as being limited to the other embodiments, but may be used in 5 various other combinations, modifications and environments. Modification can be made in by the techniques or knowledge of the above teachings or related art within the scope of the teachings herein. Ail changes and modifications made by those skilled in the art are intended to be wi thin the scope of the appended daims.

Claims (12)

1. What is claimed is:

   1. A workflow control method based on a one-to-one correspondence between rôles and users, comprising the following steps:

   SI : building a three-layer structure model of user-role-permission that comprises:

   a rôle layer, wherein an operation subject of process approval in a workflow is a rôle, each rôle is an independent individual rather than a group or class, one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles, a permission layer comprising a permission required to be used in the execution of the workflow, wherei n the permission is directly granted to a rôle, and a user layer, wherein a user détermines an approval task in the workflow through a related rôle, and performs an approval operation with the permission of the related rôle;

   S2: using the three-layer structure model to control the workflow, wherein one approval process comprises:

   one start node initiating or requesting or submitting the workflow, at least one approval node selecting an approval rôle, and authorizing the approval rôle; and one end node, to which the approval process cornes and then is ended; and

   S3: determining, according to a user's related rôle, an approval task to be processed, and performing an approval operation with the permission of the related rôle.
2. 2. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 1, wherein when a workflow is initiated or requested or submitted at said start node, a start rôle initiâtes or requests or submits the workflow, wherein only a rôle having the permission to start a workflow can initiate or request or submit the workflow as the start rôle.
3. 3. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 1, wherein a workflow is initiated or requested or submitted at said start node, a system détermines an approval process according to a form submitted by a start rôle.
4. 4. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 1, wherein a workflow is initiated or requested or submitted at said start node, one or more approval processes are designed for a form that requires a workflow, but one rôle can only select one approval process under the form.
5. 5. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 1, wherein one or more approval rôles are selected at said approval node, one rôle can exist at different approval nodes in one approval process, and the approval rôle may own different permissions for viewing and modifying a form field at different approval nodes.
6. 6. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 1, wherein one or more approval rôles are selected at said approval node, an approval role's permission is set at said approval node, and the permission can be independently set for each approval rôle of each approval node.
7. 7. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 1, wherein step SI comprises the following sub-steps:

   S101: creating a rôle, wherein each rôle is an independent individual rather than a group or class;

   S102: authorizing rôles created in step S101 respectively; and

   S103: relating a user to a rôle, wherein one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles, wherein, step S101 is preceded, but step S102 and step S103 hâve no sequential relationship.
8. 8. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 1, wherein said rôle belongs to a certain department, said rôle is unique under the department, and said rôle is authorized according to work content of said rôle.
9. 9. The workflow control method based on a one-to-one correspondence between rôles and users according to claim 8, further comprising a step of managing cross-department transfer of a user, which specifically comprises:

   (1) cancelling the user's relation to the rôle in the original department; and (2) relating the user to a rôle in a new department.
10. 10. A workflow control system based on a one-to-one correspondence between rôles and users, comprising a model building unit, a workflow control unit, and an approval operation unit, wherein, said model building unit is used to build a three-layer structure model of user-role-permission comprises:

    a rôle layer, wherein an operation subject of process approval in a workflow is a rôle, each rôle is an independent individual rather than a group or class, one rôle can only be related to a unique user during the same period, and one user is related to one or more rôles;

    a permission layer comprising a permission required to be used in the execution of the workflow, wherein the permission is directly granted to a rôle; and a user layer, wherein a user détermines an approval task in the workflow through a related rôle, and performs an approval operation with the permission of the related rôle;

    said workflow control unit Controls the workflow by using the three-layer structure model, wherein one approval process comprises:

    one start node initiating or requesting or submitting the workflow;

    at least one approval node selecting an approval rôle and authorizing the approval rôle; and one end node, to which the approval process cornes and then is ended;

    in said approval operation unit, the user détermines, according to the rôle related to the user, the approval task to be processed, and performs the approval operation with the permission of the related rôle.
11. 11. The workflow control System based on a one-to-one correspondence between rôles and users according to claim 10, wherein said model building unit comprises:

    a rôle création submodule used to perform rôle layout according to posts and create 5 System rôles, wherein each rôle is an independent individual rather than a group or class;

    a rôle authorization submodule used to authorize the rôle according to work content of the rôle; and a user-role relation submodule used to relate the user to the rôle, ensuring that one rôle can be related to a unique user during the same period, and one user is related to one or 10 more rôles.
12. 12. The workflow control System based on a one-to-one correspondence between rôles and users according to claim 11, wherein said System rôle is composed of: a post name + a post number.