A data query method for cascade screening of new energy industry organization institutions

Abstract

The application provides a data query method for cascade screening of new energy industry organization institutions, comprising: obtaining a permission mark of a current login user; comparing the permission mark of the user with a permission / level dictionary to obtain a user level of the user; determining a permission mark of data to be queried; comparing the permission mark of the data to be queried with the permission / level dictionary to obtain a data level of the data to be queried; comparing the user level of the user with the data level of the data to be queried to determine whether the user has the permission to query the data; when the user has the permission to query the data, displaying the next level data corresponding to the user level through a drop-down box; and returning the data to be queried or expanding the cascade data level by level according to the selection operation of the user. The application saves all permission levels and related logic of permission interface calling in a dictionary, and the dictionary is configured by a management background, so that the adjustment of the permission is more convenient and lightweight.

Description

Technical Field

[0001] This invention relates to data query technology, and more particularly to a data query method for cascading screening of organizations in the new energy industry. Background Technology

[0002] The centralized control system in the new energy industry has a large demand for data queries. During the data query process, it is necessary to impose conditions on the data to be queried, among which the "data dimension" is a crucial condition that must be determined before the data query is performed. The common organizational hierarchy in new energy industry group companies, from highest to lowest authority, is: Group, Branch, Power Plant, Equipment (Wind Turbines / Photovoltaics, etc.). Determining the "data dimension" means determining whether the data to be queried is at the group level, branch level, or power plant / equipment level. Only when the data permission level of the currently logged-in system account is higher than the data permission level of the data to be queried can that user be allowed to view the corresponding data.

[0003] Existing data query methods typically include: Figure 1 As shown, this is only a dictionary of "level / permission {2: company}" provided by the system. After a user logs in, they obtain their permission level (level, such as group: 1). The approach to finding a list of organizations at a certain level is as follows: based on the permission level of the list to be queried, use if / else statements to match the data interface to be called.

[0004] However, existing methods have the following limitations:

[0005] ① This method writes the logic of data lists with different permission dimensions in the data query component code. Once the calling interface needs to be changed, the corresponding code logic needs to be modified. Once the code is modified, it will involve a series of lengthy development processes such as subsequent integration, testing, and release.

[0006] ② When the organizational structure is adjusted, such as adding or reducing organizational levels, the code in the data query component also needs to be adjusted accordingly. Suppose the organizational structure changes from the current 4 levels to 5 levels, and a "duration" level is added between the site and the equipment. At this time, the code needs to be adjusted accordingly. After modifying the code, the lengthy process from testing to release mentioned in the previous step will still be involved. Summary of the Invention

[0007] The purpose of this invention is to provide a data query method for cascading filtering of organizations in the new energy industry, which makes the adjustment of permissions more convenient and lightweight, and can meet the potential demand for "unlimited expansion" of permissions.

[0008] The following provides a brief overview of one or more aspects to offer a basic understanding of them. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form to prepare for the more detailed descriptions that follow.

[0009] According to one aspect of the present invention, a data query method for cascading filtering of new energy industry organizations is provided, comprising:

[0010] Get the permission flags of the currently logged-in user;

[0011] Compare the user's permission marker with the permission / level dictionary to obtain the user's user level; identify the permission marker for the data to be queried;

[0012] The permission flags of the data to be queried are compared with the permission / level dictionary to obtain the data level of the data to be queried;

[0013] The user's user level is compared with the data level of the data to be queried to determine whether the user has permission to query the data.

[0014] When the user has permission to query the data, the next level of data corresponding to the user's level will be displayed via a drop-down list.

[0015] The system returns the data to be queried or expands the cascading data level by level based on the user's selected action.

[0016] In one embodiment, the permission / level dictionary defines the permission levels corresponding to various permission tags.

[0017] In one embodiment, the permission marker for specifying the data to be queried includes:

[0018] If the data query interface is a single-dimensional data query interface, determine the permission flag for the data to be queried based on the name of the data query interface.

[0019] If the data query cross-section is a multi-dimensional data query cross-section, the permission flags for the data to be queried are determined based on the permission flags bound to the query type selected by the user.

[0020] In one embodiment, when the user has permission to query the data, displaying the next level of data corresponding to the user's level via a dropdown menu includes:

[0021] Calculate the permission level of the next level of data corresponding to the user level;

[0022] The permission level of the next level of data is compared with the permission / level dictionary to obtain the permission tag corresponding to the next level;

[0023] Match the permission flags corresponding to the next level of data with the permission / interface dictionary to obtain the interface to call the next level of data;

