Authority control method and device, electronic equipment, storage medium and program product

Abstract

The invention discloses an authority control method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of authority management.The method comprises the steps that when a selection instruction for a target menu submitted by a target user is received, role information corresponding to the target user is determined based on an identifier of the target user; obtaining a first data rule and a first operation rule based on the selection instruction and the role information, and generating a data list interface according to the first data rule and the first operation rule; when an operation instruction of a target user for any target data in the data list interface is received, obtaining a second data rule and a second operation rule based on the operation instruction and the role information, and generating a form interface according to the second data rule and the second operation rule, and enabling the target user to operate each element in the target data on the form interface. By adopting the scheme, dynamic authority control and refined authority management can be realized.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of permission management, and particularly relate to a permission control method and device, an electronic device, a storage medium, and a program product. BACKGROUND

[0002] In a business system of an enterprise, a user can access resources by permission management. A traditional system permission management usually adopts an RBAC (Role-Based Access Control) permission management system. In the RBAC permission management system, a system determines a permission range according to a role assigned to a user.

[0003] However, the RBAC permission management system depends on a static permission assignment scheme. The static permission assignment scheme often lacks flexibility and lacks data constraints, which leads to an inability to flexibly manage data access permissions in a rapidly changing business environment and an inability to meet the needs of enterprises for fine business management. SUMMARY

[0004] Embodiments of the present application provide a permission control method and device, an electronic device, a storage medium, and a program product, which can realize dynamic permission control and fine permission management.

[0005] In a first aspect, embodiments of the present application provide a permission control method, which includes: when a selection instruction submitted by a target user for a target menu is received, determining role information corresponding to the target user based on an identifier of the target user, the target menu being a menu for which the target user has access permission; obtaining a first data rule and a first operation rule based on the selection instruction and the role information, to generate a data list interface according to the first data rule and the first operation rule, the data list interface containing permission data for which the target user has operation permission; when an operation instruction of the target user for any target data in the data list interface is received, obtaining a second data rule and a second operation rule based on the operation instruction and the role information, and generating a form interface according to the second data rule and the second operation rule, to enable the target user to operate each element in the target data in the form interface.

[0006] Optionally, before the role information corresponding to the target user is determined based on the identifier of the target user, the method further includes: obtaining the role information corresponding to the target user, to query a menu permission rule associated with the role information according to the role information; generating an application interface according to the menu permission rule, to enable the target user to select the target menu in the application interface, the application interface containing one or more menus for which the target user has access permission.

[0007] Optionally, obtaining the role information corresponding to the target user includes: obtaining the target user's identifier based on the target user's login information, querying the user group associated with the target user based on the identifier; and determining the target user's role information based on the mapping relationship between user groups and role information.

[0008] Optionally, obtaining first data rules and first operation rules based on selection instructions and role information, and generating a data list interface based on the first data rules and first operation rules, includes: determining a target menu based on selection instructions, querying the first data rules and first operation rules based on the target menu and role information; obtaining permission data based on the first data rules; and obtaining the target user's first operation permissions for the permission data based on the first operation rules, and generating a data list interface based on the permission data and first operation permissions.

[0009] Optionally, obtaining second data rules and second operation rules based on operation instructions and role information, and generating a form interface based on the second data rules and second operation rules, includes: determining target data based on operation instructions, querying second data rules and second operation rules based on target data and role information; obtaining each element in the target data based on the second data rules, and obtaining the target user's second operation permissions for each element based on the second operation rules, so as to generate a form interface based on each element in the target data and the second operation permissions.

[0010] Optionally, before obtaining the role information corresponding to the target user, the method further includes: assigning the target user to the corresponding user group, with the user group associated with the role information; setting constraint rules associated with the role information, the constraint rules including at least one of the following: menu permission rules, data constraint rules, permission point constraint rules, main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules.

[0011] Optionally, the first data rule includes data constraint rules, and the first operation rule includes permission point constraint rules; the second data rule includes main table field constraint rules, panel constraint rules, and sub-table field constraint rules, and the second operation rule includes main table field operation rules and sub-table field operation rules.

[0012] Optionally, constraint rules associated with role information can be set, including setting constraint rules associated with role information based on business nodes in the business process.

