EA044262B1 - METHOD OF GRANTING RIGHTS WITH RESPECT TO FORM DATA OBTAINED BASED ON THE ROLE - Google Patents

Description

Field of technology

The invention relates to a method for creating/granting rights over forms in administrative software systems such as ERP, and in particular it relates to a method for granting rights over role-derived form data.

BACKGROUND OF THE INVENTION

Role-based access control (RBAC) is one of the most studied and advanced database access control mechanisms in recent years. This mechanism is considered an ideal candidate to replace traditional mandatory access control (MAC) and selective access control (DAC) systems. The basic idea of role-based access control (RBAC) is to separate different roles according to different functional positions in the organizational view of an enterprise, encapsulate access rights to database resources in roles, and allow users to indirectly access database resources by assigning different roles for users.

Large-scale application systems often have a large number of tables and views built into them, making database resource management and provisioning significantly more complex. It is extremely difficult for the user to directly control the granting of rights and database resources. This requires the user to have a deep understanding of the database structure and knowledge of the SQL language. As application system design or security requirements change, a large number of complex and extensive rights changes are required, which is very likely to result in information security vulnerabilities caused by unexpected errors in the rights granted. Therefore, developing a simple and effective way to manage rights for large-scale application systems has become a common requirement for systems and system users.

The role-based access control mechanism allows you to easily and effectively manage system rights, which significantly reduces the burden and cost of system rights management, and also makes system rights management more compatible with the specific operational management of the application system.

However, traditional role-based user rights management and workflow management methods use a one-to-many role-to-user relationship mechanism, where the role represents a group/class. This means that one role can simultaneously correspond or be associated with many users, and the role is identical to the concepts of official position, position, work specialty, etc. In this communication mechanism, granting rights to users is mainly divided into three forms: 1. as shown in fig. 1, direct granting of rights to users, the disadvantage of which is the high workload, as well as the frequency and volume of operations; 2. As shown in Fig. 2, granting rights (one role can be associated with several users) to a role (with the properties of a class/group/position/job specialty) and the user acquires rights through the role; 3. As shown in Fig. 3, the above two methods are combined.

In descriptions 2 and 3 above, it is necessary to grant rights to a role with class/group properties. The method of granting rights and managing the workflow through a role with the properties of a class/group/position/work specialty has the following disadvantages:

1. Difficulties in performing operations if user rights change. During actual use of the system, user rights are subject to frequent changes. For example, in the process of changing rights, when the rights of an employee associated with a role have changed, it is inappropriate to change the rights of the entire role because the rights of an individual employee have changed, since the role is also associated with other employees whose rights have remained unchanged. As a result, you must either create a new role corresponding to the employee whose rights have been changed, or directly grant rights to the employee (removed from the role) based on the rights requirements. The above two processing methods not only take a long time, but also easily lead to errors in the granted rights of a role in case the role has a large number of rights. The user has to do a lot of work, resulting in errors that result in losses for the system user.

2. It is difficult to remember the specific rights contained in a role for a long time. If a role has a large functionality of rights, over time it is difficult to remember the specific rights of the role, and even more difficult to remember the differences in rights between roles with identical rights. If you need to associate a new user, it is impossible to determine exactly how to establish the association.

3. As user rights change, more roles are created (if new roles are not created, direct granting of rights to users increases significantly), and it becomes more difficult to distinguish specific rights differences between roles.

4. When transferring a user to another position and the need to assign a large number of rights of the transferred user to other users, it is necessary to separate the rights of the transferred user and create roles for communication with other users. Such operations are not only complex and time-consuming, but also error-prone.

In traditional field-based form data entitlement management,

- 1 044262 property of an employee, if there is a relatively large number of employees (for example, 500 employees), situations such as dismissal, taking on a position, transfer of employees, etc. continuously arise, which makes the operation of granting rights extremely complex, and is also associated with heavy workloads. In addition, changes must be made to the corresponding original entitlements when employees leave, reassign, or transfer, resulting in enormous entitlement workloads, complexity, and errors.