[0024] The system calls the interface to access the next level of data, receives the data, and renders the corresponding data dropdown list. Each option in the data dropdown list has a permission flag and a permission level field.

[0025] In one embodiment, the step of expanding cascading data or returning the data to be queried according to the user's selection includes:

[0026] Determine whether the user's selected options have the same permission level as the data to be queried;

[0027] If equal, return the relevant data for the selected item;

[0028] If not equal, expand to the next level of cascaded data based on the user's selection.

[0029] In one embodiment, expanding the next level of cascaded data according to the user's selection includes:

[0030] When a user selects an item from a dropdown menu, obtain the permission level for that option;

[0031] Calculate the permission level of the next level of data corresponding to the selected option;

[0032] The permission level of the next level of data is compared with the permission / level dictionary to obtain the permission tag corresponding to the next level;

[0033] Match the permission flags corresponding to the next level of data with the permission / interface dictionary to obtain the interface to call the next level of data;

[0034] The system calls the interface to access the next level of data, receives the data, and renders the corresponding data dropdown list. Each option in the data dropdown list has a permission flag and a permission level field.

[0035] In one embodiment, the permission / interface dictionary defines the data interfaces to be called by data at each level.

[0036] In one embodiment, the permission / level dictionary is pre-stored in the management backend. When a user logs into the system, it is retrieved from the management backend and cached on the browser.

[0037] In one embodiment, the method further includes: after obtaining the permission / level dictionary, reversing it to obtain the level / permission dictionary, and storing it in the front-end cache.

[0038] The beneficial effects of this invention are as follows: By storing all permission levels and related logic for permission interface calls in a dictionary, which is configured by the management backend and retrieved and cached when a user logs into the system, any changes to permission levels or interfaces can be made directly in the management backend without requiring code modification. This avoids the cumbersome process of modification, testing, and deployment associated with code changes, making permission adjustments more convenient and lightweight. It achieves the goals of "adjusting permissions without code," quickly completing permission adjustments at critical boundaries, and fulfilling the potential need for "unlimited permission expansion." Attached Figure Description

[0039] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0040] The above-described features and advantages of the present invention will be better understood after reading the following detailed description of embodiments of the present disclosure in conjunction with the accompanying drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related properties or features may have the same or similar reference numerals.

[0041] Figure 1 This is a flowchart of existing data query methods;

[0042] Figure 2 This is a flowchart of the method provided in the embodiments of this application;

[0043] Figure 3 This is a diagram of a data dropdown list;

[0044] Figure 4 This is a diagram showing the dropdown menu below "Branch 1" when selected. Detailed Implementation

[0045] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be noted that the aspects described below with reference to the accompanying drawings and specific embodiments are merely exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0046] In this embodiment, it is assumed that the data dimensions in the project are at four levels: Group-1; Branch Office-2; Site-3; and Equipment-4. This embodiment uses four levels of data as an example, but it is not limited to the cascading of four data dimensions; this method supports unlimited dimension expansion.

[0047] To implement this method, the following preliminary work is required:

[0048] 1. Define a "roleFlag" / level dictionary (roleMap) to define the "level" for each data dimension.

[0049]

[0050]

[0051] The permission markers in the dictionary, ordered from highest to lowest permission, are as follows:

[0052] The permission level corresponding to group-group is 1;

[0053] The permission level corresponding to "company" is 2.

[0054] Plant site - corresponding permission level is 3;

[0055] The corresponding permission level for the dev device is 4.

[0056] Among them, the "permission dictionary" is stored in the "account information" and is a crucial field of account information. The system architect formulates the rules according to the specific permission scenarios, and the "management backend" that comes with the operation and maintenance system is maintained by the "administrator" or higher roles.

