OA19448A - Role acquisition-based method for authorizing form data. - Google Patents
Role acquisition-based method for authorizing form data. Download PDFInfo
- Publication number
- OA19448A OA19448A OA1202000027 OA19448A OA 19448 A OA19448 A OA 19448A OA 1202000027 OA1202000027 OA 1202000027 OA 19448 A OA19448 A OA 19448A
- Authority
- OA
- OAPI
- Prior art keywords
- rôle
- user
- target
- form data
- authorized
- Prior art date
Links
- 230000000875 corresponding Effects 0.000 claims description 24
- 230000001939 inductive effect Effects 0.000 abstract description 6
- 238000000034 method Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000004048 modification Effects 0.000 description 5
- 238000006011 modification reaction Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 2
- 238000007796 conventional method Methods 0.000 description 1
Abstract
An authorization method based on form data gotten by a role is disclosed in the present invention, including: selecting one or more grantees; selecting a form, and displaying an authorized field used for searching form data; displaying all roles in a system, defining a role that needs to be used for searching form data as a target role, and selecting a target object for each target role respectively, where the target object is a current object, a historical object, or all objects; defining a target role and a user or an employee in its target object as a limited value; for each target role of each authorized field, respectively getting a set of form data, any limited value of the target role of which is included by a field value of the authorized field in the form, and authorizing an operation permission to the set. The present invention achieves dynamic authorization of form data, so that related permissions can be adjusted automatically in the resignation, transfer, induction of the employees and other cases, thus reducing workloads of the authorization operation and making it less error-prone.
Description
[0002] Role-based access control (RBAC) is one of the most researched and mature 10 permission management mechanisms for databases in recent years. It is considered to be an idéal candidate to replace conventional mandatory access control (MAC) and discretionary access control (DAC). 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 15 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-scale application Systems, which makes the management and permissions of database resources very complicated. It is very difficult for a 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 20 database structure and to be familiar with the use of the SQL language. Once the 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 25 has become a common requirement for Systems and System users.
[0004] The role-based permission control mechanism can manage the access permissions of the System simply and efficiently, which greatly reduces the burden and cost of the permission management of the system, and makes the permission management of the system more compilant with the business management spécifications of the application System.
[0005] However, the conventional role-based user permission management method adopts the role-to-user one-to-many relation mechanism, where the rôle has the nature of a group/a class. That is, one rôle can simultaneously correspond to/be related to multiple users, and the rôle is similar to a post/a position/a type of work or other concepts. The permission authorized to a user under this relation mechanism is basically divided into the following three forms: 1. As shown in FIG. 1, the permission is directly authorized to the user, where the disadvantage is that the workload is large and the operation is frequent and cumbersome. 2. As shown in FIG. 2, the rôle (having the nature of a class/a group/a post/a type of work) is authorized (one rôle may be related to multiple users), the user obtains permissions through its rôle. 3. As shown in FIG. 3, the above two methods are combined.
[0006] In the above descriptions, as both 2 and 3 need to authorize the rôle that has the nature of a class/a group. The way of authorization through the rôle having the nature of a class/a group/a post/a type of work has the following disadvantages: 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 the change in 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 in the permissions of the individual employée, because this rôle is also related to other employées whose permissions remain unchanged. To deal with this situation, either a new rôle is created to fit the employée whose permissions hâve changed, or permissions are directly authorized 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.
[0007] 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, as time goes by, it is difficult to remember the spécifie permissions of the rôle, and it is even more difficult to remember the permission différences between rôles with similar permissions. If a new user needs to be related, it is impracticable to accurately détermine how to select a relation.
[0008] 3. Because user’s permissions change, more rôles will be created (if new rôles are not created, direct authorization to the user will be increased greatly), and it is more difficult to distinguish spécifie différences between the permissions of the rôles.
[0009] 4. When a user is transferred from a post, if many permissions of the transferred user need to be assigned to other users, it is necessary to distinguish the permissions of the transferred user and create rôles to relate to the other users respectively during processing. Such operations are not only complicated and time-consuming, but also prone to errors.
[0010] In the conventional authorization control of form data based on a field having the nature of an employée, if there are a large number of employées (for example, 500 employées), the situations such as the résignation, induction, and transfer of the employées continue arising dynamically at any time, which makes the authorization operation very complicated and involves tremendous workloads. Moreover, in the case of the résignation, induction, and transfer of the employées, the original related authorization needs to be modified, and as a resuit, the authorization involves tremendous workloads, and is complicated and prone to errors.
[0011] In the conventional authorization control of form data based on a field having the nature of a user, because the conventional System does not establish a fixed one-to-one relationship between users and employées, it exists that multiple employées may log into the system as one user. When the form data is saved, the field value of the field thereof having the nature of a user can only record an operating user, but it cannot be accurately recorded and distinguished whether the employée corresponding to the operating user is Zhang San or Li Si, which makes it difficult to know the employée corresponding to the operating user clearly and accurately when the data is viewed subsequently.
[0012] In the conventional authorization method, the dynamic authorization cannot be done, merely to view the related work of carrent employees/users with some post numbers, not to view the related work of historical employees/users with these post numbers, or on the contrary, the dynamic authorization can be done, to view the related work of historical employees/users with some post numbers, not to view the related work of current employees/users with these post numbers.
SUMMARY
Technical Problems
[0013] The object of the présent invention is to overcome the deficiencies of the prior art, and provide an authorization method based on form data gotten by a rôle, which achieves the dynamic authorization of form data, so that related permissions can be adjusted automatically during the résignation, transfer, and induction of employées, thus reducing workloads of the authorization operation and making it less error-prone.
Solutions to Problems
Technical Solutions
[0014] The object of the présent invention is achieved by the following technical solutions: An authorization method based on form data gotten by a rôle includes:
[0015] (1) selecting one or more grantees;
[0016] (2) selecting a form, and displaying an authorized field used for searching form data, where said authorized field is a field, the field value of which includes a user or an employée;
[0017] (3) authorizing each authorized field respectively: displaying ail rôles in a system, wherein said rôle is an independent individual not a group/a 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; defining a rôle that needs to be used for searching form data as a target rôle, where one target rôle corresponds to one rôle; selecting a target object for each target rôle respectively, where said target object is a current object, a historical object, or ail objects, said current object is a user currently related to the rôle or an employée corresponding to the user, said historical object is ail users who hâve been related to the rôle except the user currently related to the rôle or employées corresponding to the users, and said ail objects are ail users who hâve been related to the rôle or employées corresponding to the users; and 5 [0018] (4) for each target rôle of each authorized field, getting a set of form data, any user or employée of the target object of the target rôle of which is included by a field value of the authorized field in said form, respectively, and authorizing an operation permission to the set.
[0019] Steps (2), (3), and (4) are performed sequentially, and step (1) is performed 10 before step (2), or performed between step (2) and step (3), or performed between step (3) and step (4), or performed after step (4).
[0020] An authorization method based on form data gotten by a rôle includes:
[0021] (1) selecting one or more grantees;
[0022] (2) selecting a form, and displaying an authorized field used for searching form data, where said authorized field is a field, the field value of which includes a rôle and a user, or a rôle and an employée;
[0023] (3) authorizing each authorized field respectively: displaying ail rôles in a
System, where said rôle is an independent individual not a group/a 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 20 rôles; defining a rôle that needs to be used for searching form data as a target rôle, where one target rôle corresponds to one rôle; selecting a target object for each target rôle respectively, where said target object is a current object, a historical object, or ail objects, said current object is a user currently related to the rôle or an employée corresponding to the user, said historical object is ail users who hâve been related to the rôle except the user 25 currently related to the rôle or employées corresponding to the users, and said ail objects are ail users who hâve been related to the rôle or employées corresponding to the users; and defining a target rôle and a user or an employée in the target object of the target rôle as a limited value of the target rôle;
[0024] (4) for each target rôle of each authorized field, getting a set of form data, any limited value of the target rôle of which is included by a field value of the authorized field in said form, respectively, and authorizing an operation permission to the set.
[0025] Steps (2), (3), and (4) are performed sequentially, and step (l) is performed 5 before step (2), or performed between step (2) and step (3), or performed between step (3) and step (4), or performed after step (4).
[0026] Preferably, said operation permission includes one or more operations of viewing, modifying, adding, deleting and printing form data.
[0027] Preferably, said user détermines (obtains) permissions through its relation to 10 the rôle, one employée corresponds to one user, and one user corresponds to one employée.
[0028] Preferably, said rôle belongs to a certain department, the rôle is authorized according to the work content of the rôle, the name of the rôle is unique under the department, and the number of the rôle is unique in the System.
[0029] Preferably, during cross-department transfer of said user, the user's relation 15 to the rôle in the original department is canceled, and the user is related to a rôle in a new department.
[0030] Preferably, a null option is displayed when ail rôles in the System are displayed, and if the null option is selected, the operation permission is authorized to the form data in which the field value of the authorized field in said form is null.
[0031] Preferably, an unrestricted option is displayed when ail rôles in the System are displayed, and if the unrestricted option is selected, the operation permission is authorized to the form data in which the field value of the authorized field in said form is any value.
[0032] Preferably, said grantee includes one or more types of a person, a user, a 25 group, a class, and a rôle, said rôle is an independent individual not a group/a 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.
[0033] An authorization method based on form data gotten by a rôle includes:
[0034] (1) selecting one or more grantees;
[0035] (2) selecting a form, and displaying an authorized field used for searching form data, where said authorized field is a field, the field value of which includes a rôle, said rôle is an independent individual not a group/a 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; and
[0036] (3) authorizing each authorized field respectively: displaying ail rôles in a
System, where said rôle is an independent individual not a group/a 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; defining a rôle that needs to be used for searching form data as a target rôle, where one target rôle corresponds to one rôle; and for each target rôle of each authorized field, getting a set of form data, the target rôle of which is included by a field value of the authorized field in said form, respectively, and authorizing an operation permission to the set.
[0037] Steps (2) and (3) are performed sequentially, and step (1) is performed before step (2), or performed between step (2) and step (3), or performed after step (3).
Bénéficiai Effects of the Invention
Bénéficiai Effects
[0038] The présent invention has the following bénéficiai effects: (1) The présent invention achieves dynamic authorization of form data, so that the related permissions can be adjusted automatically in the case of the résignation, transfer, induction of employées, and other cases, thus reducing the workloads of the authorization operation and making it less error-prone. For example, the supervisor 1 of a sales department I is authorized to view (view as a reimbursing applicant) the personal expense account of an employée currently with a certain post number under the department. If an employée Zhang San currently related to the post number is replaced by Li Si, the supervisor 1 automatically can only view the personal expense account of the latest employée Li Si (the reimbursing applicant is Li Si) related to the post number, and automatically cannot view the personal expense account of the employée Zhang San (the reimbursing applicant is Zhang San) originally related to the post number. For another example, the housekeeping supervisor l of a company is only authorized to view (view as a reimbursing applicant) the personal expense account of employées historically related to a certain post number, so as to carry out the 5 related analysis about ail the employées (excluding the currently related employée) who hâve been related to the post number. If the employée Zhang San currently related to the post number no longer works with the post number (the Zhang San’s relation to the post number/role is canceled), the housekeeping supervisor l can automatically view the personal expense account of Zhang San and carry out the related analysis. For another 10 example, a general manager 1 of the company is authorized to view (view as a reimbursing applicant) the personal expense accounts of ail employées related to a certain post number. After the employée Zhang San currently related to the post number is replaced by Li Si, the general manager 1 can automatically view Li Si's personal expense account (and can also view Zhang San's personal expense account).
[0039] The conventional authorization method is complicated, and cannot realize collective authorization for data corresponding to a person currently with a post number, a person who has worked with the post number, or ail persons who hâve worked with the post number, not to mention automatic dynamic. The présent invention achieves collective authorization easily and quickly by means of a current object, a historical object, and ail 20 objects, and can achieve an automatic dynamic correspondence function.
[0040] (2) The rôle in the présent invention is an independent individual not a group/a 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. One user is related to one employée, and one employée is related to one user. During operation of an enterprise or an institution, the rôle rarely 25 changes, and the rôle even remains unchanged in a relatively long period of time. In the case of the résignation, transfer and induction of an employée, the authorization can be completed by canceling the relation to the related rôle or relating to a new rôle. The authorization operation is simple, convenient, and highly efficient, which greatly improves the authorization efficiency.
[0041] (3) In the présent invention, the form data that needs to be authorized is gotten through a rôle and a user related to the rôle, or a rôle and an employée corresponding to a user related to the rôle, so that the permissions of the different responsibilities of an employée can be effectively distinguished when the form data is authorized. For example, Zhang San is currently related to a rôle 1 under an aircraft business department and a rôle 2 under a home appliance business department, the permission to view Zhang San's home appliance contract form needs to be authorized to a manager 1 of the home appliance business department now, and a contract signer field is selected as an authorized field. If the manager 1 is authorized according to the conventional employee-based authorization method and the field value of the contract signer is authorized to be Zhang San, the manager 1 of the home appliance business department can view ail home appliance contracts and aircraft contracts in which the contract signer fields are Zhang San. As a resuit, the manager 1 of the home appliance business department can view the aircraft contracts signed by Zhang San, which causes information leakage of the aircraft contracts. When the manager 1 of the home appliance business department is authorized using the method in the présent invention, and the field value of the contract signer field is authorized to be Zhang San (rôle 2), the manager 1 of the home appliance business department can only view the home appliance contracts signed by Zhang San (rôle 2), but cannot view the aircrafts contracts signed by Zhang San (rôle 1), thus achieving refined management and ensuring the information security of the company.
[0042] (4) The conventional permission management mechanism defines the nature of a group, a type of work, 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 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 this rôle is also related to other employées whose permissions remain unchanged. To deal with this situation, either a new rôle is created to fit the employée whose permissions hâve changed, or permissions are directly authorized 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.
[0043] 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 the 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 having the nature of a group. As it is 10 unnecessary to consider the commonality of the rôles having the nature of a group when satisfying the related users, the solutions in the présent application make 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 permission management efficiency for the 15 system user in using the system, make the dynamic authorization simpler, more convenient, clearer and more explicit, and improve the efficiency and reliability of the permission setting.
[0044] (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 20 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 having the nature of a group 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 having the nature of a group, ail users related 25 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 having the nature of a group, 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 there are many function points, and in many cases, the problem cannot be solved unless a new rôle is created.
[0045] (6) In the conventional group-based rôle authorization method, if the rôle has many permission function points, as time goes by, it is difficult to remember the spécifie permissions of the rôle, and it is even more difficult to remember the permission différences between rôles with similar permissions. If a new user needs to be related, it cannot be accurately determined how to select a relation. In the method of the présent application, the rôle itself has the nature of a post number/a station number, such that the sélection can be made easily.
[0046] (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, it is necessary to distinguish the permissions of the transferred user and creating rôles to relate to other users respectively. The operations are complicated, time-consuming, and prone to errors.
[0047] 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 canceled (the canceled 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 less error-prone.
[0048] (8) The rôle belongs to a department, and then the department to which the rôle belongs cannot be replaced. Reasons why the department to which the rôle belongs cannot be replaced are as follows. Reason 1: As the rôle in the présent application is équivalent to a station number/a post number in nature, different station numbers/post numbers hâve different work content/permissions. For example, the rôle of a salesperson 1 under a sales department and the rôle of a developer 1 under a technical department are two completely different station numbers/post numbers, and hâve different permissions. 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 the rôle of the salesperson 1, the rôle that owns the permissions of the sales department exists in the technical department. This leads to management confusion and security vulnerabilities.
BRIEF DESCRIPTION OF THE DRAWINGS
DESCRIPTION OF THE DRAWINGS
[0049] FIG. 1 is a schematic diagram in which a system directly authorizes a user in the prior art;
[0050] FIG. 2 is a schematic diagram in which a system authorizes a rôle having the nature of a group/a class in the prior art;
[0051] FIG. 3 is a schematic diagram in which a system both directly authorizes a user and a rôle having the nature of a group/a class in the prior art;
[0052] FIG. 4 is a flowchart of an embodiment in the présent invention;
[0053] FIG. 5 is a schematic diagram in which a system authorizes a user through a rôle having the nature of an independent individual according to the présent invention;
[0054] FIG. 6 is a schematic diagram of a form in the présent invention;
[0055] FIG. 7 is a flowchart of another embodiment in the présent invention;
[0056] FIG. 8 is a schematic diagram of a form when a header is checked;
[0057] FIG. 9 is a flowchart of still another embodiment in the présent invention; and
[0058] FIG. 10 is a schematic diagram of a form when a rôle is selected to be authorized.
DETAILED DESCRIPTION
Description of Embodiments
[0059] The technical solutions of the présent invention will be further described in detail below with reference to the figures, but the protection scope of the présent invention is not limited to the following descriptions.
[0060] [Embodiment 1] As shown in FIG. 4, an authorization method based on form data gotten by a rôle includes: selecting one or more grantees. The grantee includes one or more types of a person, a user, a group, a class, and a rôle.
[0061] As shown in FIG. 5, the rôle is an independent individual not a group/a 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.
[0062] The rôle belongs to a certain department, and the rôle is authorized 5 according to the work content of the rôle; the name of the rôle is unique under the department, and the number of the rôle is unique in a System. The user détermines (obtains) permissions through its relation to the rôle, one employée corresponds to one user, and one user corresponds to one employée.
[0063] Définition of a rôle: A rôle does not hâve the nature of a group/a class/a 10 category/a post/a position/a type of work or the like, but has a non-collective nature. The rôle is unique and is an independent individual. Applied in an enterprise or an institution, the rôle is équivalent to a post number (the post number herein is not a post, and 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).
[0064] 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 I, 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. The 20 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, the rôles to which Zhang San needs to be related are the deputy general manager 2 and the manager of Beijing sales department I, and Zhang San owns the permissions of the two rôles.
[0065] The concept of conventional rôles is a group/a class/a post/a position/a type of work in nature, and one rôle can correspond to multiple users. However, in the présent application, the concept of rôle is équivalent to a post number/a station number, and is also similar to the rôle in a film and télévision drama: one rôle (in childhood, juvénile, middle-age...) can be played by only one actor or actress during the same period, but one actor or actress may play multiple rôles.
[0066] During cross-department transfer of the user, the user's relation to the rôle in the original department is canceled, and the user is related to a rôle in a new department. After the rôle is created, a user may be related to the rôle in the process of creating the user, or may be related to the rôle 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 the user and another rôle may be created at any time.
[0067] A form is selected, and an authorized field used for searching form data is displayed, where the authorized field is a field, the field value of which includes a user or an employée. As shown in FIG. 6, the authorized field is creator.
[0068] Each authorized field is authorized respectively: ail rôles in a System are displayed, where the rôle is an independent individual not a group/a 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 rôle that needs to be used for searching form data is defined as a target rôle, where one target rôle corresponds to one rôle (for example, if 5 rôles need to be used for searching form data, there are 5 target rôles correspondingly); a target object is selected for each target rôle respectively, where the target object is a current object, a historical object, or ail objects, said current object is a user currently related to the rôle or an employée corresponding to the user, said historical object is ail users who hâve been related to the rôle except the user currently related to the rôle or employées corresponding to the users, and said ail objects are ail users who hâve been related to the rôle or employées corresponding to the users.
[0069] As shown in FIG. 6, the current object is selected as the target object for a salesperson 1 (rôle), the historical object is selected as the target object for a salesperson 2 (rôle), ail objects are selected as the target object for a salesperson 3 (rôle). If the salesperson 1 is currently related to a user A and has been related to a user B before, the target object of the salesperson 1 is the user A; if the salesperson 2 is currently related to a user C and has been related to a user D and a user E before, the target object of the salesperson 2 is the user D and the user E; if the salesperson 3 is currently related to a user
F and has been related to a user G before, the target object of the salesperson 3 is the user F and the user G.
[0070] For each target rôle of each authorized field, the set of form data, any user or employée of the target object of the target rôle of which is included by a field value of the authorized field in the form is gotten respectively, and the operation permission is authorized to the set. According to the setting of the target object in the example above, the operation permission is authorized to form data in which the field value of the creator in the contract form includes the user A, the operation permission is authorized to form data in which the field value of the creator in the contract form includes the user D or the user E, and the operation permission is authorized to form data in which the field value of the creator in the contract form includes the user F or the user G.
[0071] The operation permission includes one or more operations of viewing, modifying, adding, deleting and printing form data.
[0072] [Embodiment 2] As shown in FIG. 7, an authorization method based on form data gotten by a rôle includes: selecting one or more grantees. The grantee includes one or more types of a person, a user, a group, a class, and a rôle. The rôle is an independent individual not a group/a 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.
[0073] The rôle belongs to a certain department, and the rôle is authorized according to the work content of the rôle; the name of the rôle is unique under the department, and the number of the rôle is unique in a System. The user détermines (obtains) permissions through its relation to the rôle, one employée corresponds to one user, and one user corresponds to one employée.
[0074] During cross-department transfer of the user, the user's relation to the rôle in the original department is canceled, and the user is related to a rôle in a new department. After the rôle is created, a user may be related to the rôle in the process of creating the user, or may be related to the rôle 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 the user and another rôle may be created at any time.
[0075] A form is selected, and an authorized field used for searching form data is displayed, where the authorized field is a field, the field value of which includes a rôle and a user, or a rôle and an employée; that is, the authorized field may be a field, the field value 5 of which includes a rôle and a user, or may be a field, the field value of which is a rôle and an employée.
[0076] Each authorized field is authorized respectively: ail rôles in a system are displayed, where the rôle is an independent individual not a group/a 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 10 rôles; a rôle that needs to be used for searching form data is defined as a target rôle, where one target rôle corresponds to one rôle (for example, if 5 rôles need to be used for searching form data, there are 5 target rôles correspondingly); a target object is selected for each target rôle respectively, where the target object is a current object, a historical object, or ail objects, said current object is a user currently related to the rôle or an employée 15 corresponding to the user, said historical object is ail users who hâve been related to the rôle except the user currently related to the rôle or employées corresponding to the users, and said ail objects are ail users who hâve been related to the rôle or employées corresponding to the users; the target rôle and the user or the employée in the target object of the target rôle are defined as the limited value of the target rôle. If the target object of the 20 target rôle includes multiple users or employées, the target rôle and the users or employées in the target object of the target rôle are defined as multiple limited values.
[0077] For example, the target object of the target rôle A includes three users: a user A, a user B, and a user C. In this case, the target rôle A and the user A are defined as a limited value target rôle A (user A), the target rôle A and the user B are defined as a 25 limited value target rôle A (user B), and the target rôle A and the user C are defined as a limited value target rôle A (user C).
[0078] When the target object is selected for the rôle, if the column name of any one of the current object, the historical object, and ail objects is selected (for example, the current object selected in FIG. 8), the target objects of ail rôles (including the rôles to be added subsequently) are objects corresponding to the selected column name (one type of the current object, historical object, and ail objects). For example, in FIG. 8, the column name of the current object is selected, the target objects of a salesperson 1, a salesperson 2, a salesperson 3 and the like are ail their respective current objects. When ail rôles of the authorized field (including rôles to be added subsequently) are target rôles, and the target objects of these target rôles are of the same type (that is, ail the target objects are current objects, historical objects, or ail objects), one-step sélection can be achieved by selecting a corresponding column name (selecting a column name is merely a manifestation, the nature of this manifestation can also be achieved in other ways), thus greatly reducing the workloads of selecting the target objects for the target rôles and improving the efficiency of the authorization operation.
[0079] As shown in FIG. 6, the current object is selected as the target object for a salesperson 1 (rôle), the historical object is selected as the target object for a salesperson 2 (rôle), ail objects are selected as the target object for a salesperson 3 (rôle). If the salesperson 1 is currently related to a user A and has been related to a user B before, the target object of the salesperson 1 is the user A; if the salesperson 2 is currently related to a user C and has been related to a user D and a user E before, the target object of the salesperson 2 is the user D and the user E; if the salesperson 3 is currently related to a user F and has been related to a user G before, the target object of the salesperson 3 is the user F and the user G.
[0080] For each target rôle of each authorized field, the set of form data, any limited value of the target rôle of which is included by a field value of the authorized field in the form is gotten respectively, and the operation permission is authorized to the set. According to the setting of the target object in the example above, the salesperson 1 and the user A are defined as a first limited value, the salesperson 2 and the user D are defined as a first second value, the salesperson 2 and the user E are defined as a third limited value, the salesperson 3 and the user F are defined as a fourth limited value, and the salesperson 3 and the user G are defined as a fifth limited value. In this case, the operation permission is authorized to form data in which the field value of the creator in the contract form includes the first limited value (which may also be expressed as salesperson 1 (A)), the operation permission is authorized to form data in which the field value of the creator in the contract form includes the second limited value (which may also be expressed as salesperson 2 (D)) or the third limited value (which may also be expressed as salesperson 2 (E)), and the operation permission is authorized to form data in which the field value of the creator in the contract form includes the fourth limited value (which may also be expressed as salesperson 3 (F)) or the fifth limited value (which may also be expressed as salesperson 3 (G)). As shown in FIG. 6, a clerk 1 can view a contract created by salesperson 1(A) (if the user related to the rôle, such as the salesperson 1, changes from A to K, after the use has changed, the clerk 1 can automatically view a contract created by salesperson 1(K), and cannot view the contract created by salesperson 1(A), because after the rôle to which A is related has changed, A becomes a historical related rôle of the salesperson 1), the clerk 1 can view contracts created by salesperson 2(D) and salesperson 2(E), and the clerk 1 can modify contracts created by salesperson 3(F) and salesperson 3(G).
[0081] The operation permission includes one or more operations of viewing, modifying, adding, deleting and printing form data.
[0082] In another embodiment, the null option and the unrestricted option are displayed when ail rôles in the system are displayed; if the null option is selected, the operation permission is authorized to form data in which the field value of the authorized field in the form is null; if the unrestricted option is selected, the operation permission is authorized to form data in which the field value of the authorized field in the form is any value (including null). In the présent invention, the unrestricted option is set, and if the unrestricted option is selected, the operation permission is authorized to form data in which the field value of the authorized field in the form is any value, thus improving the efficiency of authorizing a grantee having the operation permissions of ail form data of the authorized field.
[0083] When there is one grantee, after a form is selected, the grantee's current form-operation permissions in the form are displayed.
[0084] [Embodiment 3] As shown in FIG. 9, an authorization method based on form data gotten by a rôle includes: selecting one or more grantees. The grantee includes one or more types of a person, a user, a group, a class, and a rôle. The rôle is an independent individual not a group/a 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.
[0085] The rôle belongs to a certain department, and the rôle is authorized according to the work content of the rôle; the name of the rôle is unique under the department, and the number of the rôle is unique in a System. The user détermines (obtains) permissions through its relation to the rôle, one employée corresponds to one user, and one user corresponds to one employée.
[0086] During cross-department transfer of the user, the user's relation to the rôle in the original department is canceled, and the user is related to a rôle in a new department. After the rôle is created, a user may be related to the rôle in the process of creating the user, or may be related to the rôle 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 the user and another rôle may be created at any time.
[0087] The form is selected, and the authorized field used for searching form data is displayed, where the authorized field is a field, the field value of which includes a rôle, where the rôle is an independent individual not a group/a 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.
[0088] Each authorized field is authorized respectively: ail rôles in a System are displayed, where the rôle is an independent individual not a group/a 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; the rôle that needs to be used for searching form data is defined as a target rôle, where one target rôle corresponds to one rôle; and for each target rôle of each authorized field, the set of form data, the target rôle of which is included by a field value of the authorized field in the form is gotten respectively, and the operation permission is authorized to the set. As shown in FIG. 10, the authorized field creator includes target rôles salesperson 1, salesperson 2, salesperson 3; the set of form data in which the creator is the salesperson 1 is gotten, and the viewing permission is authorized to the set; the set of form data in which the creator is the salesperson 2 is gotten, and the viewing permission is authorized to the set; the set of form data in which the creator is the salesperson 3 is gotten, and the modification permission is authorized to the set.
[0089] The operation permission includes one or more operations of viewing, 5 modifying, adding, deleting and printing form data.
[0090] 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 various other combinations, modifications and environments. Modification can be made by 10 the techniques or knowledge of the above teachings or related art within the scope of the teachings herein. AH changes and modifications made by those skilled in the art without departing from the spirit and scope of the présent invention are intended to be within the protection scope of the appended claims.
Claims (10)
1. An authorization method based on form data gotten by a rôle, comprising:
selecting one or more grantees;
selecting a form, and displaying an authorized field used for searching form data, wherein said authorized field is a field, the field value of which comprises a user or an employée;
authorizing each authorized field respectively: displaying ail rôles in a system, wherein said rôle is an independent individual not a group/a 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; defining a rôle that needs to be used for searching form data as a target rôle, wherein one target rôle corresponds to one rôle; selecting a target object for each target rôle respectively, wherein said target object is a current object, a historical object, or ail objects, said current object is a user currently related to the rôle or an employée corresponding to the user, said historical object is ail users who hâve been related to the rôle except the user currently related to the rôle or employées corresponding to the users, and said ail objects are ail users who hâve been related to the rôle or employées corresponding to the users; and for each target rôle of each authorized field, getting a set of form data, any user or employée of the target object of the target rôle of which is included by a field value of the authorized field in said form, respectively, and authorizing an operation permission to the set.
2. An authorization method based on form data gotten by a rôle, comprising:
selecting one or more grantees;
selecting a form, and displaying an authorized field used for searching form data, wherein said authorized field is a field, the field value of which comprises a rôle and a user, or a rôle and an employée;
authorizing each authorized field respectively: displaying ail rôles in a system, wherein said rôle is an independent individual not a group/a 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; defining a rôle that needs to be used for searching form data as a target rôle, wherein one target rôle corresponds to one rôle; selecting a target object for each target rôle respectively, wherein said target object is a current object, a historical object, or ail objects, said current object is a user currently related to the rôle or an employée corresponding to the user, said historical object is ail users who hâve been related to the rôle except the user currently related to the rôle or employées corresponding to the users, and said ail objects are ail users who hâve been related to the rôle or employées corresponding to the users; and defining a target rôle and a user or an employée in the target object of the target rôle as a limited value of the target rôle; and for each target rôle of each authorized field, getting a set of form data, any limited value of the target rôle of which is included by a field value of the authorized field in said form, respectively, and authorizing an operation permission to the set.
3. The rôle acquisition-based method for authorizing form data according to claim 2, wherein said operation permission comprises one or more operations of viewing, modifying, adding, deleting and printing form data.
4. The rôle acquisition-based method for authorizing form data according to claim 2, wherein said user détermines permissions through its relation to the rôle, one employée corresponds to one user, and one user corresponds to one employée.
5. The rôle acquisition-based method for authorizing form data according to claim 2, wherein said rôle belongs to a certain department, the rôle is authorized according to the work content of the rôle, the name of the rôle is unique under the department, and the number of the rôle is unique in the System.
6. The rôle acquisition-based method for authorizing form data according to claim 5, wherein during cross-department transfer of said user, the user's relation to the rôle in the original department is canceled, and the user is related to a rôle in a new department.
7. The rôle acquisition-based method for authorizing form data according to claim 2, wherein a null option is displayed when ail rôles in the System are displayed, and if the null option is selected, the operation permission is authorized to the form data in which the field value of the authorized field in said form is null.
8. The rôle acquisition-based method for authorizing form data according to claim 2, wherein an unrestricted option is displayed when ail rôles in the System are displayed, and if the unrestricted option is selected, the operation permission is authorized to the form data in which the field value of the authorized field in said form is any value.
9. The rôle acquisition-based method for authorizing form data according to claim 2, wherein said grantee comprises one or more types of a person, a user, a group, a class, and a rôle, said rôle is an independent individual not a group/a 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.
10. An authorization method based on form data gotten by a rôle, comprising:
selecting one or more grantees;
selecting a form, and displaying an authorized field used for searching form data, wherein said authorized field is a field, the field value of which comprises a rôle, said rôle is an independent individual not a group/a 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; and authorizing each authorized field respectively: displaying ail rôles in a System, wherein said rôle is an independent individual not a group/a 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; defining a rôle that needs to be used for searching form data as a target rôle, wherein one target rôle corresponds to one rôle; and for each target rôle of each authorized field, getting a set of form data, the target rôle of which is included by a field value of the authorized field in said form, respectively, and authorizing an operation permission to the set.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710571694.8 | 2017-07-13 |
Publications (1)
Publication Number | Publication Date |
---|---|
OA19448A true OA19448A (en) | 2020-09-18 |
Family
ID=
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11586758B2 (en) | Authorization method for form data acquired based on role | |
EP3633567A1 (en) | Method for setting up approval role according to department by approval node in workflow | |
AU2018258773A1 (en) | Workflow control method and system based on one-to-one correspondence between roles and users | |
EP3614283A1 (en) | Permission granting method and system based on one-to-one correspondence between roles and users | |
US11599656B2 (en) | Method for authorizing form data operation authority | |
US20200389463A1 (en) | Permission granting method and system based on one-to-one correspondence between roles and users | |
US11586747B2 (en) | Method for setting operating record viewing right based on time period | |
US11750616B2 (en) | Method for authorizing approval processes and approval nodes thereof for user | |
AU2018276969A1 (en) | Approval workflow entrusting and re-entrusting method | |
US11775687B2 (en) | Method for authorizing field value of form field by means of third party field | |
WO2018224023A1 (en) | Method for displaying permission after employee logs into account thereof in system | |
WO2018205940A1 (en) | Organizational structure chart generation method based on one-to-one correspondence between roles and users, and application method | |
US11824865B2 (en) | Method for authorizing authorization operator in system | |
EP3667539A1 (en) | Column value-based separate authorization method for statistical list operations | |
WO2019001322A1 (en) | Role-based menu authorization method | |
OA19448A (en) | Role acquisition-based method for authorizing form data. | |
EA044262B1 (en) | METHOD OF GRANTING RIGHTS WITH RESPECT TO FORM DATA OBTAINED BASED ON THE ROLE | |
OA19306A (en) | Workflow control method and system based on one-to-one correspondence between roles and users. |