In traditional form data entitlement management based on a user property field, since the traditional system does not establish a fixed one-to-one relationship between users and employees, it is possible for multiple employees to log in as one user. When saving form data, the value of the user property field can only be recorded as a user, but it is impossible to distinguish whether the corresponding user's employee is Zhang San or Li Si, which makes it difficult to clearly and accurately identify the user's corresponding employee who performed the operation when viewing the data later.

In the traditional entitlement method, dynamic entitlement cannot be performed solely to view the related work activity of current employees/users with certain job numbers, without being able to view the related work activity of previous employees/users with those job numbers; or, conversely, dynamic entitlement may be performed solely to view the related work activity of previous employees/users with certain job numbers, without the ability to view the related work activity of current employees/users with those job numbers.

Brief description of the invention

Technical problem

It is an object of the present invention to overcome the shortcomings of the prior art and to provide a method for granting rights to role-derived form data to enable dynamic granting of rights to form data so that the corresponding rights of leaving or transferring employees are automatically adjusted. to another position and incoming employees, thereby reducing the workload of entitlement operations and the likelihood of errors.

Technical solutions

The problem of the present invention is solved by the following technical solutions:

a method for granting rights to role-derived form data, comprising:

(1) selection of one or more authorized objects;

(2) selecting a form and displaying an authorized field used to search the form data, wherein said authorized field is a field whose value includes a user or employee;

(3) separate grant of rights for each authorized field:

display all roles in the system, wherein the specified role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user is associated with one or more roles; defining a role used to search the form data as a target role, wherein one target role corresponds to one role; separately selecting a target object for each target role, wherein said target object is the current object, previous objects, or all objects; said current object represents the currently associated user or user-matched employee, said previous objects represents all role-associated users or user-matched employees excluding the currently associated user, and said all objects represent all associated the role of users or employees corresponding to users;

(4) for each target role of each authorizable field, separately obtaining the data set of a specific authorizable field value in a specified form and effecting the granting of rights to operate on the resulting data set, the authorizable field value including any user or employee in the target object of that target role.

Steps (2), (3) and (4) are performed sequentially, and step (1) is performed either before step (2), or between steps (2) and (3), or between steps (3) and (4), or after step (4).

A method for granting rights to role-derived form data, comprising:

(1) selection of one or more authorized objects;

(2) selecting a form and displaying an authorized field used to search the form data, wherein said authorized field is a field whose value includes a role and a user or a role and an employee;

- 2 044262 (3) separate grant of rights in relation to each authorized field:

display all roles in the system, wherein the specified role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user is associated with one or more roles; defining a role used to search the form data as a target role, wherein one target role corresponds to one role; separately selecting a target object for each target role, wherein said target object is the current object, previous objects, or all objects; said current object represents the currently associated user or user-matched employee, said previous objects represents all role-associated users or user-matched employees excluding the currently associated user, and said all objects represent all associated the role of users or employees corresponding to users; defining a target role and a user or employee in the target object of this target role as a limit value of the target role;

(4) for each target role of each authorizable field, separately obtaining the data set of a specific value of the authorizable field in a specified form and granting rights to operations in relation to the received data set, wherein the value of the authorizable field includes any limit value of that target role.

Steps (2), (3) and (4) are performed sequentially, and step (1) is performed either before step (2), or between steps (2) and (3), or between steps (3) and (4), or after step (4).

Preferably, said operation rights include one or more of the operations of viewing, modifying, adding, deleting, and printing form data.

Preferably, said user defines (acquires) rights through his association with a role, one employee corresponds to one user and one user corresponds to one employee.

Preferably, the specified role relates to a specific department, rights are granted to the role in accordance with the job responsibilities of the role, the role name is unique within the department and the role number is unique in the system.

Preferably, when the specified user is transferred to another department, the user's association with the role in the previous department is removed and the user is associated with the role in the new department.

Preferably, when displaying all roles in the system, there is an empty value option, and if the empty value option is selected, then rights to operate on data in the specified form are granted with an empty value of the authorized field.

Preferably, when displaying all roles in the system, there is an option without restrictions, and if the option without restrictions is selected, then rights to operate on data in the specified form are granted with any value of the authorized field.

