Data query method, apparatus, device, medium, and product

Abstract

This application relates to a data query method, apparatus, device, medium, and product. The method includes: obtaining a data query request from an ERP system, and determining the type of corresponding target basic data and an initial database query instruction based on the data query request; the data query request includes a user identity identifier; determining the target access permission conditions corresponding to the type of target basic data based on a preset first mapping relationship between the user identity identifier, the type of basic data, and access permission conditions; updating the initial database query instruction based on the target access permission conditions to obtain a target database query instruction; and executing the target database query instruction to obtain the corresponding data query result. This application employs the above method, which can improve the convenience of permission maintenance and the efficiency of data query.

Description

Technical Field

[0001] This application relates to the field of computer information processing technology, and in particular to a data query method, apparatus, device, medium and product. Background Technology

[0002] In ERP (Enterprise Resource Planning) systems, data access control is a crucial means of ensuring enterprise information security. Employees at different positions and levels should only be able to access data within their scope of responsibility, especially documents involving basic information such as customers, products, suppliers, and warehouses, to ensure data security.

[0003] In related technologies, data access control schemes typically involve setting a static list of basic data permissions for each user. Administrators configure the specific data entries that users can access for each type of basic data (such as customers, products, warehouses, etc.) in a unified interface. When a user queries a document, the system filters the accessible basic data and related documents based on this static list.

[0004] However, in actual business operations, basic data is updated frequently, such as the continuous addition of products and changes in customers. The traditional static list query method mentioned above is difficult to adapt to the dynamic business needs, which can easily lead to a large workload for permission maintenance and low data query efficiency. Summary of the Invention

[0005] Therefore, it is necessary to provide a data query method, apparatus, computer equipment, computer-readable storage medium, and computer program product to address the aforementioned technical problems.

[0006] Firstly, this application provides a data query method, which includes:

[0007] Obtain data query requests from the ERP system, and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identification;

[0008] Based on the preset first mapping relationship between user identity identifier, basic data type and access permission conditions, the target access permission conditions corresponding to the target basic data type are determined; the access permission conditions are the filtering conditions of the business attributes of the basic data corresponding to the user identity identifier generated based on the preset permission configuration request.

[0009] The initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction;

[0010] Execute the target database query command to obtain the corresponding data query results.

[0011] In one embodiment, the initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction, including:

[0012] Convert the target access permission conditions into database query filter conditions;

[0013] The database query filter conditions are concatenated into the initial database query command to obtain the target database query command.

[0014] In one embodiment, the method further includes:

[0015] When there are at least two types of target basic data, convert the access permission conditions of each target into database query filtering conditions;

[0016] The database query filter conditions are concatenated into the initial database query command to obtain the target database query command, including:

[0017] According to the order of the data query requests, the query filter conditions of each database are sequentially concatenated into the initial database query instruction to obtain the target database query instruction.

[0018] In one embodiment, the method further includes:

[0019] For each user, a preset permission configuration request for the user is received, and access permission conditions corresponding to the user's identity are generated based on the preset permission configuration request; the preset permission configuration request includes filtering conditions for business attributes set for at least one type of basic information;

[0020] Store each access permission condition and establish the association between the access permission condition and the user identity identifier to obtain the first mapping relationship.

[0021] In one embodiment, the data query request also includes a role identifier, which is used to indicate that the user has other identities; the method further includes:

[0022] Identify the role identifier in the data query request;

[0023] If the role identifier is empty, determine the target access permission conditions corresponding to the type of target basic data based on the first mapping relationship;

[0024] If the role identifier is not empty, the target access permission conditions are obtained based on the preset access permission processing method.

[0025] In one embodiment, the target access permission conditions are obtained based on a preset access permission processing method, including:

[0026] For each role identifier, based on the second mapping relationship of the preset role identifier, the type of basic data and the query permission conditions, the first access permission condition corresponding to the type of target basic data is determined.

[0027] Based on the first mapping relationship, determine the second access permission conditions corresponding to the type of target basic data;

[0028] The second access permission condition and each of the first access permission conditions are combined to obtain the target access permission condition.

[0029] In one embodiment, the user identity identifier corresponds to one of the role identifiers; based on a preset access permission processing method, the target access permission conditions are obtained, including:

[0030] Based on the preset priority of role identifiers, the role identifier with the highest priority is determined as the target role identifier;

[0031] Based on the preset role identifier, the type of basic information, and the second mapping relationship of query permission conditions, the query permission conditions corresponding to the target role identifier are determined as the target access permission conditions.

[0032] Secondly, this application also provides a data query device, which includes:

[0033] The initial query instruction determination module is used to obtain data query requests from the ERP system and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identification.

[0034] The access permission condition determination module is used to determine the target access permission condition corresponding to the type of target basic data based on the preset user identity identifier, the type of basic data, and the first mapping relationship of access permission conditions; the access permission condition is the filtering condition of the business attributes of the basic data corresponding to the user identity identifier generated based on the preset permission configuration request.