[0013] Secondly, embodiments of this application provide an access control device, comprising: an information determination module, configured to, upon receiving a selection instruction submitted by a target user for a target menu, determine the role information corresponding to the target user based on the target user's identifier, wherein the target menu is a menu for which the target user has access permissions; a first access control module, configured to, based on the selection instruction and role information, acquire a first data rule and a first operation rule, thereby generating a data list interface according to the first data rule and the first operation rule, wherein the data list interface contains access data for which the target user has operation permissions; and a second access control module, configured to, upon receiving an operation instruction from the target user for any target data in the data list interface, acquire a second data rule and a second operation rule based on the operation instruction and role information, and generate a form interface according to the second data rule and the second operation rule, thereby enabling the target user to operate on various elements in the target data in the form interface.

[0014] Optionally, it also includes: a user assignment module, used to assign target users to corresponding user groups, where user groups are associated with role information; and a rule configuration module, used to set constraint rules associated with role information, where constraint rules include at least one of the following: menu permission rules, data constraint rules, permission point constraint rules, main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules.

[0015] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory storing program instructions, wherein the processor is configured to execute the access control method described above when running the program instructions.

[0016] Fourthly, embodiments of this application provide a storage medium storing program instructions, wherein the program instructions, when executed, perform the access control method described above.

[0017] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements the access control method described above.

[0018] The access control method provided in this application, when receiving a selection instruction from a target user for a target menu, determines the corresponding role information based on the target user identifier. Then, based on the selection instruction and role information, it obtains a first data rule and a first operation rule, generating a data list interface containing access control data. When receiving an operation instruction from the target user for target data in the data list interface, it obtains a second data rule and a second operation rule based on the operation instruction and role information, thereby generating a form interface to allow the target user to operate on various elements of the target data. Using this approach, whenever a user's relevant instruction is received, the electronic device obtains the corresponding data rules and operation rules based on the user's instruction and role information, enabling dynamic access control even in changing business environments. Furthermore, this application employs a method that combines operation rules and data rules for access control, achieving refined access control. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of an access control method provided in an embodiment of this application; Figure 2 This is another flowchart of the access control method provided in the embodiments of this application; Figure 3 This is a schematic diagram of role rule configuration provided in an embodiment of this application; Figure 4 This is a schematic diagram of an access control device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0022] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0023] In the following description, when referring to the accompanying drawings, the same numbers in different drawings denote the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0024] In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0025] RBAC (Role-Based Access Control) is an access control mechanism that manages permissions through role assignment. It controls access to system resources by binding users or user groups to specific roles. Roles are the unit and carrier of permission assignment, and a role contains one or more permissions. By assigning a role to a user, the user obtains the permissions of that role.

[0026] Traditional system access control typically employs a Restricted Access Control (RBAC) system. In an RBAC system, the system determines a user's access permissions based on their assigned role. However, RBAC systems rely on static permission allocation schemes, which often lack flexibility and data constraints. This makes it difficult to manage data access permissions flexibly in rapidly changing business environments and fails to meet the needs of enterprises for refined business management.

[0027] Based on this, embodiments of this application provide an access control method, apparatus, electronic device, storage medium, and program product. Whenever an instruction from a target user is received, corresponding data rules and operation rules are obtained based on the target user's instruction and role information to achieve dynamic access control. Simultaneously, the operation rules and data rules are combined for access control, achieving refined access management.

[0028] The subject of this application is an electronic device, such as a laptop, desktop computer, mobile phone, or tablet computer, and the embodiments of this application are not limited thereto. A permission management system is deployed on the electronic device, and this permission management system is mounted on a Low-Code Development Platform (LCDP). The Low-Code Platform provides a permission management interface, allowing administrators or business personnel to define user role information and configure corresponding constraint rules for roles through drag-and-drop and point-and-click methods in a graphical permission management interface.

[0029] The electronic device also has a display screen for displaying various operation interfaces in the permission management system, such as permission management interface, workbench interface, application interface, data list interface, form interface, etc.

[0030] The permission control method of this application embodiment will now be described in detail. For example, please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an access control method provided in an embodiment of this application. The executing entity of this embodiment is an electronic device, and this embodiment includes: S101: When a selection instruction for a target menu is received from a target user, the role information corresponding to the target user is determined based on the target user's identifier, and the target menu is a menu that the target user has access to.