[0057] After successfully logging into the operations and maintenance system, the "permission dictionary" is retrieved from "User Information" (including username, user permissions, permission dictionary of the user's organization, etc.) and cached in the browser. The cache is cleared after closing the browser or exiting the system, and the dictionary is retrieved again the next time you log in to the system.

[0058] 2. After obtaining the "permission / level" dictionary (roleMap), reverse it in the component code to obtain the "level / permission" dictionary (levelMap) and store it in the front-end cache for easy access later:

[0059]

[0060]

[0061] 3. Define the data list retrieval methods (permissions / interface dictionary) for each level, funList:

[0062]

[0063] Since the group is the highest level and there is only one, there is no need to define a method to retrieve the list of groups. This dictionary, like the "permissions / level dictionary," is maintained by the administrator in the management backend of the operations and maintenance system.

[0064] Figure 2 The specific flow of this method is shown, such as Figure 2 As shown, after a user logs into the system, the first step is to determine whether the currently logged-in user has data query permissions, including:

[0065] 11. Retrieve the currently logged-in user's ld (userld) and the corresponding "roleFlag" for that account: group, company, plant, dev;

[0066] 12. By comparing the user's "roleFlag" with the "roleMap" dictionary, the user's level is obtained: userLevel;

[0067] 13. Specify the "data flag" of the data to be queried: group, company, plant, dev; specifically, this includes two methods:

[0068] (1) If it is a single-dimensional data query section, it can be directly limited in the interface. For example, if the interface name is: "Daily power generation query of wind turbine", then it can be clearly stated that the data dimension to be queried by the interface is "dev". In the process of developing the interface, the dataFlag of the component can be directly set to 'dev'.

[0069] (2) If it is a multi-dimensional data query interface, in conjunction with the "Query Type Drop-down Box (Site / Equipment)", when the "Query Type" is Site: you can query "Site Basic Information - Site Name, ID, Contact Person, etc". When the "Query Type" is Equipment, you can query "Wind Turbine Basic Information - Wind Turbine Number, Wind Turbine ID, Brand, Model, etc".

[0070] When UI developers use cascading components in the UI, they bind the component's `dataFlag` to the "Query Type" dropdown. When the "Query Type" is "Factory", `dataFlag` is assigned the value "plant", and when the "Query Type" is "Device", `dataFlag` is assigned the value "dev". This allows them to determine the data's permission flag based on the query type.

[0071] 14. After comparing the data's "data flag" with the "permission / level" dictionary (roleMap), the level of the data to be queried is obtained: dataLevel;

[0072] 15. Compare userLevel with dataLevel. If userLevel <= dataLevel, it means the user has permission to query the data; if userLevel > dataLevel, it means the user does not have permission to query the data.

[0073] When the user has query permissions:

[0074] 21. Calculate the next level of permissions for the currently logged-in user. For example, if the currently logged-in user's permission is "group", then their next level of permission would be "company".

[0075] 22. Call the corresponding next-level data list retrieval method (e.g., funList.company, i.e., getCompanyList) to retrieve the data list and display the data dropdown. A typical data dropdown is as follows: Figure 3 As shown.

[0076] It should be noted that the fields in the drop-down list have permission flags (e.g., company) and permission levels (e.g., 2);

[0077] The purpose of the permission flag is as follows: In addition to the regular name / value ({name: branch company 1, value: 001}) returned by the user's selected action, the permission flag is also included as a field in the return value and passed to subsequent actions. This flag indicates the permission level of the currently selected value. The format of the return value is:

[0078]

[0079] When subsequent operations of a cascading component need to be differentiated based on the different permissions of the selected value, the permission flag field can serve as the basis for differentiated processing.

[0080] The purpose of permission levels is to perform matching operations based on the permission level of the selected item when it is necessary to continue querying the next level drop-down menu after selecting an item in the drop-down list, so as to obtain the data interface to be called to query the next level drop-down menu.

[0081] Based on the user's selection of an item from the dropdown menu, determine if the access level of the selected item is equal to the data level to be queried (dataLevel). If they are equal, return the relevant data for the selected item, and the process is complete. If they are not equal, continue displaying the next level of data.

[0082] For example, if the "Branch Company" dropdown is currently selected, you need to continue to scroll down to find the list of sites under that company;

[0083] 31. From the selected items, we can see that the branch office's permission level is 2;

[0084] 32. Calculations show that the level of the "next level (station)" is 2 + 1 = 3;

[0085] 33. By matching this value with the "permission / level" dictionary (roleMap), the permission tag corresponding to this level is determined to be: plant;

[0086] 34. Match "plant" with the "permissions / interfaces" dictionary; obtain the interface to call the next level of data;

[0087] 35. Call the next level of data via the API, receive the data, and render the corresponding site data dropdown list, such as... Figure 4 As shown.

[0088] The reason this method uses a cascading, step-by-step selection approach is that, within the new energy group, the number of managed devices is enormous (tens of millions). Directly returning the data to be queried would lead to the following problems:

[0089] 1. The return value data volume is huge, and the data request time is too long, which can easily lead to data request timeout.

[0090] 2. Excessive rendering load on the interface causes lag and crashes.

[0091] 3. Excessive data return makes it difficult to locate the target data, resulting in poor component usability.

[0092] This method employs a cascading, step-by-step selection interaction scheme, making the data volume of each organizational level relatively controllable. Considering the applicable hardware conditions, the data volume at the company and site levels is less than 100, and the data volume at each site equipment level does not exceed 500. This avoids the problems caused by excessive data volume at these levels. Furthermore, the scheme supports keyword searching within components, allowing for quick location of target data. In addition, considering the real-world use cases of this scheme, users developing components using this scheme will obtain detailed basic information about the target data from the group level down to the company, site level, and equipment level in advance, eliminating situations where unclear upstream conditions prevent the location of target data.

[0093] In summary, the new energy industry data query method provided in this embodiment offers a solution for a "general organizational structure screening" tool for new energy industry groups. By utilizing the solution provided by this invention for front-end component tool development and configuring tool parameters, the same tool can display different data, filter, and return value formats on different interfaces; this improves front-end interface development efficiency, ensures the uniformity of interface style, the consistency of interaction logic and user experience, and the unified source of filtered data.

[0094] Furthermore, by storing all permission levels and related logic for permission API calls in a dictionary—configured by the management backend and retrieved and cached when a user logs into the system—modifications to permission levels or APIs can be made directly in the management backend without requiring code modifications. This avoids the cumbersome process of modification, testing, and deployment associated with code changes, making permission adjustments more convenient and lightweight. It achieves the goals of "adjusting permissions without code," quickly completing permission adjustments at critical boundaries, and fulfilling the potential need for "unlimited permission expansion."

[0095] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0096] The prior description of this disclosure is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0097] The above description is merely a preferred example of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A data query method for cascading filtering of organizational structures in the new energy industry, characterized in that, include: Get the permission flags of the currently logged-in user; The user's permission flag is compared with the permission / level dictionary to obtain the user's user level; Clearly define the permission tags for the data to be queried; The permission flags of the data to be queried are compared with the permission / level dictionary to obtain the data level of the data to be queried; The user's user level is compared with the data level of the data to be queried to determine whether the user has permission to query the data. When a user has permission to query the data, a dropdown menu is displayed to show the next level of data corresponding to the user's level. This process includes: calculating the permission level of the next level of data corresponding to the user's level; comparing the permission level of the next level of data with a permission / level dictionary to obtain the permission flag for the next level; matching the permission flag of the next level of data with a permission / interface dictionary to obtain the interface to call the next level of data; calling the next level of data through the interface, receiving the data, and rendering the corresponding data dropdown menu. Each option in the data dropdown menu has a permission flag and permission level field. The system returns the data to be queried or expands the cascading data level by level based on the user's selected action. This includes: determining whether the permission level of the user's selected item is equal to the permission level of the data to be queried; if they are equal, returning the relevant data of the selected item; if they are not equal, expanding the next level of cascading data based on the user's selection. The step of expanding the next level of cascaded data based on the user's selection includes: When a user selects an item from the dropdown list, the permission level of that option is obtained; the permission level of the next-level data corresponding to the selected item is calculated; the permission level of the next-level data is compared with the permission / level dictionary to obtain the permission tag corresponding to the next level; the permission tag corresponding to the next-level data is matched with the permission / interface dictionary to obtain the interface to call the next-level data; the next-level data is called through the interface, the data is received, and the corresponding data dropdown list is rendered.

2. The data query method for cascading screening of new energy industry organizations according to claim 1, characterized in that, The permission / level dictionary defines the permission levels corresponding to various permission tags.

3. The data query method for cascading screening of new energy industry organizations according to claim 1, characterized in that, The permission markers for specifying the data to be queried include: If the data query interface is a single-dimensional data query interface, determine the permission flag for the data to be queried based on the name of the data query interface. If the data query cross-section is a multi-dimensional data query cross-section, the permission flags for the data to be queried are determined based on the permission flags bound to the query type selected by the user.

4. The data query method for cascading screening of new energy industry organizations according to claim 1, characterized in that, The permission / interface dictionary defines the data interfaces that each level of data needs to call.

5. The data query method for cascading screening of new energy industry organizations according to claim 1, characterized in that, The permission / level dictionary is pre-stored in the management backend. When a user logs into the system, it is retrieved from the management backend and cached in the browser.

6. The data query method for cascading screening of new energy industry organizations according to claim 5, characterized in that, Also includes: After obtaining the permission / level dictionary, reverse it to get the level / permission dictionary and store it in the front-end cache.

Images