Preferably, said authorizable entity is one or more of a person, a user, a group, a class, and a role; a specified role is a single entity rather than a group/class, and one role can only be associated with one user at a time, while one user can be associated with one or more roles.

A method for granting rights to role-derived form data, comprising:

(1) selection of one or more authorized objects;

(2) selecting a form and displaying an authorized field used to search the form data, wherein said authorized field is a field whose value includes a role; the specified role is a separate entity, not a group/class, and at the same time one role can be associated with only one user, while one user is associated with one or more roles;

(3) separate grant of rights for each authorized field:

display all roles in the system, wherein the specified role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user is associated with one or more roles; defining a role used to search the form data as a target role, wherein one target role corresponds to one role; for each target role of each authorized field, a set of data of a specific value of the authorized field is separately obtained in the specified form and rights to operations are granted for the obtained set of data, while the value of the authorized field includes this target role.

Steps (2) and (3) are performed sequentially, and step (1) is performed either before step (2), or between steps (2) and (3), or after step (3).

Positive effects

The present invention has the following beneficial effects.

(1) The present invention enables dynamic granting of rights to form data, allowing the corresponding rights of leaving, transferring, and incoming employees to be automatically adjusted, thereby reducing the cost of

- 3 044262 sideload of entitlement operations and the possibility of errors.