[0035] The target query instruction determination module is used to update the initial database query instruction based on the target access permission conditions to obtain the target database query instruction;

[0036] The data query result determination module is used to execute the target database query command and obtain the corresponding data query result.

[0037] Thirdly, this application also provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0038] Obtain data query requests from the ERP system, and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identification;

[0039] Based on the preset first mapping relationship between user identity identifier, basic data type and access permission conditions, the target access permission conditions corresponding to the target basic data type are determined; the access permission conditions are the filtering conditions of the business attributes of the basic data corresponding to the user identity identifier generated based on the preset permission configuration request.

[0040] The initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction;

[0041] Execute the target database query command to obtain the corresponding data query results.

[0042] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0043] Obtain data query requests from the ERP system, and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identification;

[0044] Based on the preset first mapping relationship between user identity identifier, basic data type and access permission conditions, the target access permission conditions corresponding to the target basic data type are determined; the access permission conditions are the filtering conditions of the business attributes of the basic data corresponding to the user identity identifier generated based on the preset permission configuration request.

[0045] The initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction;

[0046] Execute the target database query command to obtain the corresponding data query results.

[0047] Fifthly, this application also provides a computer program product comprising a computer program that, when executed by a processor, performs the following steps:

[0048] Obtain data query requests from the ERP system, and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identification;

[0049] Based on the preset first mapping relationship between user identity identifier, basic data type and access permission conditions, the target access permission conditions corresponding to the target basic data type are determined; the access permission conditions are the filtering conditions of the business attributes of the basic data corresponding to the user identity identifier generated based on the preset permission configuration request.

[0050] The initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction;

[0051] Execute the target database query command to obtain the corresponding data query results.

[0052] The aforementioned data query method, apparatus, equipment, medium, and product acquire data query requests from an ERP system and determine the type of corresponding target basic data and the initial database query instruction based on the data query request. The data query request includes a user identity identifier. Based on a preset first mapping relationship between the user identity identifier, the type of basic data, and access permission conditions, the target access permission conditions corresponding to the type of target basic data are determined. The access permission conditions are filtering conditions for the business attributes of the basic data corresponding to the user identity identifier, generated based on a preset permission configuration request. The initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction. The target database query instruction is executed to obtain the corresponding data query result. This application, employing the above method, can transform the access permission control logic from the traditional "whitelist" of specific data maintenance to the "attribute rules" that define data characteristics, and change the execution timing of access permissions from the traditional static association during configuration to dynamic synthesis during querying. This allows the ERP system to become more flexible and easier to maintain when facing frequently changing enterprise data and complex permission requirements, thereby improving the user's data query efficiency and reliability. Attached Figure Description

[0053] Figure 1 Flowcharts of data query methods provided in some embodiments of this application;

[0054] Figure 2 A schematic diagram of the metadata structure of the basic information provided for some embodiments of this application;

[0055] Figure 3 This is a schematic diagram of the structure of document metadata provided in some embodiments of this application;

[0056] Figure 4 A flowchart for obtaining a target database query instruction is provided for some embodiments of this application;

[0057] Figure 5 A flowchart for obtaining a target database query instruction is provided for some embodiments of this application;

[0058] Figure 6 A flowchart for obtaining the first mapping relationship is provided for some embodiments of this application;

[0059] Figure 7 A schematic diagram of a system interface for configuring user access permissions provided in some embodiments of this application;

[0060] Figure 8 Flowcharts illustrating the conditions for obtaining target access permissions provided in some embodiments of this application;

[0061] Figure 9 Flowcharts illustrating the conditions for obtaining target access permissions provided in some embodiments of this application;

[0062] Figure 10 A flowchart illustrating the conditions for obtaining target access permissions provided in some embodiments of this application;

[0063] Figure 11 A sequence diagram of querying document data provided for some embodiments of this application;

[0064] Figure 12 Structural block diagrams of a data query apparatus provided in some embodiments of this application;

[0065] Figure 13 This is an internal structural diagram of a computer device provided in some embodiments of this application. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0067] In ERP (Enterprise Resource Planning) systems, data access control is a crucial means of ensuring enterprise information security. Employees at different positions and levels should only be able to access data within their scope of responsibility, especially documents involving basic information such as customers, products, suppliers, and warehouses, to ensure data security.

[0068] In related technologies, data access control schemes typically involve setting a static list of basic data permissions for each user. Administrators configure the specific data entries that users can access for each type of basic data (such as customers, products, warehouses, etc.) in a unified interface. When a user queries a document, the system filters the accessible basic data and related documents based on this static list. However, in actual business operations, basic data is frequently updated, such as the continuous addition of products and changes in customers. The traditional static list query method is difficult to adapt to dynamically changing business needs, easily leading to a large workload for permission maintenance and low data query efficiency.