[0031] In this embodiment, one or more menus that a specific user (i.e., the target user) has access to are displayed in the application interface that the target user can operate. When the target user selects a menu (referred to as the target menu for ease of description) from one or more menus in the application interface, the electronic device receives a selection instruction for the target menu submitted by the target user. At this time, the electronic device obtains the target user's identifier to determine the role information corresponding to the target user. Different users have different identifiers; for example, the target user's identifier can be a username, user ID, employee number, or other unique identity credentials. The target user's role information is used to represent the role corresponding to the target user; for example, the role information can be the name of the role corresponding to the target user.

[0032] Specifically, in one approach, users are directly associated with roles, forming a mapping between user identifiers and role information. In this case, the target user's role information can be directly retrieved based on the target user's identifier. In another approach, users are associated with user groups, forming a mapping between user identifiers and user groups. Simultaneously, user groups are associated with roles, forming a mapping between user groups and role information. In this case, the target user's user group is first retrieved based on their identifier, and then the corresponding role information is retrieved based on the user group. It should be noted that these mapping relationships can be pre-stored in the electronic device in the form of a mapping table.

[0033] S102: Obtain the first data rule and the first operation rule based on the selection instruction and role information, and generate a data list interface according to the first data rule and the first operation rule. The data list interface contains permission data for which the target user has operation permissions.

[0034] In this embodiment, after receiving a selection instruction from a target user, the electronic device identifies the selection instruction to determine the target menu that the target user wants to access. Subsequently, based on the target menu and the target user's role information, the electronic device queries the rule storage space for the first data rule and the first operation rule associated with the role information and the target menu. The rule storage space stores the mapping relationship between role information and constraint rules. When an administrator or business personnel defines role information for a user and configures corresponding constraint rules for that role information in the access control interface, the access control system can store the role information and the corresponding constraint rules in the rule storage space.

[0035] In this embodiment, the constraint rules associated with the target user's role information can be queried first. Then, constraint rules associated with the target menu can be filtered from these rules. The final constraint rules include a first data rule and a first operation rule. The first data rule limits which data the target user can operate on within the target menu at the data level. Data that the target user has the right to operate on is the permission data. For example, by setting a first data rule for the target user, it can be limited that the target user can only operate on data within their department. The first operation rule limits the specific operations that the target user can perform on the permission data at the operation level. That is, it limits which operations the target user can perform on the permission data. For example, by setting a first operation rule for the target user, it can be specified that the target user can perform one or more of the following operations on the permission data: viewing, editing, deleting, and exporting.

[0036] In this embodiment, based on the first data rule and the first operation rule, the permission data that the target user has the right to operate on, as well as the first operation permission for the permission data, can be obtained. The permission management system uses the aforementioned permission data and the first operation permission to render on the front end, thereby generating a data list interface. This data list interface not only displays the permission data that the target user is authorized to operate on, but also presents the first operation permission for the permission data in the form of button permission points. Button permission points include one or more of the following: add button, delete button, export button, view button, and edit button; this embodiment of the application is not limited to these.

[0037] S103: When an operation instruction from a target user is received for any target data in the data list interface, the second data rule and the second operation rule are obtained based on the operation instruction and role information, and a form interface is generated according to the second data rule and the second operation rule so that the target user can operate on the various elements in the target data in the form interface.

[0038] In this embodiment, when a target user operates on any piece of permission data (i.e., target data) in the data list interface, the permission management system receives an operation instruction from the target user. The permission management system can then identify this operation instruction to determine the target data that the target user intends to operate on. Further, the permission management system can query the rule storage space for a second data rule and a second operation rule associated with the role information and the target data, based on the target user's role information and the target data. Similar to step S102, the permission management system can first query the constraint rules associated with the target user's role information, and then further filter out the constraint rules associated with the target data from these constraint rules. The final constraint rules include the second data rule and the second operation rule. The second data rule is used to limit the elements that the target user can operate on the target data at the data level, that is, to limit which elements within the target data the target user can operate on. These elements include at least one of main table fields, panel fields, and sub-table fields. For example, the second data rule can limit the target user to access main table A field, main table B field, and sub-table C field in the target data. The second operational rule is used to limit the specific operations that the target user can perform on the above elements at the operational level, that is, to limit what operations the target user can perform on each element in the target data. For example, the target user can edit field A in the main table, but only has access permissions to field B in the main table.