For example, head 1 of sales department 1 is granted rights to view (view by reporting person) the personal reporting sheet of an employee currently corresponding to a certain position number in this department. If the currently associated employee Zhang San is replaced by Li Si, then Manager 1 can automatically only view the report sheet of the last employee associated with the position number, Li Si (the reporting person is Li Si), and automatically cannot view the report sheet of the originally associated employee. Zhang San's employee position number (reporting person is Zhang San). Or, for example, the head of the 1st administrative and economic activity of the company is granted the rights only to view (view by accountable person) the personal reporting sheet of previous employees associated with a certain position number, in order to conduct an appropriate analysis of all employees (with the exception of the currently associated employee), that were associated with this job number. If Zhang San's currently associated job number ceases to perform a work activity with that job number (Zhang San's association with that job number/role is deleted), then Operations Manager 1 can automatically view Zhang San's report sheet and perform appropriate analysis. . Or, for example, the general director of 1 company is granted the rights to view (view by reporting person) the reporting sheet of all employees associated with a certain position number. If the currently associated employee Zhang San is replaced by Li Si, then General Manager 1 can automatically view both Li Si's and Zhang San's reporting statements.

The traditional way of entitlement is complex and does not allow for shared entitlement of data corresponding to the current employee of the job number, the past employee of the job number, or all employees of the job number, let alone automatic dynamism. The present invention makes it possible to easily and quickly provide collective entitlement through a model with the current object, previous objects and all objects, and also allows the implementation of an automatic dynamic matching function.

(2) In the present invention, a role is a single entity rather than a group/class, and one role can only be associated with one user at a time, while one user is associated with one or more roles, one user is associated with one employee and one employee is associated with one user. During the functioning of an enterprise or institution, the role rarely changes, and even remains unchanged for a relatively long period of time. In the event of an employee leaving, transferring, or joining a position, entitlement can be accomplished by deleting the association with the relevant role or associating it with a new role. The operation of granting rights is simple, convenient and highly efficient, which greatly improves the efficiency of granting rights.

(3) In the present invention, the form data on which access rights are granted are obtained by a role and a role-associated user or a role and an employee that corresponds to a role-associated user, which allows the rights to be effectively differentiated at the time of granting rights on the form data. associated with various employee responsibilities. For example, Zhang San is currently associated with Role 1 in the Aviation Department and Role 2 in the Home Appliances Department. It is necessary to grant the head of the 1st department of household appliances the rights to view contract forms for household appliances of employee Zhang San, and the field of the person who signed the contract is selected as the authorized field. If manager 1's entitlement is done according to the traditional employee-based entitlement method, and the signatory field value is Zhang San, then home appliance department manager 1 can view all the home appliance contracts and all the aircraft contracts signed by Zhang San. As a result, the head of the 1st Home Appliances Department can view the aircraft contracts signed by Zhang San, which leads to leakage of information about the aircraft contracts. If the granting of rights to the head of the home appliance department 1 is carried out using the method according to the present invention, and the value of the signatory field is Zhang San (role 2), then the head of the home appliance department 1 can only view the home appliance contracts signed by Zhang San (role 2). , but cannot view the aircraft contracts signed by Zhang San (role 1). In this way, detailed management is implemented and the company’s information security is ensured.

(4) In the traditional rights management mechanism, a role is characterized as a property of a group, work specialty, class, etc. A role is associated with a user on a one-to-many basis. During actual use of the system, user rights are subject to frequent changes. For example, in the process of changing rights, when the rights of an employee associated with a role have changed, it is inappropriate to change the rights of the entire role because the rights of an individual employee have changed, since the role is also associated with other employees whose rights have remained unchanged. As a result

- 4 044262 you must either create a new role corresponding to the employee whose rights have been changed, or directly grant rights to the employee (excluded from the role) based on the rights requirements. The above two processing methods not only take a long time, but also easily lead to errors in the rights granted to the role in case the role has a large number of rights. The user has to do a lot of work, resulting in errors that result in losses for the system user.

However, according to the method of this application, since a role is a separate entity, the goal can be achieved by changing the rights of that role. Although the method in this application is likely to increase the workload during system initialization through copying and the like, however, creating and granting role rights can be done more efficiently than in the case of traditional roles with the group property . Since there is no need to consider the commonality of roles with the group property when associating users, the solutions provided in this application make setting up rights clear and understandable. Especially after the system has been used for a certain period of time (after dynamically changing user rights/roles), the solutions provided in this application can greatly improve the efficiency of rights management for system users, making dynamic rights provision simpler, more convenient, clearer and understandable, and also improve the efficiency and reliability of setting rights.

(5) The traditional way of granting rights based on a role with a group property is error prone. The method provided in this application significantly reduces the likelihood of errors in the rights granted, since in the method of this application the role is considered only as a separate entity, without taking into account the commonality of several users associated with the role with the group property in the traditional way. If errors are detected in the granted rights, only the user associated with the role is affected, but in the case of a traditional role with a group property, all users associated with the role are affected. Even if errors are found in the granted rights, the correction method according to this application is simple and takes a short period of time, while in the case of a traditional role with a group property, the commonality of rights of all users associated with the role must be taken into account when correcting errors. If a role has large functionality, the fix is large, complex, and error-prone, and in many cases the problem cannot be resolved until a new role is created.

(6) In the traditional way of granting rights to a role with a group property, if the role has a large functionality of rights, over time it is difficult to remember the specific rights of the role, and it is even more difficult to remember the differences in rights of different roles with identical rights. If you need to associate a new user, it is impossible to determine exactly how to establish the association. In this application method, the role itself is the job number/workstation number, making selection much easier.

(7) When transferring a user to another position and need to assign a large number of rights of the transferred user to other users, it is necessary to separate the rights of the transferred user and create roles for communication with other users. Such operations are not only complex and time-consuming, but also error-prone.

The method in this application is as follows: the transferred user is associated with multiple roles. When you transfer a user, you first remove the association between the user and the roles in the previous department (unlinked roles can be reassociated with other users), and then associate the user with the role in the new department. The operation is simple and error-free.

(8) The role belongs to a specific department and the department to which the role belongs cannot be changed. The reasons why the department to which a role belongs cannot be changed are as follows. Reason 1: Because the role in this requisition is essentially a workstation number/job number, different workstation numbers/job numbers have different job content or rights. For example, sales role 1 in the sales department and developer role 1 in the technical department are two completely different workstation numbers/position numbers and they have different rights. Reason 2: If the department (sales department) to which the salesperson 1 role belongs is replaced by the technical department without changing the rights of the salesperson 1 role, then a role exists in the technical department with rights related to the sales department. This leads to management confusion and security vulnerabilities.

Description of the attached graphic materials

In fig. 1 is a schematic illustration of direct granting of rights to a user in a system according to the prior art.

In fig. 2 is a schematic representation of granting rights to a role with group/class properties in a system according to the prior art;

In fig. 3 is a schematic representation of direct granting of rights to both a user and a role with group/class properties in a prior art system.

In fig. 4 is a flow chart of one embodiment of the present invention.

In fig. 5 is a schematic illustration of granting rights to a user in a system through a role with a separate entity property according to the present invention.

- 5 044262

In fig. 6 is a schematic diagram of a mold according to the present invention.

In fig. 7 is a flowchart according to another embodiment of the present invention.

In fig. Figure 8 shows a schematic representation of the form with the title marked.

In fig. 9 is a flowchart according to another embodiment of the present invention.

In fig. 10 is a schematic representation of the form when selecting a role for granting rights.

Embodiments of the Invention

Below, the technical solutions according to the present invention are described in more detail with reference to the accompanying drawings, however, the scope of protection of the present invention is not limited to the following.

Embodiment 1 As shown in FIG. 4, a method for granting rights to role-derived form data includes: selecting one or more authorized objects. The specified authorizable entity is one or more of a person, a user, a group, a class, and a role.

As shown in FIG. 5, a role is a single entity rather than a group/class, and one role can only be associated with one user at a time, while one user can be associated with one or more roles.

The role belongs to a specific department, the rights of the role are granted in accordance with the job responsibilities of the role, the name of the role is unique within the department and the role number is unique in the system. A user defines (acquires) rights through his association with a role, one employee corresponds to one user, and one user corresponds to one employee.

Definition of a role: a role is characterized not by the properties of a group/class/category/position/official position/work specialty, etc., but only by the property of the absence of collectivity, the role is characterized by uniqueness, and the role is a separate entity that exists independently. Applied in an enterprise or institution, the role is identical to the position number (in this case, the position number is not a position; one position can simultaneously have several employees, but one position number in the same period can correspond to only one employee).

For example, the following roles can be created in the company's system: General Director, Deputy General Director 1, Deputy General Director 2, Beijing Sales Manager I, Beijing Sales Manager 2, Beijing Sales Manager 3, Shanghai Sales Engineer 1, Shanghai Engineer Sales Engineer 2, Shanghai Sales Engineer 3, Shanghai Sales Engineer 4, Shanghai Sales Engineer 5, etc. The relationship between users and roles is as follows: if a company employee Zhang San acts as Deputy General Manager 2 and then At the same time, he acts as the manager of Beijing Sales Department 1, then Zhang San should be associated with the role of deputy general manager 2 and the role of manager of Beijing Sales Department 1, that is, Zhang San has the rights of two roles.

The concept of traditional roles is characterized by the properties of a group/class/position/position/job specialty, and one role can correspond to several users. However, in this application, the concept of a role corresponds to a position number/job number, and is also similar to a role in films and television series: one role (in childhood, adolescence, adulthood, etc.) can only be performed by one actor at a time, but one actor can perform multiple roles.

When a user is transferred to another department, the user's association with a role in the previous department is removed and the user is associated with a role in the new department. Once a role is created, a user can be associated with the role during the user creation process, or can be associated with a role at any time after the user is created. Once a user is associated with a role, the user can be unassociated from the role at any time, and an association between the user and another role can be created at any time.

A form is selected and an authorized field used to search the form data is displayed, where the specified authorized field is a field whose value includes the user or employee. As shown in FIG. 6, authorization field - creator.

Rights in relation to each authorized field are provided separately: they display all roles in the system, while the role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user is associated with one or more roles; the role used to search for form data is defined as a target role, with one target role corresponding to one role (for example, if 5 roles need to be used to search for form data, then there are 5 target roles); separately selecting a target object for each target role, wherein the target object is the current object, previous objects, or all objects; the specified current object represents in

- 6 044262 currently associated with the role of the user or the employee corresponding to the user, the specified previous objects represent all associated users or the employee associated with the user except the currently associated user, and the specified all objects represent all associated users or employees employees corresponding to the users.

As shown in FIG. 6, the current object is selected as the target object for salesman 1 (role), previous objects are selected as targets for salesman 2 (role), and all objects are selected as targets for salesman 3 (role). If Merchant 1 is currently associated with User A and was previously associated with User B, then Merchant 1's target is User A; If Merchant 2 is currently associated with User C and was previously associated with User D and User E, then Merchant 2's targets are User D and User E; If seller 3 is currently associated with user F and was previously associated with user G, then seller 3's targets are user F and user G.

For each target role of each authorized field, a set of data of a specific value of the authorized field is separately obtained in the specified form and rights to operations are granted in relation to the obtained set of data, wherein the value of the authorized field includes any user or employee in the target object of this target role. According to the target object setup in the example above, granting operation rights is performed on form data whose creator field value in the contract form includes user A; granting rights to operations is performed in relation to form data, the value of the creator field in the contract form of which includes user D and user E; and the granting of rights to operations is performed in relation to the form data, the value of the creator field in the contract form of which includes user F and user G.

Operation rights include one or more of the operations to view, edit, add, delete, and print form data.

Embodiment 2 As shown in FIG. 7, a method for granting rights with respect to role-derived form data includes: selecting one or more authorized objects. An authorized entity is one or more of a person, a user, a group, a class, and a role; a specified role is a single entity rather than a group/class, and one role can only be associated with one user at a time, while one user can be associated with one or more roles.

The role belongs to a specific department, the rights of the role are granted in accordance with the job responsibilities of the role, the name of the role is unique within the department and the role number is unique in the system. A user defines (acquires) rights through his association with a role, one employee corresponds to one user, and one user corresponds to one employee.

When a user is transferred to another department, the user's association with the role in the previous department is canceled and the user is associated with the role in the new department. Once a role is created, a user can be associated with the role during the user creation process, or can be associated with a role at any time after the user is created. Once a user is associated with a role, the user can be unassociated from the role at any time, and an association between the user and another role can be created at any time.

A form is selected and an authorized field used to search for form data is displayed, wherein the specified authorized field is a field whose value includes a role and a user or a role and an employee; that is, an authorized field can be a field whose value includes a role and a user, and an authorized field can also be a field whose value includes a role and an employee.

Rights are granted separately in relation to each authorized field: they display all roles in the system, while the role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user is associated with one or more roles; the role used to search for form data is defined as a target role, with one target role corresponding to one role (for example, if 5 roles need to be used to search for form data, then there are 5 target roles); separately selecting a target object for each target role, wherein the target object is the current object, previous objects, or all objects; said current object represents the currently associated user or user-matched employee, said previous objects represents all role-associated users or user-matched employees excluding the currently associated user, and said all objects represent all associated the role of users or employees corresponding to users; the target role and the user or employee in the target of that target role are defined as the limit value of that target role, and if the target of that target role includes multiple users or employees, then the target role and the users/employees in the target of that target role are defined as multiple limit values 7 044262.

For example, the target of target role A includes three users: user 1, user 2 and user 3. In such a case, target role A and user 1 constitute the limit target role A (user 1), target role A and user 2 constitute the limit target role A (user 2), and target role A and user 3 constitute the limit value of target role A (user 3).

When selecting a target object for a role, if the column name of any of the current object, previous objects and all objects is selected (for example, in Fig. 8 the current object is selected), then the target objects of all roles (including roles added subsequently) are the objects corresponding to the selected column name (one of the types of the current object, previous objects and all objects). For example, in FIG. 8, the column name is selected as the current object, and the target objects are the current objects corresponding to seller 1, seller 2, seller 3, etc. When all the roles of the authorized field (including roles added subsequently) are target roles, and the targets of these target roles have the same type (that is, all target objects are the current object, previous objects or all objects), one-step selection can be realized by selecting the corresponding column name (selecting a column name is a kind of manifestation form, the essence of this manifestation can also be achieved other means), which significantly reduces the workload of selecting targets for target roles and improves the efficiency of the entitlement operation.

As shown in FIG. 6, the current object is selected as the target for salesman 1 (role), the previous objects are selected as targets for salesman 2 (role), and all objects are selected as targets for salesman 3 (role). If Merchant 1 is currently associated with User A and was previously associated with User B, then Merchant 1's target is User A; If Merchant 2 is currently associated with User C and was previously associated with User D and User E, then Merchant 2's targets are User D and User E; if Merchant 3 is currently associated with User F and was previously associated with User G, then Merchant 3's targets are User F and User G. Merchant 1 and User A, Merchant 2 and User D, Merchant 2 and User E, Merchant 3 and user F as well as salesperson 3 and user G constitute the limit value of the corresponding target role.

For each target role of each authorized field, a set of data of a specific value of the authorized field is separately obtained in the specified form and rights to operations are granted for the resulting set of data, wherein the value of the authorized field includes any limit value of this target role. According to the target setup in the example above, Merchant 1 and User A make up the first limit, Merchant 2 and User D make up the second limit, Merchant 2 and User E make up the third limit, Merchant 3 and User F make up the fourth limit , seller 3 and user G constitute the fourth limit value. In such a case, the grant of transaction rights is performed on the form data in which the value of the creator field in the contract form includes the first limit value (can also be expressed as seller 1 (A)); granting transaction rights is performed on form data in which the value of the creator field on the contract form includes a second limit value (can also be expressed as seller 2 (D)) or a third limit value (can also be expressed as seller 2 (E)) ; and the grant of transaction rights is performed on the form data in which the value of the creator field in the contract form includes a fourth limit value (also expressed as seller 3 (F)) or a fifth limit value (also expressed as seller 3 (G) ). As shown in FIG. 6, clerk 1 can view contracts created by salesman 1 (A) (if the user associated with the role salesman 1 changes from A to K, then after the change, clerk 1 can automatically view contracts created by salesman 1 (K), and cannot view contracts created by salesperson 1 (A) because after changing the associated role of user A, A becomes the previous associated user of seller 1), clerk 1 can view contracts created by salesperson 2 (D) and salesperson 2 (E) , and also clerk 1 can change contracts created by seller 3 (F) and seller 3 (G).

Operation rights include one or more of the operations to view, edit, add, delete, and print form data.

In yet another embodiment, when displaying all roles in the system, a blank option and an unrestricted option are present; if the empty value option is selected, then granting rights to operate on data in the specified form with an empty value of the authorized field; if the option without restrictions is selected, then rights to operate on data in the specified form are granted with any value (including an empty value) of the authorized field. In the present invention, it is possible to set the option without restrictions, and if the option without restrictions is selected, then the granting of rights to operate on data in the specified form with any value of the authorized field is performed, which improves the efficiency of granting rights to the authorized object having

- 8 044262 rights to operate with all form data of the specified authorized field.

If there is one authorized object, after selecting a form, the current rights to operate with the form of this authorized person are displayed.

Embodiment 3 As shown in FIG. 9, a method for granting rights with respect to role-derived form data includes: selecting one or more authorized objects. An authorized entity is one or more of a person, a user, a group, a class, and a role; a specified role is a single entity rather than a group/class, and one role can only be associated with one user at a time, while one user can be associated with one or more roles.

The role belongs to a specific department, the rights of the role are granted in accordance with the job responsibilities of the role, the name of the role is unique within the department and the role number is unique in the system. A user defines (acquires) rights through his association with a role, one employee corresponds to one user, and one user corresponds to one employee.

When a user is transferred to another department, the user's association with a role in the previous department is removed and the user is associated with a role in the new department. Once a role is created, a user can be associated with the role during the user creation process, or can be associated with a role at any time after the user is created. Once a user is associated with a role, the user can be unassociated from the role at any time, and an association between the user and another role can be created at any time.

Selecting a form and displaying an authorized field used to search the form data, wherein said authorized field is a field whose value includes a role, wherein said role represents a single entity rather than a group/class, and one role can be associated in the same period with only one user, whereas one user is associated with one or more roles.

Rights are granted separately in relation to each authorized field: they display all roles in the system, while the specified role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user associated with one or more roles.; the role used to search the form data is defined as a target role, with one target role corresponding to one role; for each target role of each authorized field, a set of data of a specific value of the authorized field is separately obtained in the specified form and rights to operations are granted in relation to the received set of data, while the value of the authorized field includes this target role. As shown in FIG. 10, the authorized field creator includes the target roles seller 1, seller 2, seller 3; receiving a set of data from a form, the creator of which is seller 1, and granting viewing rights in relation to the received set of data; receiving a set of data from a form, the creator of which is seller 2, and granting viewing rights in relation to the received set of data; receiving a set of data from a form, the creator of which is the seller 3, and granting rights to change in relation to the received set of data.

Operation rights include one or more of the operations to view, edit, add, delete, and print form data.

The above are only preferred embodiments of the present invention, and it should be understood that the present invention is not at all limited to the embodiments disclosed herein, which should not be construed as exclusive of other embodiments, but can be applied to any other combinations, variations and environments, Therefore, without deviating from the discussed essence of the present invention, changes can be made to it based on the above ideas or technologies or knowledge from related fields. Moreover, unless there is a departure from the spirit and scope of the present invention, changes and modifications suggested by those skilled in the art are intended to be within the scope of protection of the present invention as defined by the appended claims.

-

Claims (7)

CLAIM 1. A method for granting rights in relation to form data obtained based on a role, characterized in that it includes: selecting one or more authorized objects; selecting a form and displaying an authorized field used to search the form data, wherein said authorized field is a field whose value includes a user or employee; separate grant of rights in relation to each authorized field: display all roles in the system, while the specified role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user associated with one or more roles; defining a role used to search the form data as a target role, wherein one target role corresponds to one role; separately selecting a target object for each target role, wherein said target object is the current object, previous objects, or all objects; said current object represents the currently associated user or user-matched employee, said previous objects represents all role-associated users or user-matched employees excluding the currently associated user, and said all objects represent all associated the role of users or employees corresponding to users; for each target role of each authorizable field, separately obtaining a data set of a specific authorizable field value in a specified form and granting rights to operate on the resulting data set, wherein the authorization field value includes any user or employee in the target object of that target role. 2. A method for granting rights in relation to form data obtained based on a role, characterized in that it includes: selecting one or more authorized objects; selecting a form and displaying an authorized field used for searching form data, wherein said authorized field is a field whose value includes a role and a user or a role and an employee; separate grant of rights in relation to each authorized field: display all roles in the system, while the specified role represents a separate entity, and not a group/class, and in the same period one role can be associated with only one user, while one user associated with one or more roles; defining a role used to search the form data as a target role, wherein one target role corresponds to one role; separately selecting a target object for each target role, wherein said target object is the current object, previous objects, or all objects; said current object represents the currently associated user or user-matched employee, said previous objects represents all role-associated users or user-matched employees excluding the currently associated user, and said all objects represent all associated the role of users or employees corresponding to users; defining a target role and a user or employee in the target object of this target role as a limit value of the target role; for each target role of each authorized field, separately obtaining a set of data of a specific value of the authorized field in the specified form and granting rights to operations in relation to the received set of data, wherein the value of the authorized field includes any limit value of this target role. 3. The method for granting rights with respect to role-derived form data according to claim 2, wherein said operation rights include one or more operations of viewing, modifying, adding, deleting and printing form data. 4. The method for granting rights with respect to role-derived form data according to claim 2, wherein said user defines rights through his association with the role, one employee corresponds to one user and one user corresponds to one employee. 5. A method for granting rights in relation to form data obtained based on a role according to claim 2, characterized in that the specified role relates to a specific department, the rights are granted to the role in accordance with the job responsibilities of the role, the name of the role is unique within the department and the role number is the only one in the system. 6. The method for granting rights in relation to form data obtained based on a role according to claim 5, characterized in that when the specified user is transferred to another department, the user’s association with the role in the previous department is deleted and the user is associated with the role in the new department. 7. The method of granting rights in relation to the form data obtained based on the role according to claim 2, from - -