[0069] To address the aforementioned technical problems, this application provides a data query method applicable to terminals within an enterprise that have an ERP system installed. These terminals can be, but are not limited to, various personal computers, laptops, smartphones, and tablets. The data query method includes: first, obtaining a data query request from the ERP system; then, determining the type of the corresponding target basic data and an initial database query instruction based on the data query request; the data query request includes a user identity identifier; next, based on a preset first mapping relationship between the user identity identifier, the type of basic data, and access permission conditions, determining the target access permission conditions corresponding to the type of target basic data; the access permission conditions are filtering conditions for the business attributes of the basic data corresponding to the user identity identifier, generated based on a preset permission configuration request; then, updating the initial database query instruction based on the target access permission conditions to obtain a target database query instruction; finally, executing the target database query instruction to obtain the corresponding data query result.

[0070] In this way, the access control logic can be transformed from the traditional "whitelist" of maintaining specific data to "attribute rules" that define data characteristics. Furthermore, the timing of access permission execution can be changed from static association during configuration to dynamic synthesis during querying. This makes the ERP system more flexible and easier to maintain when facing frequently changing enterprise data and complex permission requirements, thereby improving the efficiency and reliability of user data queries. Specifically, when adding a new piece of basic data, the administrator only needs to correctly set its business attributes (e.g., setting the new product category to 'electronic products') when maintaining the data. The newly added basic data will automatically fall within the scope of existing permission conditions, and users can naturally query it. Therefore, there is no need to modify the permission configuration itself, thus achieving "one-time configuration, long-term effect" in permission management. This improves the adaptability of the ERP system's query requests to dynamic business environments, which also helps improve the efficiency of user data queries.

[0071] In one embodiment, such as Figure 1As shown, the method will be explained using the aforementioned terminal as an example. In this embodiment, the method includes the following steps:

[0072] Step 102: Obtain the data query request from the ERP system, and determine the type of the corresponding target basic data and the initial database query instruction based on the data query request.

[0073] A data query request can be a request currently initiated by a user within the ERP system, or a historical request initiated by the user previously within the ERP system. The user is either the specific user currently logged into and operating the ERP system, or a historical user who has logged in and operated the ERP system. The data query request includes user identification. The system can identify the user's identity information by recognizing user identification in the data query request, such as user ID, employee number, and login account. For example, it can identify the user with user ID S001 as salesperson Zhang San. A data query request is a specific operation initiated by a user within the ERP system with the intention of retrieving data. Common forms include a user opening or refreshing a business document list interface (such as a sales order list, a purchase receipt list, etc.) or a basic data list interface (such as a customer list, a product list, etc.). Taking a sales order list as an example, a sales order list typically includes fields such as customer ID, salesperson ID, department ID, and warehouse ID, while a purchase receipt list typically includes fields such as supplier ID.

[0074] In an ERP system, basic data refers to entity data that forms the core foundation of an enterprise's business activities and is shared and referenced by multiple business modules and processes. This includes personnel and organizational data, business partner data, material and asset data, and financial data. Types of basic data typically include product information tables, customer information tables, supplier information tables, warehouse information tables, department information tables, and employee information tables. These tables form the master data that constitutes the core information of documents. The type of target basic data corresponds to the type of basic data requested in the data query. For example... Figure 2 As shown, Figure 2 This is a data illustration of some basic information. For example, the product information table stores data in the form of product metadata, which includes fields such as primary key, code, name, and category. Additionally, the attributes of basic data include basic data type, attribute fields, comparison operators, and comparison values. For instance, the attribute field of a sales order document under the product information table is "sweater," the comparison operator is "=", and the comparison value (condition value) is "brand A," meaning that this sales order is for sweaters of brand A.

[0075] The initial database query command is automatically generated by the system's backend logic based on the user's data query request. The system parses the user request (such as viewing the "sales order list", possibly with user-inputted filter conditions, such as "date=2025-01-01"), and then converts it into a basic database query command or statement that has not yet been fitted with data permission filtering, such as an SQL (Structured Query Language) statement. This statement already includes which tables (such as the main order table and the order details table) and which fields to retrieve, as well as the common filter conditions (such as the date range) set by the user on the ERP system's operation interface.

[0076] Optionally, the system's front-end interface (such as a document list page) initiates an AJAX request or submits a form, sending the user's actions (such as clicking to query, page loading, etc.) and selected parameters to the back-end server. The back-end controller receives the request, parses out the document type to be queried, for example, taking the currently obtained data query request as "view all sales orders in 2024" as an example, the system can first parse out the query intent corresponding to this data query request as querying sales orders; and then, according to... Figure 3 The predefined document metadata configuration shown allows you to find which basic data is associated with a document type. For example, if the order master table is associated with "customer" and the order details table is associated with "product", then the corresponding target basic data types are mainly the customer information table (the customer information associated with the sales order) and the product information table (the multiple product information contained in the sales order details). In addition, it may also include the department information table (the sales department information that the sales order may be associated with) and the warehouse information table (the warehouse information that the sales order may be associated with for shipment or outbound). These associated basic data types are the "target basic data types". At the same time, based on the user's self-selected parameters, the user-selected conditions are determined, and the basic SQL for querying these documents is assembled, that is, the initial database query instruction. This instruction contains the SELECT field, FROM master table and related tables (related only based on business logic), and WHERE + user-selected conditions.