[0039] In this embodiment, based on the second data rules and the second operation rules, the system can obtain the various elements in the target data that the target user has the right to operate on, as well as the second operation permissions for each element. The permission management system uses these elements and second operation permissions in the target data to render a form interface on the front end. The form interface can display the target user's operation permissions for each element in the target data. For example, for a field A in the main table with edit permissions, the form interface can display an editable input box; for a field B in the main table with only access permissions, the form interface will present its content in read-only mode. In other words, in the form interface, the second data rules and the second operation rules can limit which panels the target user can see, which panels cannot see, which fields in the form interface are editable, and which fields are not editable.

[0040] The access control method provided in this application, when receiving a selection instruction from a target user for a target menu, determines the corresponding role information based on the target user identifier. Then, based on the selection instruction and role information, it obtains a first data rule and a first operation rule, generating a data list interface containing access control data. When receiving an operation instruction from the target user for target data in the data list interface, it obtains a second data rule and a second operation rule based on the operation instruction and role information, thereby generating a form interface to allow the target user to operate on various elements of the target data. Using this approach, whenever a user's relevant instruction is received, the electronic device obtains the corresponding data rules and operation rules based on the user's instruction and role information. Even in changing business environments, dynamic access control can be achieved. Furthermore, by combining operation rules with data rules for access control, fine-grained access management is achieved, thereby realizing a deep integration of RBAC and DBAC (Data-Based Access Control).

[0041] Optionally, in the above embodiments, before the electronic device determines the role information corresponding to the target user based on the target user's identifier, the access control system can obtain the role information corresponding to the target user in advance, so as to query the menu permission rules associated with the role information. Then, the access control system generates an application interface according to the menu permission rules, so that the target user can select a target menu in the application interface, which contains one or more menus that the target user has access to.

[0042] like Figure 2 As shown, Figure 2This is another flowchart of the access control method provided in this application embodiment. In this application embodiment, after the target user enters login information such as account and password on the workbench interface, the user logs in. When the access management system detects the target user's login, it can obtain the target user's identifier from the login information, and then obtain the target user's role information based on the target user's identifier. Further, the access management system can query the corresponding menu permission rules from the rule storage space based on the role information. The menu permission rules are used to limit which menus the target user can access, thereby determining the menus that the target user has access to based on the menu permission rules, and then returning various applications that the target user has access to to the workbench interface.

[0043] If a target user has access to a menu within an application, it indicates that the target user has access to that application. If the target user has access to multiple applications, the workbench interface will display all of them. When the target user clicks on a target application, the application interface will appear on the screen, allowing the target user to select the desired menu within that application. This approach ensures that the target user can only access the applications and menus they are authorized to view and manipulate, thus effectively guaranteeing the accuracy of access control.

[0044] Optionally, before obtaining the role information corresponding to the target user, the permission management system can pre-assign the target user to the corresponding user group. This user group is associated with the role information and has constraint rules associated with the role information. The constraint rules include at least one of the following: menu permission rules, data constraint rules, permission point constraint rules, main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules.

[0045] like Figure 3 As shown, Figure 3 This is a schematic diagram of role rule configuration provided in an embodiment of this application. In this embodiment, to facilitate user management, administrators or business personnel can pre-assign users to corresponding user groups through the permission management interface, that is, bind user identifiers to user groups to establish a mapping relationship between user identifiers and user groups. Simultaneously, user groups are associated with role information, that is, user groups are bound to role information to establish a mapping relationship between user groups and role information, thereby ensuring that users within each user group have the same role permissions. For further management, the aforementioned user groups can be divided into ordinary user groups and tree-structured user groups. Ordinary user groups represent independent user groups that have no association with other users or user groups. Tree-structured user groups are user groups with a hierarchical structure, where one user group can become a child group or parent group of another user group. For example, user groups can be divided into teams, departments, etc., with departments acting as the parent group of teams and possessing all the permissions of the team.

[0046] In this embodiment, administrators or business personnel can set constraint rules associated with role information through the permission management interface and store these constraint rules in the rule storage space. Specifically, menu permission rules specify the menus a role has access to; data constraint rules limit the data permissions a role can manipulate; permission point constraint rules limit the operations a role can perform on the permitted data; main table field constraint rules and sub-table field constraint rules limit the main table fields and sub-table fields a role can manipulate, respectively; main table field operation rules and sub-table field operation rules limit the operation permissions for main table fields and sub-table fields, respectively; and panel constraint rules limit the panels a role has access to.

