Setting method of form field operation authority of workflow and setting method of form field operation authority of approval node

Abstract

The invention discloses a setting method of a form field operation authority of a workflow. The workflow includes a start node and an approval node, and the form field operation authority of the startnode and the form field operation authority of the approval node are set differently. In addition, a setting method of a form field operation authority of the approval node is disclosed. The approvalnode includes one or more approvers, the form field operation authority of each approver in the approval node is customized, specifically including: selecting an approver from the approval node; obtaining the default setting of the form field operation authority; modifying the default setting of the form field operation authority according to an approval item of the selected approver in the workflow. According to the invention, the approval period is shortened, the workload of examination and approval is reduced, and the information security is enhanced.

Description

technical field [0001] The invention relates to a method for setting authority in workflow of management software systems such as ERP, in particular to a method for setting operation authority of form fields of workflow and approval nodes thereof. Background technique [0002] Role-based access control (RBAC) is the most researched and thoughtful database permission management mechanism in recent years. It is considered to be an ideal candidate to replace traditional mandatory access control (MAC) and discretionary access control (DAC). Traditional discretionary access control has high flexibility but low security, mandatory access control has high security but is too restrictive; role-based access control combines both, which is not only easy to manage but also reduces complexity, cost and error probability , which has been greatly developed in recent years. The basic idea of ​​role-based access control (RBAC) is to divide different roles according to different functional ...

AI Technical Summary

Problems solved by technology

[0008] In the above statement, both 2 and 3 need to authorize the role of class / group nature, but the method of authorization and workflow control through the role of class / group / position / type of work has the following disadvantages: 1. When user permissions change Difficult to operate: In actual system use, it is often necessary to adjust user permissions during operation. For example, when dealing with changes in employee permissions, the permissions of an employee associated with a role change. We cannot Changes in employee permissions change the permissions of the entire role, because the role is also associated with other employees whose permissions have not changed

[0010] 2. It is difficult to remember the specific permissions contained in the role for a long time: If the role has many permission function points, it is difficult to remember the specific permissions of the role over time, and it is even more difficult to remember the permission differences between roles with similar permissions. The permissions of the role are also easy to confuse; if you want to associate a new user, you cannot accurately determine how to choose the association

[0011] 3. Due to the change of user permissions, more and more roles will be created (if no new roles are created, the direct authorization to users will be greatly increased), and it is more difficult to distinguish the specific differences between the permissions of each role

[0012] 4. When transferring a post, if you want to assign many permissions of the transferred user to several other users, you must distinguish these permissions of the transferred user during processing, and then create roles to associate with the other users. users, such an operation is not only complicated and time-consuming, but also prone to errors

Example 2, the sales contract of a Shanghai branch needs to be approved by the personnel of the Chengdu branch, but the approval personnel of the Chengdu branch do not have the authority to view the sales contract of the Shanghai branch in the system (because the personnel of the Chengdu branch are in the system According to the needs of business management, authorization is only authorized to view the sales contract of the Chengdu branch, but not the sales contract of the Shanghai branch; but when setting an approval node for approving the sales contract of the Shanghai branch, the Chengdu branch is considered A person with strong ability has set this person from the Chengdu Branch to this approval node as the approver of the approval node. When the approver approves the sales contract of the Shanghai Branch at the approval node, due to the Nodes do not set independent permissions, but the approval nodes in the approval process adopt / inherit the permissions of the approver in the form corresponding to the approval process of the approver in the system, then the permission of the approver in the approval node is Adopt / continue to use the authority of the sales contract form in the system, and because the authority of the approver in the system is only to view the sales contract of the Chengdu branch, but not the authority to view the sales contract of the Shanghai branch), at this time, it will lead to The approval personnel of the Chengdu branch cannot view the relevant content of the sales contract, resulting in the inability to complete the normal approval process

[0015] When the same permissions are set for all nodes, some approvers can view sensitive information that they do not need for approval, which will expand the scope of dissemination of these information, easily lead to information leakage, and threaten information security, such as approval before the contract is signed: financial approval The approver mainly examines whether the contract should be signed from the financial point of view, and does not need to know the customer's contact information. If the financial approver is set to view the customer's contact information, it may lead to the disclosure of the customer's contact information.

In addition, in a contract approval process, approver A is in the third and fifth approval nodes, and the third approval node is to approve the product technical requirements in the contract, so this approval node only needs to display technical information Yes, the fifth approval node is the mode of transportation in the approval contract, and only the relevant transportation information can be displayed; the traditional setting of the same authority for approver A on all approval nodes cannot meet the different approval requirements for different approval nodes Make different permission settings

Images