[0077] Step 104: Based on the preset first mapping relationship between user identity identifier, type of basic data and access permission conditions, determine the target access permission conditions corresponding to the type of target basic data.

[0078] The access permission conditions are filtering conditions for the business attributes of basic data corresponding to the user's identity, generated based on a preset permission configuration request. The preset permission configuration request is a request made by the system administrator in the background, based on the company's organizational structure and division of responsibilities, to pre-configure user access permissions for each piece of basic data according to role (identity). For example, the administrator might pre-configure the following access permissions for the sales manager in the customer information table: Department = "My Department and Subordinate Departments"; for the product information table, the administrator might pre-configure the following access permissions for the sales manager: Product Line = "All"; and for the warehouse information table, the administrator might pre-configure the following access permissions for the sales manager: Warehouse = "All".

[0079] The formation of the first mapping relationship can begin with the system administrator selecting a specific user. Then, for a specific basic data type, such as a "customer information table," one or more filtering conditions based on that basic data attribute are configured, such as "Region" = "East China" or "Level" = "VIP" or "Regular." The system then stores the relationship between these three elements (user identity, basic data type, and access permission conditions) in a database or configuration file. This creates a permission rule table with a structure similar to (User ID, Basic Data Type, Condition Field, Operator, Condition Value). When a query is needed, the system searches for all matching rules in this permission rule table (the first mapping relationship) based on the user ID and the basic data type involved in the query. The target permission condition is the access permission condition determined based on the target basic data type in the first mapping relationship table. Furthermore, when a business document involves a basic data type with configured permission conditions, the permission conditions for the business document will automatically take effect.

[0080] Optionally, you can first obtain the user's identity identifier, such as the user ID obtained from the login session; then combine it with the target basic data type list determined in step 102, such as "product" and "customer"; then query the preset permission rule base, i.e. the first mapping relationship, to obtain all valid filtering conditions for "product" and "customer" under the user ID; then group these filtering conditions according to the basic data type to form a structure such as {"product": ["name like '%have permission%'", "category in ('category 1')"], "customer": ["name='customer 1'"]}, which is the target access permission condition.

[0081] Thus, compared with the limitations of traditional technology where permission conditions are restricted by hard coding (static and fixed), the permissions in this embodiment are dynamically generated. Instead of storing which order IDs each user can query, the system stores a general rule. When a user queries, the system will look up the corresponding preset configuration in real time based on the user's identity and generate specific filtering conditions for the current query, thereby enabling configurable, generalized and dynamic access permissions. Furthermore, traditional methods typically link permissions directly to the final business document, pre-assigning each user a business document ID they can access. This application, however, defines the smallest unit of permission control and the configuration object as the business attributes of basic data (such as the customer's region, material product category, and department level). Thus, as long as a business document is associated with a certain piece of basic data, the permission rules for that basic data automatically extend to all related documents. This facilitates subsequent access permission maintenance. When new basic data is added or changes occur, only the relevant business attributes of the basic data need to be added or modified; there's no need to update the access permissions of each user involved. Therefore, this improves the convenience of permission maintenance and the efficiency of user data retrieval.

[0082] Step 106: Update the initial database query instruction based on the target access permission conditions to obtain the target database query instruction.

[0083] The target database query instruction is the final, complete database query instruction formed by dynamically fusing the initial database query instruction with all relevant target access permission conditions. It is also a statement that can be directly executed by the database engine, containing both the original business query logic and additional data security filtering logic. For example, the final form of the target database query instruction can be a concatenated SQL statement.

[0084] Optionally, you can first iterate through the target access permission conditions; then, for each basic data type (such as "product"), check whether the FROM clause in the initial database query command, i.e., the initial SQL statement, has already associated the table of that basic data. If not, dynamically add a LEFT JOIN (or INNER JOIN) to associate the product ID field of the document details table with the primary key of the product table; then, dynamically concatenate the corresponding filter conditions in the WHERE clause (such as AND t3.fname like '%has permission%'); repeat this process for all basic data types that require access control. Finally, a complete SQL statement (target database query command) is generated that embeds all data permission filtering logic.

[0085] Step 108: Execute the target database query command to obtain the corresponding data query results.

[0086] The data query result is the data set returned by the database after executing the target database query command. For example, for a list query, the data query result is usually a structured dataset (such as a list of rows, each row containing fields such as document number, customer name, product name, and date). This dataset is received and rendered by the ERP system's front-end interface, presented to the user intuitively in the form of tables, lists, or cards. That is, what the user sees is an interface that has been automatically filtered and contains only the data that they have permission to view.