[0047] This approach ensures that role information corresponds to user groups rather than individual users, facilitating user management. Furthermore, through multi-dimensional constraint rules across menus, data, fields, and panels, it enables refined management and precise control of user permissions.

[0048] Optionally, during the process of the access control system obtaining the role information corresponding to the target user, the access control system can obtain the target user's identifier based on the target user's login information, then query the user groups associated with the target user based on the identifier, and finally determine the target user's role information based on the mapping relationship between user groups and role information.

[0049] In this embodiment, when a target user enters login information such as account and password, and the verification is successful, the access control system can obtain a unique and unchanging identifier for that target user. Subsequently, based on this identifier, and through the mapping relationship between user identifiers and user groups, the access control system can query the user group to which the target user belongs. Further, based on the user group to which the target user belongs, the access control system can find the corresponding role information for the user group through the mapping relationship between user group and role information, ultimately obtaining the role information associated with the target user. It should be noted that a target user can belong to one or more user groups. When a target user belongs to multiple user groups simultaneously, the target user has multiple corresponding roles, and the role information can include the names of multiple roles.

[0050] With this approach, since the target user has the roles and permissions of their user group, when querying the target user's role information, it is only necessary to determine the user group to which the target user belongs to find the corresponding role information of that user group, making the query process more efficient.

[0051] Optionally, during the process of the access control system obtaining first data rules and first operation rules based on selection instructions and role information to generate a data list interface, the access control system can determine the target menu based on the selection instructions, and then query the first data rules and first operation rules based on the target menu and role information. Afterwards, the access control system can obtain access data based on the first data rules, and obtain the target user's first operation permissions for the access data based on the first operation rules, and then generate the data list interface based on the aforementioned access data and the aforementioned first operation permissions.

[0052] Optionally, the first data rule includes data constraint rules, and the first operation rule includes permission point constraint rules. Data constraint rules specify the access permissions a target user can have on the data list interface. For example, in nationwide data, data constraint rules can restrict user A to only access data from East China, meaning the data list interface only displays data from that region. Similarly, user B can only access data from Jiangsu Province, meaning the data list interface only displays data from that region. Permission point constraint rules specify the operations a target user can perform on the access data on the data list interface. Specifically, this can be represented by displaying corresponding button permission points on the data list interface, such as a create button, an export button, or an edit button. For example, if a target user does not have editing permissions for data A, then the edit button for data A will be unselectable or hidden on the data list interface.

[0053] Specifically, based on the target menu and role information, the rule interpreter, using Spring AOP (Aspect-Oriented Programming) reflection, retrieves the corresponding data constraint rules and permission point constraint rules from the rule storage space. Subsequently, the rule interpreter converts these rules into executable database statements and renders them on the front end through general CRUD (Create, Read, Update, Delete) interfaces, resulting in a data list interface. Simultaneously, administrators can configure or modify constraint rules, including data constraint rules and permission point constraint rules, in real time according to actual business needs, updating the constraint rules accordingly. Therefore, upon receiving a selection command, the permission management system can retrieve the latest data constraint rules and permission point constraint rules from the rule storage space through the rule interpreter, thereby generating an updated data list interface to achieve dynamic management of the target user's permission data.

[0054] It should be noted that a target user can correspond to multiple roles, and each role has its own constraint rules. If a target user corresponds to more than one role, the constraint rules associated with each role are merged through the rule interpreter, and finally a data list interface is generated based on the merged constraint rules.

[0055] This approach ensures that each user can only operate on authorized data within their authorized scope through the first data rule and the first operation rule, thereby effectively protecting data security.

[0056] Optionally, during the process of the access control system obtaining second data rules and second operation rules based on operation instructions and role information, and generating a form interface based on the second data rules and second operation rules, the access control system can determine the target data based on the operation instructions, and then query the second data rules and second operation rules based on the target data and role information. Afterwards, the access control system can obtain each element in the target data based on the second data rules, and obtain the target user's second operation permissions for each element based on the second operation rules, and then generate a form interface based on the elements in the target data and the second operation permissions.

[0057] Optionally, the second data rules include main table field constraint rules, panel constraint rules, and sub-table field constraint rules; the second operation rules include main table field operation rules and sub-table field operation rules. It is understood that the form interface is the data input and editing interface, and the main platform for target users to add, delete, and modify authorized data. In this embodiment, the main table field constraint rules specify the main table fields that the target user can access in the form interface, and the main table field operation rules specify the operations that the target user can perform on the main table fields in the form interface, such as viewing and editing. A main table can be configured with multiple sub-tables. Sub-table field constraint rules specify the sub-table fields that the target user can access in the form interface, and the sub-table field operation rules specify the operations that the target user can perform on the sub-table fields. Panel constraint rules specify the panels that the target user can access in the form interface. A panel, as an integrated display tool, can be used to display some fields in the main table. Panel constraint rules ensure that the target user can only see panels that match their permissions.

[0058] Specifically, based on the target data and role information, the rule interpreter, using Spring AOP reflection, can retrieve the corresponding main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules from the rule storage space. Subsequently, the rule interpreter converts these rules into database-executable statements, which are then rendered on the front end through CRUD (Create, Read, Update, Delete) interfaces to obtain the form interface. Similarly to the above embodiment, administrators can configure or modify constraint rules in real time according to actual business needs to update the constraint rules. Therefore, upon receiving an operation instruction, the rule interpreter can retrieve the latest main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules from the rule storage space, thereby generating the latest form interface to achieve dynamic management of various elements in the target data.

[0059] This approach, by utilizing field and panel level constraint rules, can precisely limit the access permissions of users with different roles to fields (for example, some roles only have viewing permissions for specific main table fields and sub-table fields, while other roles have editing permissions), achieving precise control over the permissions of different roles. Furthermore, by controlling the permissions of main table fields, sub-table fields, and panels, permission management is further refined.

[0060] Optionally, in the above embodiments, during the process of setting constraint rules associated with role information, the permission management system can set constraint rules associated with role information according to business nodes in the business process.

[0061] In this embodiment, the administrator or business personnel pre-define the business process, which includes multiple business nodes, each with corresponding role information for handling that node. Specifically, based on actual business needs, the administrator can set different constraint rules for different roles at different business nodes. Once the business process is initiated, the target data can flow between the various business nodes. At different business nodes, different roles have different access rights to the elements within the target data and corresponding operational permissions. For example, within the same form, different roles may see different main table fields, sub-table fields, or panels.

[0062] For example, in a quotation process, a salesperson initiates a quotation process. Each salesperson only has access to the quotation process they initiated, while higher-level regional managers can view multiple quotation processes from a higher perspective. After a quotation process is initiated, it is distributed to multiple different business nodes. Each business node has users with different roles who need to handle tasks. Although users at different business nodes view the same quotation, based on the principle of least privilege, each user can only view and operate on the parts relevant to their business. Through the configuration of different constraint rules, users with different roles can only view and operate on the main table fields, sub-table fields, and panels related to their business. For example, users in the logistics department can only view and edit the main table fields, sub-table fields, and / or panels related to logistics costs in the quotation, and users in the installation department can only view and edit the main table fields, sub-table fields, and / or panels related to installation costs in the quotation. For example, for the role responsible for cost data entry, only editing permissions for specific main table fields and / or sub-table fields are set at the data entry node. For the role responsible for data review, viewing, approving, or rejecting permissions for the aforementioned main table fields and / or sub-table fields are set at the review node.

[0063] It's worth noting that during the workflow of business nodes, the role information and constraint rules of relevant users can be modified in real time through the permission management interface. When the enterprise's organizational structure is adjusted or personnel responsibilities change, the administrator can update the constraint rules or the users associated with the role information in any task node within the permission management interface. For example, if business personnel B is promoted to department head, their constraint rules and user group can be modified in the permission management interface. For instance, their permission to view only the relevant fields of a quotation can be updated to the permission to view and edit the relevant fields. When business personnel B processes their business node, the processing will be based on the updated relevant fields and operation permissions.

[0064] This approach integrates constraint rules with business processes, enabling precise control and dynamic adjustment of permissions, and greatly improving the flexibility and efficiency of permission management.

[0065] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0066] Figure 4 This is a schematic diagram of an access control device provided in an embodiment of this application. The device 400 includes: a role information determination module 41, a first access control module 42, and a second access control module 43.

[0067] The information determination module 41 is used to determine the role information of the target user based on the target user's identifier when it receives a selection instruction for the target menu submitted by the target user. The target menu is a menu that the target user has access to.