[0087] Optionally, the target database query command can be sent to the database server, such as MySQL or Oracle, through a database connection pool. Then, the database engine parses and executes the target database query command, using the indexes and optimizers in the target database query command for efficient querying. Finally, the query result set is returned to the application server, which then converts the query result set into the format required by the front end (such as JSON) and returns it to the front end interface for rendering and display.

[0088] The aforementioned data query method transforms access control logic from the traditional "whitelist" of specific data maintenance to "attribute rules" that define data characteristics. It also changes the timing of access permission execution from static association during configuration to dynamic synthesis during querying. This makes the ERP system more flexible and easier to maintain when facing frequently changing enterprise data and complex permission requirements, thereby improving user data query efficiency and reliability. Specifically, when adding a new piece of basic data, the administrator only needs to correctly set its business attributes (e.g., setting the new product category to 'electronic products') when maintaining the data. The newly added basic data will automatically fall within the scope of existing permission conditions, allowing users to query it naturally. This eliminates the need to modify the permission configuration itself, achieving "one-time configuration, long-term effect" in permission management. This improves the adaptability of the ERP system's query requests to dynamic business environments, which also helps improve the efficiency of user data queries.

[0089] In one embodiment, such as Figure 4 As shown, the initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction, including:

[0090] Step 402: Convert the target access permission conditions into database query filter conditions.

[0091] Optionally, the system first parses the entities (such as "customer") and attributes (such as "region" and "status") in the target access permission conditions; then, based on the system's data model mapping relationship, it determines the physical database table names and field names corresponding to these business attributes; then, it performs value replacement and calculation: for fixed values ​​(such as "East China"), they are used directly; for dynamic words, real-time calculation and replacement are required. For example, if the rule is order.salesperson='user', the parser needs to obtain the ID of the currently logged-in user (such as "user001") at the moment of executing the query and replace it in the filter conditions, such as forming SALESMAN_ID='user001'; then, it assembles the mapped fields, operators ("=", "IN", "LIKE", etc.) and calculated values ​​into a standard SQL condition expression string.

[0092] Step 404: Concatenate the database query filter conditions into the initial database query instruction to obtain the target database query instruction.

[0093] Optionally, the initial database query instruction can be parsed using an SQL parsing library. Then, based on the basic information provided by the target access permission conditions, the corresponding table or table alias can be found in the FROM and JOIN clauses of the initial query and merged into the initial database query instruction to obtain the target database query instruction.

[0094] In this embodiment, by dynamically generating target database query instructions in this way, we can improve the efficiency of users querying data and also ensure the convenience of permission maintenance.

[0095] In one embodiment, such as Figure 5 As shown, the method also includes:

[0096] Step 502: If there are at least two types of target basic data, convert the access permission conditions of each target into database query filtering conditions.

[0097] It is understandable that there may be more than one type of target basic data, which will increase the number of corresponding permission conditions. However, it is necessary to convert the target access permission conditions corresponding to these target basic data types into database query filtering conditions one by one.

[0098] Step 504: Following the order of the data query requests, sequentially concatenate the database query filter conditions into the initial database query instruction to obtain the target database query instruction.

[0099] Optionally, the database query filter conditions can be sequentially concatenated into the WHERE clause of the initial database query command according to the order of the data query requests to obtain the target database query command. However, if the initial database query command does not have a WHERE clause, then HERE + [permission filter condition] can be added directly. If the initial database query command has a WHERE clause, then AND + [permission filter condition] can be added to the end of the initial database query command. Finally, the target database query command, i.e., the final SQL query statement, is obtained.

[0100] In this embodiment, when there are at least two types of target basic data, each target access permission condition is converted into a database query filter condition, and each database query filter condition is sequentially concatenated into the initial database query instruction according to the request order of the data query request. This helps to improve the efficiency and reliability of the target database query instruction determination.

[0101] In one embodiment, such as Figure 6 As shown, the method also includes:

[0102] Step 602: For each user, receive a preset permission configuration request for the user, and generate access permission conditions corresponding to the user's identity based on the preset permission configuration request.

[0103] The preset permission configuration request includes filtering conditions for business attributes set for at least one type of basic data. Filtering conditions are one or more rules expressed in business language used to filter basic data records. Filtering conditions include equality matching, range matching, list matching, fuzzy matching, and relational matching, and may also include combined conditions.

[0104] Examples include: equivalence matching, such as `customer.creditr='A'`, which means precisely matching high-credit customers; range matching, such as `contract.signeddate>='2025-01-01'`, which means only contracts from 2025 onwards can be viewed; list matching, such as `material.categoryIN('finished product', 'semi-finished product')`, which means only materials of a specific category can be viewed; fuzzy matching, such as `project nameLIKE '%urgent%'`, which means only projects with "urgent" in their names can be viewed; relational matching, such as `order.salesperson='user'`, which will be replaced with the user's ID during execution; and combined conditions, including logical combinations using AND and OR, such as `(customer.source channel='online')ANDAND(customer.region='user's region')`.

[0105] Optional, such as Figure 7As shown, in the backend management page, administrators can first select a user or role, and then select a "basic information" (such as customer or supplier) from the drop-down list. They can then configure filter conditions using UI components like dropdowns, input boxes, and date pickers, and can configure multiple conditions for different basic information. Next, they can import PAI or scripts. For example, for batch initialization or integration with external systems, API interfaces or script templates are provided, allowing configurations to be uploaded in structured data formats (such as JSON). Finally, internal system conversion is performed. For instance, after the configuration interface or API receives parameters (such as {field: "customer.region", operator: "=", value: "East China"}), the system's backend "condition generator" component serializes these parameters into a standard, storable permission condition expression string or structured data object. Once the administrator has set the parameters, clicking "save" completes the user permission settings.

[0106] Step 604: Store each access permission condition and establish the association between the access permission condition and the user identity identifier to obtain the first mapping relationship.

[0107] Optionally, the storage structure can be designed first, such as creating a dedicated permission configuration table in the data. The permission configuration table can include data such as primary key, user identity identifier, type of basic information, and access permission conditions. Then, the condition expression corresponding to the access permission conditions generated in step 602, together with its associated user identity identifier and type of basic information, is written as a record into the database table to obtain the first mapping relationship.

[0108] In this embodiment, access control is transformed from a traditional, hard-coded, and rigid technical problem into a business operation problem that can be flexibly managed by administrators through configuration. Thus, when a new type of basic data is added to the system, only one option needs to be added to the permission configuration interface to start configuring permission rules for it, thereby improving the efficiency of permission maintenance.

[0109] In one embodiment, such as Figure 8 As shown, the data query request also includes a role identifier, which is used to indicate that the user has other identities; the method also includes:

[0110] Step 802: Identify the role identifier in the data query request.

[0111] Optionally, after obtaining the user's data query request, the role identifier in the data query request is identified to obtain the identification result. The identification result may be that a role identifier exists, that is, the user has other identities; or the identification result may be that a role identifier does not exist, that is, the user does not have other identities and only has the identity set by the system default.

[0112] Step 804: If the role identifier is empty, determine the target access permission conditions corresponding to the type of target basic data based on the first mapping relationship.

[0113] It is understandable that when the role identifier is empty, it means that the user only has the identity set by the system default and has no other identity. At this time, the target access permission conditions corresponding to the type of target basic information can be directly determined based on the first mapping relationship.

[0114] Step 806: If the role identifier is not empty, obtain the target access permission conditions based on the preset access permission processing method.

[0115] Understandably, when the role identifier is empty, the apparent user not only has the system's default identity but also other identities. For example, the user's default identity might be a regular employee, but they might need to temporarily view information beyond their current access permissions and be temporarily assigned a new identity to view the information corresponding to that new identity. However, in cases where a user has multiple identities, it's necessary to redefine the target access permission conditions to ensure the efficiency and reliability of data queries.

[0116] In this embodiment, the user's target access permission conditions are further determined by the identification results of the role identifier, which helps to ensure the efficiency and reliability of data query.

[0117] In one embodiment, such as Figure 9 As shown, based on the preset access permission processing method, the target access permission conditions are obtained, including:

[0118] Step 902: For each role identifier, based on the preset second mapping relationship between the role identifier, the type of basic data, and the query permission conditions, determine the first access permission condition corresponding to the type of the target basic data.

[0119] The second mapping relationship is the association between roles and permission rules. Specifically, it predefines the default query permissions for each role in the system when accessing various types of basic data. For example, the "Sales Specialist" role automatically has the permission rule "can only view clients within their department."

[0120] The first access permission condition is the set of permission conditions retrieved through the second mapping relationship, which represents all roles held by the user currently executing the query. For example, assuming user A has the roles of "Salesperson" and "Project Leader," the system will first retrieve condition C1 from the second mapping relationship based on the "Salesperson" role + "target basic information (such as customer)" (e.g., customer.salesperson=user), and then retrieve condition C2 based on the "Project Leader" role + "target basic information (customer)" (e.g., customer.project IN (the list of projects the user is responsible for)). That is, conditions C1 and C2 are the user's first access permission conditions (a list of conditions) regarding the "customer" information.

[0121] Optionally, when a user initiates a query, the system obtains the user's identity identifier, such as user_id, from the session or token; then queries the user's role, and for each role, in conjunction with the target basic data type of this query, queries the second mapping relationship to determine the corresponding first access permission condition.

[0122] Step 904: Based on the first mapping relationship, determine the second access permission conditions corresponding to the type of the target basic data.

[0123] The second access permission condition is the permission condition that is directly granted to the user currently executing the query, which is found through the first mapping relationship.

[0124] Optionally, user identification, such as user_id and target basic data type, can be used to directly query the first mapping relationship to determine the second access permission conditions corresponding to the type of target basic data.

[0125] Step 906: Merge the second access permission condition and each of the first access permission conditions to obtain the target access permission condition.

[0126] Optionally, permission rules from different roles can be merged sequentially with the second access permission conditions and each of the first access permission conditions to obtain the target access permission conditions.

[0127] In this embodiment, by combining role-based authorization with user-based personalized authorization, the efficiency and consistency of permission management can be guaranteed. Furthermore, by merging the second access permission conditions and each first access permission condition, it can be ensured that the final effective permission conditions not only cover all the user's authority but also comply with any additional personal needs that may exist. In this way, the system can simultaneously meet the needs of large-scale standardized permission distribution and refined case handling, thereby enhancing the adaptability and maintainability of the permission system and improving the convenience of permission maintenance.

[0128] In one embodiment, such as Figure 10As shown, the user identity identifier corresponds to one of the role identifiers; based on the preset access permission processing method, the target access permission conditions are obtained, including:

[0129] Step 1002: Based on the preset priority of role identifiers, determine the role identifier with the highest priority as the target role identifier.

[0130] The priority of role identifiers can be pre-determined based on internal organizational hierarchy principles and the sensitivity of business data. The highest priority role identifier represents the highest access permission, and also means that from all the roles a user owns, a unique "effective role" can be selected for this permission determination according to preset priority rules.

[0131] Optionally, you can first query the association table based on the user's identity to obtain all the role identifiers the user possesses; then, sort the retrieved role identifiers according to the preset priority of the role identifiers, and determine the role identifier with the highest priority as the target role identifier. This avoids the complex logic (such as union and intersection judgments) required when merging multiple role permissions, making the permission determination process simpler and more efficient. It also helps users filter out data they are not interested in, thus satisfying their query requests for specific data.

[0132] Step 1004: Based on the preset second mapping relationship between role identifier, type of basic data and query permission conditions, the query permission conditions corresponding to the target role identifier are determined as target access permission conditions.

[0133] Optionally, a query key can be formed first based on the target role identifier determined in step 1002 and the type of target basic information in this query request; then, the corresponding target access permission conditions can be determined in the second mapping relationship based on the query key.

[0134] In this embodiment, determining target access permission conditions based on the highest priority role identifier can filter out data that is not of interest to users, thereby retaining the data that users currently want to view most, thus ensuring a better user experience. Furthermore, since permission rules can be configured based on roles, when adjusting the permissions of a certain type of user, only the permission conditions corresponding to that role need to be modified, and the permissions of all users with that role will be automatically and uniformly updated.

[0135] In one exemplary embodiment, such as Figure 11 As shown, Figure 11This is a sequence diagram for querying document data. When a user initiates a document query request on the product's document query interface, the backend first obtains the corresponding set data permissions based on the user's identity and returns the data permission information. Then, based on the type of target basic data corresponding to the document query request, the user's identity, and the first mapping relationship, it determines the target access permission conditions. Next, it concatenates the target access permission conditions with the aforementioned data permission information to obtain the actual query SQL, which is the concatenated SQL. The concatenated SQL is then returned so that the system can execute it to obtain the corresponding query result data. Finally, the query result data is displayed on the document query interface and rendered, showing the queried document data to the user.

[0136] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0137] Based on the same inventive concept, this application also provides a data query apparatus for implementing the data query method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more data query apparatus embodiments provided below can be found in the limitations of the data query method described above, and will not be repeated here.

[0138] In one embodiment, such as Figure 12 As shown, a data query device is provided, including: an initial query instruction determination module 1202, an access permission condition determination module 1204, a target query instruction determination module 1206, and a data query result determination module 1208, wherein:

[0139] The initial query instruction determination module 1202 is used to obtain data query requests from the ERP system and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identity identifiers;

[0140] The access permission condition determination module 1204 is used to determine the target access permission condition corresponding to the type of target basic data based on the preset user identity identifier, the type of basic data and the first mapping relationship of access permission conditions; the access permission condition is the filtering condition of the business attributes of the basic data corresponding to the user identity identifier generated based on the preset permission configuration request.

[0141] The target query instruction determination module 1206 is used to update the initial database query instruction based on the target access permission conditions to obtain the target database query instruction;

[0142] The data query result determination module 1208 is used to execute the target database query command and obtain the corresponding data query result.

[0143] In one embodiment, the target query instruction determination module 1206 is further configured to: convert the target access permission conditions into database query filter conditions; and concatenate the database query filter conditions into the initial database query instruction to obtain the target database query instruction.

[0144] In one embodiment, the target query instruction determination module 1206 is further configured to: convert each target access permission condition into a database query filter condition when there are at least two types of target basic data; and sequentially concatenate each database query filter condition into the initial database query instruction according to the request order of the data query request to obtain the target database query instruction.

[0145] In one embodiment, the apparatus further includes a mapping relationship determination module, which is configured to: for each user, receive a preset permission configuration request for the user, and generate access permission conditions corresponding to the user's identity identifier based on the preset permission configuration request; the preset permission configuration request includes filtering conditions for business attributes set for at least one type of basic data; store each access permission condition, and establish an association between the access permission condition and the user's identity identifier to obtain a first mapping relationship.

[0146] In one embodiment, the apparatus further includes a target access control module, which is used to: identify the role identifier in the data query request; if the role identifier is empty, determine the target access control conditions corresponding to the type of the target basic data based on a first mapping relationship; if the role identifier is not empty, obtain the target access control conditions based on a preset access control processing method.

[0147] In one embodiment, the target access determination module is further configured to: for each role identifier, determine a first access permission condition corresponding to the type of target basic data based on a preset second mapping relationship between the role identifier, the type of basic data, and the query permission conditions; determine a second access permission condition corresponding to the type of target basic data based on the first mapping relationship; and merge the second access permission condition and each of the first access permission conditions to obtain the target access permission condition.

[0148] In one embodiment, the target permission determination module is further configured to: determine the highest priority role identifier as the target role identifier based on the preset priority of role identifiers; and determine the query permission conditions corresponding to the target role identifier as the target access permission conditions based on the preset second mapping relationship between role identifiers, basic data types, and query permission conditions.

[0149] Each module in the aforementioned data query device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0150] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 13 As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a data query method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0151] Those skilled in the art will understand that Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0152] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0153] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0154] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0155] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0156] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0157] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0158] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A data query method, characterized by, The method includes: Obtain data query requests from the ERP system, and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identity identifiers; Based on a preset first mapping relationship between user identity identifier, basic data type, and access permission conditions, the target access permission conditions corresponding to the type of target basic data are determined; the access permission conditions are filtering conditions for the business attributes of the basic data corresponding to the user identity identifier, generated based on a preset permission configuration request. The initial database query instruction is updated based on the target access permission conditions to obtain the target database query instruction; Execute the target database query command to obtain the corresponding data query results.

2. The method according to claim 1, characterized in that, The step of updating the initial database query instruction based on the target access permission conditions to obtain the target database query instruction includes: Convert the target access permission conditions into database query filtering conditions; The database query filter conditions are concatenated into the initial database query instruction to obtain the target database query instruction.

3. The method according to claim 2, characterized in that, The method further includes: When there are at least two types of the target basic data, each of the target access permission conditions is converted into database query filtering conditions; The step of concatenating the database query filtering conditions into the initial database query instruction to obtain the target database query instruction includes: According to the order of the data query requests, the database query filter conditions are sequentially concatenated into the initial database query instruction to obtain the target database query instruction.

4. The method according to claim 1, characterized in that, The method further includes: For each user, a preset permission configuration request for the user is received, and access permission conditions corresponding to the user's identity are generated based on the preset permission configuration request; the preset permission configuration request includes filtering conditions for business attributes set for at least one type of basic data; Store each of the access permission conditions and establish an association between the access permission conditions and the user identity identifier to obtain the first mapping relationship.

5. The method according to claim 1, characterized in that, The data query request also includes a role identifier, which is used to indicate that the user has other identities; the method further includes: Identify the role identifier in the data query request; If the role identifier is empty, the target access permission conditions corresponding to the type of the target basic data are determined based on the first mapping relationship. If the role identifier is not empty, the target access permission conditions are obtained based on a preset access permission processing method.

6. The method according to claim 5, characterized in that, The preset access permission processing method obtains the target access permission conditions, including: For each of the aforementioned role identifiers, based on a preset second mapping relationship between the role identifier, the type of basic data, and the query permission conditions, a first access permission condition corresponding to the type of the target basic data is determined; Based on the first mapping relationship, determine the second access permission condition corresponding to the type of the target basic data; The target access permission condition is obtained by merging the second access permission condition and each of the first access permission conditions.

7. The method according to claim 5, characterized in that, The user identity identifier corresponds to one of the role identifiers; the method for obtaining the target access permission conditions based on a preset access permission processing method includes: Based on the preset priority of role identifiers, the role identifier with the highest priority is determined as the target role identifier; Based on the preset second mapping relationship between role identifier, type of basic information and query permission conditions, the query permission conditions corresponding to the target role identifier are determined as the target access permission conditions.

8. A data query device, characterized in that, The device includes: The initial query instruction determination module is used to obtain data query requests from the ERP system and determine the type of the corresponding target basic data and the initial database query instruction based on the data query requests; the data query requests include user identity identifiers; The access permission condition determination module is used to determine the target access permission condition corresponding to the type of the target basic data based on a preset user identity identifier, the type of basic data, and a first mapping relationship of access permission conditions; the access permission condition is a filtering condition of the business attributes of the basic data corresponding to the user identity identifier, generated based on a preset permission configuration request. The target query instruction determination module is used to update the initial database query instruction based on the target access permission conditions to obtain the target database query instruction; The data query result determination module is used to execute the target database query instruction and obtain the corresponding data query result.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images