[0068] The first permission control module 42 is used to obtain the first data rule and the first operation rule based on the selection instruction and role information, so as to generate a data list interface according to the first data rule and the first operation rule. The data list interface contains permission data of the target user with operation permissions.

[0069] The second access control module 43 is used to obtain the second data rules and the second operation rules based on the operation instructions and role information when it receives an operation instruction from the target user for any target data in the data list interface, and to generate a form interface according to the second data rules and the second operation rules so that the target user can operate on the various elements in the target data in the form interface.

[0070] In one feasible implementation, the access control device 400 further includes: The target user allocation module 44 is used to assign target users to corresponding user groups, and the user groups are associated with role information.

[0071] The rule configuration module 45 is used to set constraint rules associated with role information. The constraint rules include at least one of the following: menu permission rules, data constraint rules, permission point constraint rules, main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules.

[0072] In one feasible implementation, before the information determination module 41 determines the role information corresponding to the target user based on the target user's identifier, it is also used to obtain the role information corresponding to the target user, so as to query the menu permission rules associated with the role information according to the role information; and generate an application interface according to the menu permission rules, so that the target user can select the target menu in the application interface, and the application interface contains one or more menus that the target user has access to.

[0073] In one feasible implementation, when the information determination module 41 obtains the role information corresponding to the target user, it is used to obtain the identifier of the target user based on the login information of the target user, so as to query the user group associated with the target user based on the identifier; and to determine the role information of the target user based on the mapping relationship between the user group and the role information.

[0074] In one feasible implementation, when the first permission control module 42 obtains the first data rule and the first operation rule based on the selection instruction and role information, and generates a data list interface according to the first data rule and the first operation rule, it is used to determine the target menu according to the selection instruction, and query the first data rule and the first operation rule based on the target menu and role information; obtain permission data based on the first data rule, and obtain the first operation permission of the target user for the permission data based on the first operation rule, so as to generate a data list interface according to the permission data and the first operation permission.

[0075] In one feasible implementation, when the second permission control module 43 obtains the second data rules and the second operation rules based on the operation instructions and role information, and generates a form interface according to the second data rules and the second operation rules, it is used to determine the target data according to the operation instructions, query the second data rules and the second operation rules based on the target data and role information; obtain each element in the target data based on the second data rules, and obtain the second operation permissions of the target user for each element based on the second operation rules, so as to generate a form interface according to each element in the target data and the second operation permissions.

[0076] In one feasible implementation, the first data rule includes data constraint rules, and the first operation rule includes permission point constraint rules; the second data rule includes main table field constraint rules, panel constraint rules, and sub-table field constraint rules, and the second operation rule includes main table field operation rules and sub-table field operation rules.

[0077] In one feasible implementation, when the rule configuration module 45 sets constraint rules associated with role information, it is used to set constraint rules associated with role information according to business nodes in the business process.

[0078] The permission control device provided in this application embodiment is used to execute the permission control method in the above embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0079] Combination Figure 5 As shown, this application embodiment provides an electronic device 500, including a processor 501 and a memory 502. Optionally, the device may further include a communication interface 503 and a bus 504. The processor 501, memory 502, and communication interface 503 can communicate with each other via the bus 504. The communication interface 503 can be used for information transmission. The processor 501 can call logical instructions in the memory 502 to execute the access control method described in the above embodiment.

[0080] Furthermore, the logic instructions in the aforementioned memory 502 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0081] The memory 502, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this application. The processor 501 executes functional applications and data processing by running the program instructions / modules stored in the memory 502, thereby implementing the access control method in the above embodiments.

[0082] The memory 502 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 502 may include high-speed random access memory and may also include non-volatile memory.

[0083] This application provides a storage medium storing computer-executable instructions, which are configured to execute the permission control method described in the above embodiments.

[0084] The aforementioned storage medium can be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0085] The technical solutions of this application embodiment can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this application embodiment. The aforementioned storage medium can be a non-transitory storage medium, including: USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, and other media capable of storing program code; it can also be a transient storage medium.

[0086] This application provides a computer program product, including a computer program, which, when executed by a processor, implements the access control method described above.

[0087] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the claims. As used in the description of embodiments and claims, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used in this application means including one or more of the associated listed items and all possible combinations thereof. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0088] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0089] The methods and products (including but not limited to devices and equipment) disclosed in the embodiments herein can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description; sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. An access control method, characterized in that, include: When a selection instruction for a target menu is received from a target user, the role information corresponding to the target user is determined based on the target user's identifier, and the target menu is a menu that the target user has access to; Based on the selection instruction and the role information, a first data rule and a first operation rule are obtained to generate a data list interface according to the first data rule and the first operation rule. The data list interface contains permission data for which the target user has operation permissions. When a target user is received to perform an operation on any target data in the data list interface, a second data rule and a second operation rule are obtained based on the operation instruction and the role information. A form interface is then generated according to the second data rule and the second operation rule so that the target user can perform operations on the various elements in the target data in the form interface.

2. The method according to claim 1, characterized in that, Before determining the role information corresponding to the target user based on the target user's identifier, the method further includes: Obtain the role information corresponding to the target user, and query the menu permission rules associated with the role information based on the role information; An application interface is generated according to the menu permission rules so that the target user can select the target menu in the application interface. The application interface contains one or more menus that the target user has access to.

3. The method according to claim 2, characterized in that, The step of obtaining the role information corresponding to the target user includes: The identifier of the target user is obtained based on the login information of the target user, and the user group associated with the target user is queried based on the identifier; The role information of the target user is determined based on the mapping relationship between the user group and the role information.

4. The method according to claim 1, characterized in that, The step of obtaining first data rules and first operation rules based on the selection instruction and the role information, and generating a data list interface according to the first data rules and the first operation rules, includes: The target menu is determined according to the selection instruction, and the first data rule and the first operation rule are queried based on the target menu and the character information; The permission data is obtained based on the first data rule, and the first operation permission of the target user for the permission data is obtained based on the first operation rule, so as to generate the data list interface according to the permission data and the first operation permission.

5. The method according to claim 4, characterized in that, The step of obtaining second data rules and second operation rules based on the operation instructions and the role information, and generating a form interface according to the second data rules and second operation rules, includes: The target data is determined according to the operation instructions, and the second data rules and the second operation rules are queried based on the target data and the role information; Based on the second data rule, each element in the target data is obtained, and based on the second operation rule, the second operation permission of the target user for each element is obtained, so as to generate the form interface according to each element in the target data and the second operation permission.

6. The method according to claim 3, characterized in that, Before obtaining the role information corresponding to the target user, the method further includes: The target user is assigned to the corresponding user group, and the user group is associated with the role information; Set constraint rules associated with the role information. The constraint rules include at least one of the following: menu permission rules, data constraint rules, permission point constraint rules, main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules.

7. The method according to claim 6, characterized in that, The first data rule includes the data constraint rule, and the first operation rule includes the permission point constraint rule; the second data rule includes the main table field constraint rule, the panel constraint rule, and the sub-table field constraint rule, and the second operation rule includes the main table field operation rule and the sub-table field operation rule.

8. The method according to claim 6, characterized in that, The constraint rules associated with the role information include: Based on the business nodes in the business process, set constraint rules associated with the role information.

9. An access control device, characterized in that, include: The information determination module is used to determine the role information corresponding to the target user based on the identifier of the target user when it receives a selection instruction for the target menu submitted by the target user, wherein the target menu is a menu that the target user has access to; The first permission control module is used to obtain a first data rule and a first operation rule based on the selection instruction and the role information, so as to generate a data list interface according to the first data rule and the first operation rule, wherein the data list interface contains permission data of the target user having operation permissions; The second access control module is used to obtain second data rules and second operation rules based on the operation instructions and the role information when it receives an operation instruction from a target user for any target data in the data list interface, and to generate a form interface according to the second data rules and the second operation rules so that the target user can operate on the various elements in the target data in the form interface.

10. The apparatus according to claim 9, characterized in that, Also includes: The user assignment module is used to assign the target user to a corresponding user group, wherein the user group is associated with the role information. The rule configuration module is used to set constraint rules associated with the role information. The constraint rules include at least one of the following: menu permission rules, data constraint rules, permission point constraint rules, main table field constraint rules, panel constraint rules, sub-table field constraint rules, main table field operation rules, and sub-table field operation rules.

11. An electronic device comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to perform the method as described in any one of claims 1 to 8 when executing the program instructions.

12. A storage medium storing program instructions, characterized in that, When the program instructions are executed, they perform the method as described in any one of claims 1 to 8.

13. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the method as described in any one of claims 1 to 8.

Images