Electric power index analysis level adjustment method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to an electric power index analysis hierarchy adjustment method and device, computer equipment, a readable storage medium and a program product. The method comprises the following steps: receiving a configuration file acquisition request sent by a front end under the condition that a user logs in the power index analysis system through the front end; in response to the configuration file acquisition request, determining a hierarchy of a management unit to which the user belongs, and acquiring a configuration file corresponding to the hierarchy of the management unit to which the user belongs; according to the user account of the user, a target analysis hierarchy bound with the user account is determined, and the target analysis hierarchy is not lower than the hierarchy of a management unit to which the user belongs; adding the target analysis hierarchy into the analysis hierarchy set of the configuration file to obtain a new configuration file; and feeding back the new configuration file to the front end. By adopting the method, the problem of inconvenience and complexity in operation in the existing power index analysis system can be solved, and the flexibility of the system and the user operation efficiency are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of power grid data management technology, and in particular to a method, apparatus, computer equipment, readable storage medium, and program product for adjusting the analysis level of power indicators. Background Technology

[0002] In the power system, corresponding configuration files can be pre-configured for grassroots power users in each region. When a grassroots power user logs into the system, the system will render the analysis level of each power indicator item on the page according to the configuration file corresponding to the user's region level. Based on the permission control requirements, grassroots power users can only analyze indicators of the lower level.

[0003] However, in some special scenarios, in order to facilitate users to make better horizontal comparisons, it is necessary to provide indicators for each region at the corresponding level for grassroots power users. These indicators can be exported by the leaders of the grassroots power users, but the operation is relatively inconvenient. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, readable storage medium, and program product for adjusting the analysis level of power indicators to address the above-mentioned technical problems.

[0005] Firstly, this application provides a method for adjusting the analysis level of power indicators, the method comprising:

[0006] When a user logs into the power index analysis system through the front end, the system receives a configuration file retrieval request sent by the front end.

[0007] In response to a configuration file retrieval request, the hierarchical level of the user's management unit is determined, and the configuration file corresponding to the hierarchical level of the user's management unit is retrieved; the configuration file carries a set of analysis hierarchies; the set of analysis hierarchies includes several analysis hierarchies lower than the hierarchical level of the user's management unit;

[0008] Based on the user's user account, determine the target analysis level bound to the user account. The target analysis level shall not be lower than the level of the management unit to which the user belongs.

[0009] Add the target analysis level to the set of analysis levels in the configuration file to obtain a new configuration file;

[0010] The new configuration file is fed back to the front end; the new configuration file is used to instruct the front end to render controls for each power indicator item that match the analysis level carried by the new configuration file.

[0011] In one embodiment, the configuration file retrieval request carries information including the user's region and user permission level. In response to the configuration file retrieval request, determining the user's management unit level includes:

[0012] Determine the level of the management unit to which the user belongs based on the user's region and user permission level.

[0013] In one embodiment, the target analytics level bound to the user account is determined based on the user's user account, including:

[0014] If the user account carries a permission change identifier, the target analysis level is determined based on the permission change identifier carried by the user account.

[0015] In one embodiment, determining the target analysis level bound to the user account based on the user's user account further includes:

[0016] If the user account does not carry a permission change identifier, then the target analysis level is determined to be the level of the management unit to which the user belongs.

[0017] In one embodiment, prior to the step of determining the hierarchy of the user's management unit in response to a configuration file retrieval request, the method further includes:

[0018] Perform format validation and information integrity validation on the configuration file retrieval request;

[0019] If the format validation and information integrity validation pass, proceed with the steps to determine the user's management unit level in response to the configuration file retrieval request.

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

[0021] If format validation or information integrity validation fails, an error message will be returned to the front end.

[0022] Secondly, this application also provides an analysis level adjustment device for power indicators, the device comprising:

[0023] The request acquisition module is used to receive configuration file acquisition requests sent by the front end when the user logs into the power index analysis system through the front end.

[0024] The configuration file determination module is used to respond to a configuration file retrieval request, determine the level of the user's management unit, and retrieve the configuration file corresponding to the level of the user's management unit; the configuration file carries a set of analysis levels; the set of analysis levels includes several analysis levels below the level of the user's management unit;

[0025] The target analysis level determination module is used to determine the target analysis level bound to the user account based on the user account. The target analysis level shall not be lower than the level of the management unit to which the user belongs.

[0026] The configuration file update module is used to add the target analysis level to the set of analysis levels of the configuration file to obtain a new configuration file;

[0027] The configuration file feedback module is used to send new configuration files to the front end; the new configuration file is used to instruct the front end to render controls for each power indicator item that match the analysis level carried by the new configuration file.

[0028] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the methods described above.

[0029] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods described above.

[0030] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods described above.

[0031] The analysis level adjustment method, device, computer equipment, readable storage medium, and program product of the above-mentioned power indicators have at least the following beneficial effects.

[0032] This system effectively solves the operational inconvenience and cumbersome issues existing in current power indicator analysis systems, significantly improving system flexibility and user efficiency. On one hand, by dynamically adding target analysis levels (no lower than the user's management unit level) bound to the user account in the configuration file, grassroots power users can directly obtain regional indicators at their own level and above for horizontal comparison in special scenarios without relying on leaders to export them. This meets the actual needs of efficient analysis in grassroots operations and avoids increased collaboration costs caused by permission restrictions in traditional processes. On the other hand, the new configuration file can be directly fed back to the front end and trigger real-time interface refresh. Users can use the newly added analysis levels without logging in again, simplifying the operation process, reducing time consumption caused by repeated logins, further adapting to the requirements of agile service capabilities in grassroots digital scenarios, and simultaneously enabling flexible adjustment of analysis levels within the permission control framework, balancing system security and business convenience. Attached Figure Description

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

[0034] Figure 1 This is an application environment diagram of the power index analysis level adjustment method in one embodiment;

[0035] Figure 2 This is a flowchart illustrating the method for adjusting the analysis level of power indicators in one embodiment;

[0036] Figure 3 This is a schematic diagram of the front-end user interface rendered from the configuration file before the update in one embodiment.

[0037] Figure 4 This is a schematic diagram of the front-end operation interface rendered by the updated configuration file in one embodiment;

[0038] Figure 5 This is a structural block diagram of an analysis level adjustment device for power indicators in one embodiment;

[0039] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0040] 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.

[0041] The method for adjusting the analysis level of power indicators provided in this application can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or placed on a cloud or other network server. When a user logs into the power index analysis system through a front-end, server 104 receives a configuration file retrieval request sent by the front-end; in response to the configuration file retrieval request, it determines the level of the user's management unit and retrieves the configuration file corresponding to that level; the configuration file carries a set of analysis levels; the set of analysis levels includes several analysis levels lower than the level of the user's management unit; based on the user's account, it determines the target analysis level bound to the user account, which is not lower than the level of the user's management unit; it adds the target analysis level to the set of analysis levels in the configuration file, obtaining a new configuration file; it feeds back the new configuration file to the front-end; the new configuration file is used to instruct the front-end to render controls for each power index item that match the analysis level carried in the new configuration file. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, and tablets. Server 104 can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0042] In one exemplary embodiment, such as Figure 2 As shown, a method for adjusting the analysis level of power indicators is provided, which can be applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps S202 to S210. Wherein:

[0043] S202: When a user logs into the power index analysis system through the front end, the system receives a configuration file retrieval request sent by the front end.

[0044] The configuration file retrieval request refers to the request sent by the front-end to the back-end configuration service after the power user logs into the system. This request is sent through a packaged HTTP request tool, and the request header carries the identity credentials generated after the user logs in for identity verification. The request parameters also contain the basic context of the user's operation (such as the current system module identifier) ​​to ensure that the configuration file related to power index analysis is obtained.

[0045] S204, in response to the configuration file retrieval request, determines the level of the user's management unit and retrieves the configuration file corresponding to the level of the user's management unit; the configuration file carries a set of analysis levels; the set of analysis levels includes several analysis levels lower than the level of the user's management unit.

[0046] The user's management unit level refers to the administrative region level corresponding to that management unit, such as provincial, municipal, county, and township levels. The server can determine this by extracting the "maximum permission level" field from the role file. The level codes are preset as provincial=1, municipal=2, county=3, township=4, etc., for easy level relationship determination. For example, the management unit level of a grassroots power user in Province A is provincial. The configuration file corresponding to the user's management unit level is a pre-configured file for grassroots power users at each regional level, stored in the configuration center. This file is generated based on the user's management unit level (e.g., provincial) and contains metadata (such as indicator codes, indicator names, data source tables, etc.) of all power indicator items accessible to users at that level, combined with permission control rules to filter out the allowed analysis level information. The analysis level set refers to the set of power indicator items allowed for user analysis contained in the configuration file. Due to permission control requirements, initially only regional levels lower than the user's management unit level are included. For example, the analysis level set for a provincial user initially includes municipal, county, and township levels.

[0047] For example, after receiving a configuration file retrieval request from the frontend, the backend configuration service matches the user's role from the role file stored in the configuration center. The role file contains fields such as role ID, role name, province code, maximum permission level, and range of accessible indicators. By extracting the "maximum permission level" field from the role file, the level of the user's management unit is determined. For example, the preset level codes are provincial = 1, city = 2, county = 3, and township = 4. If the extracted "maximum permission level" code is 1, then the user's management unit level is determined to be provincial. Based on the determined level of the user's management unit (e.g., provincial), the backend configuration service retrieves the configuration template specific to that level of user from the configuration center. This basic template contains metadata for all power indicator items, such as indicator codes, indicator names, and data source tables. By combining the permission control rules stored in the permission service rule engine (the core rule is that user level N is only allowed to access areas with levels > N), the configuration template is dynamically filtered to remove levels at or above the user's level, retain the lower-level area levels, and supplement each power indicator item with a "list of levels that can be analyzed", thereby generating a configuration file corresponding to the level of the user's management unit.

[0048] S206. Based on the user's user account, determine the target analysis level bound to the user account. The target analysis level shall not be lower than the level of the management unit to which the user belongs.

[0049] The user account serves as a unique identifier for grassroots power users. Users log into the system using this account, and the system identifies users by their user account when processing related requests (such as retrieving configuration files or modifying configurations). For example, when determining the target analysis level bound to a user account, matching is required through the user account. The target analysis level is an analysis level bound to the user account and is no lower than the level of the user's management unit. In special scenarios, after the administrator approves the configuration modification, additional analyzable levels can be added for users, such as adding a provincial level for provincial users, to facilitate horizontal comparative analysis.

[0050] For example, after receiving a configuration file retrieval request, the backend retrieves the corresponding permission configuration information for the user account from the user service. This information, stored in a database or cache, includes the binding relationship between the user account and the specific authorized analysis level. When a user has special needs such as horizontal comparison and the administrator approves the configuration modification, the administrator adds a configuration record for the user account in the system: "User ID - Added Analysis Level: XX", where "XX" is the target analysis level bound to the user account. The backend matches the current user account with the stored configuration records. If a corresponding configuration record exists, it extracts the level information from it as the target analysis level, and this target analysis level is not lower than the level of the user's management unit. "The target analysis level is not lower than the level of the user's management unit" means that the target analysis level is the same as or higher than the level of the user's management unit. For example, if the management unit of a grassroots electricity user in City A is at the city level (level code 2), in a special scenario, after configuration by the administrator, the target analysis level bound to that user account can be the provincial level (level code 1). In this case, the target analysis level is the same as the level of the user's management unit. If, due to business needs, the target analysis level configured for that user account is the provincial level (assuming level code 0, higher than the city level), then the target analysis level is higher than the level of the user's management unit. This setting satisfies the user's need for horizontal comparison in special scenarios and allows for flexible adjustment of the analysis level based on access control, eliminating the need for leaders to export indicator data and improving operational efficiency.

[0051] S208: Add the target analysis level to the analysis level set of the configuration file to obtain a new configuration file.

[0052] The new configuration file refers to the file created by adding the target analysis level to the analysis level set of the original configuration file corresponding to the user's management unit level. This file, when fed back to the front end, instructs the front end to render controls containing the newly added target analysis level for each power indicator item, allowing users to select the target analysis level for indicator analysis without needing to log in again.

[0053] For example, after obtaining the original configuration file corresponding to the level of the user's management unit, the backend configuration service parses the structure of the configuration file to determine the initial set of analysis levels contained in the "List of Allowed Analysis Levels" field (e.g., the field "allowedLevels"). This set only contains lower-level regional levels below the user's level (e.g., for provincial users, the initial set is [2,3,4], corresponding to city, county, and township levels). Then, after matching the target analysis level (e.g., provincial, level code 1) according to the user account, a compatibility check is performed between the target analysis level and the original set of analysis levels to ensure that the target analysis level has not been added repeatedly and complies with the permission rule of "not lower than the level of the user's management unit" (e.g., for provincial users, the target level is 1, satisfying the requirement of not lower than their level 1). Subsequently, the backend configuration service inserts the code of the target analysis level (e.g., 1) into the "List of Allowed Analysis Levels" in the original configuration file through the data processing module, forming an updated set of levels (e.g., [1,2,3,4]). Simultaneously, the system supplements the configuration file with metadata information corresponding to the target analysis level, including the range of analyzable power indicators at that level and the relationships between data source tables, ensuring that the front-end can accurately retrieve the corresponding data during rendering. The back-end repackages the updated configuration file in JSON format and sends it back to the front-end via HTTPS. The new configuration file retains the analysis permissions for lower levels in the original configuration while adding access permissions for the target analysis level, realizing dynamic expansion of the analysis level and meeting users' horizontal comparison needs. For example, after processing, the "allowedLevels" field of the configuration file for a provincial user in Province A includes provincial, municipal, county, and township levels, allowing the front-end to render an analysis level control that includes the provincial option.

[0054] S210 feeds back the new configuration file to the front end; the new configuration file is used to instruct the front end to render controls for each power indicator item that match the analysis level carried by the new configuration file.

[0055] For example, after the backend configuration service updates the configuration file, it encapsulates the new configuration file containing the target analysis level in JSON format, ensuring a clear file structure. This includes metadata for each power indicator (such as indicator code, name, and data source table) and the updated "list of allowed analysis levels" (such as including level codes for provincial, municipal, county, and township levels). Subsequently, the encapsulated new configuration file is transmitted to the frontend via HTTPS. Upon receiving the new configuration file, the frontend parses it, focusing on extracting the "allowedLevels" field for each power indicator. Combining this with the frontend's pre-defined "level code-name mapping table" (such as 1→provincial, 2→municipal, etc.), the codes are converted into user-understandable level names. Then, based on the parsing results, the frontend dynamically renders controls matching the analysis level in the new configuration file for each power indicator, such as adding a "provincial" option to the indicator's dropdown menu. Figure 3 and Figure 4 As shown in the diagram, users can directly select the newly added target analysis level (such as provincial level) through these controls. The system will then display the corresponding electricity indicator data (such as the number of complaint work orders in each province) according to that level, so that the analysis level can be adjusted and used without logging in again.

[0056] The aforementioned method for adjusting the analysis level of power indicators effectively solves the operational inconvenience and cumbersome issues existing in current power indicator analysis systems, significantly improving system flexibility and user operational efficiency. On one hand, by dynamically adding the target analysis level (no lower than the user's management unit level) bound to the user account in the configuration file, grassroots power users can directly obtain regional indicators at or above their own level for horizontal comparison in special scenarios without relying on higher-level leaders for export. This meets the actual needs of efficient analysis in grassroots operations and avoids increased collaboration costs caused by permission restrictions in traditional processes. On the other hand, the new configuration file can be directly fed back to the front end and trigger real-time interface refresh. Users can use the newly added analysis level without logging in again, simplifying the operation process, reducing time consumption caused by repeated logins, further adapting to the requirements of agile service capabilities in grassroots digital scenarios, and simultaneously achieving flexible adjustment of the analysis level within the permission control framework, balancing system security and business convenience.

[0057] In one exemplary embodiment, the configuration file retrieval request carries information including the user's region and user permission level. In response to the configuration file retrieval request, determining the user's management unit level includes:

[0058] Determine the level of the management unit to which the user belongs based on the user's region and user permission level.

[0059] The "User Location" refers to the actual administrative region to which the grassroots power user belongs, such as Province A, City B, and County C. This information identifies the user's geographical location. Within the system, this information can be determined through basic data associated with the user account or provided by the user during login or operation, used to accurately match the corresponding region's configuration file. For example, the "User Location" for a grassroots power user in Province A is "Province A." The system can retrieve the relevant power indicator configuration templates and regional hierarchy rules from the configuration center based on this information. The "User Permission Level" refers to the pre-set permission level based on the user's role and responsibilities, corresponding to the range of management unit levels the user can access, such as provincial, municipal, and county levels. This level is directly related to the level of the user's management unit and is the core basis for permission control. For example, a user with provincial permission typically corresponds to the provincial management unit level, and their permission rules limit the range of analyzable indicator levels (initially the lower-level regional level). The system can quickly determine the maximum permission boundaries of a user through the "user permission level" field. Combined with permission control rules (such as user level N is only allowed to access areas with levels > N), the system dynamically filters the configuration file to ensure that users can only access the analysis level that matches their permissions.

[0060] For example, after receiving a configuration file retrieval request carrying the user's region and permission level, the backend configuration service extracts the "user's region" information (e.g., "Province A") from the request and verifies the accuracy of the region affiliation by combining it with the basic data associated with the user account, ensuring that the region information is consistent with the records in the user registration information and role association table. The "user permission level" field (e.g., "provincial-level permission") in the request is parsed. This field corresponds to the system's preset permission level system (provincial, municipal, county, township, etc.) and forms a mapping relationship with the "maximum permission level" field in the role file. For example, "provincial-level permission" corresponds to the "maximum permission level" encoding of 1 in the role file (preset: provincial = 1, municipal = 2, etc.). The backend performs an association verification between the administrative level corresponding to the "user's region" (e.g., "Province A" corresponds to the provincial level) and the maximum permission level mapped to the "user permission level." If the two match (e.g., the region is "Province A" and the permission level is "provincial-level permission"), then the user's management unit level is determined to be provincial.

[0061] In this embodiment, a dual verification mechanism is formed by combining the user's location and permission level to determine the level of the user's management unit, significantly improving the accuracy and reliability of level determination. On one hand, the user's location ensures accurate matching of geographical location, avoiding configuration file errors due to ambiguous regional information. On the other hand, the mapping relationship between the user's permission level and the "maximum permission level" in the role file clarifies the user's permission boundaries, ensuring strict enforcement of permission control rules. This allows the system to accurately locate the user's management unit level, providing an accurate basis for subsequent configuration file selection and generation. It avoids permission abuse or insufficient permissions caused by incorrect level determination, and ensures that users can only access analysis levels that match their permissions. While meeting the needs of grassroots users for power indicator analysis, this further strengthens the system's security and standardization, improving the accuracy and efficiency of overall business processing.

[0062] In one exemplary embodiment, determining the target analytics level bound to the user account based on the user's user account includes:

[0063] If the user account carries a permission change identifier, the target analysis level is determined based on the permission change identifier carried by the user account.

[0064] The "permission change identifier" refers to a special marker carried in a user account that indicates the user has been authorized to adjust the analysis level. When a grassroots power user requests an adjustment to their analysis level due to special needs such as horizontal comparison and receives approval from the administrator, the system adds a corresponding permission change identifier to the user's account. This identifier is associated with the configuration information modified by the administrator and records the target analysis level that the user is allowed to access, which is no lower than the level of their management unit (e.g., the permission change identifier for a provincial user might correspond to "allowed access to the provincial level"). When the system determines the target analysis level based on the user account, if this identifier is detected, it can directly determine the target analysis level that the user can access based on the configuration information associated with the identifier, without needing to query complex permission configuration records. This allows for rapid dynamic adjustment of the analysis level, meeting the user's indicator analysis needs in special scenarios while ensuring the accuracy of permission control.

[0065] For example, when a user logs into the power index analysis system through the front end and initiates a configuration file retrieval request, the backend configuration service, when processing the request, will parse the user account and check whether it carries a permission change identifier. This permission change identifier is a special marker in the user account used to record the authorization for adjusting the analysis level. Its generation originates from the user's specific request—when a grassroots power user needs to conduct horizontal comparisons of regional indicators at their own level or a higher level, they can submit a configuration modification request to the administrator. After the administrator agrees, the system will add a corresponding permission change identifier to the user account. The identifier contains the target analysis level information that is allowed to be accessed (such as "provincial level" and the corresponding level code 1). After detecting the permission change identifier in the user account, the backend configuration service will verify the identifier to confirm its validity (such as whether it was generated with administrator authorization, whether it is within the validity period, etc.). After successful verification, the level information carried in the identifier is parsed and determined as the target analysis level bound to the user account, and this level is not lower than the level of the user's management unit (for example, the target analysis level for a provincial user can be provincial level).

[0066] In this embodiment, the above process can quickly identify the user's special permission configuration and directly determine the target analysis level without repeatedly querying complex permission records. This ensures the accuracy of permission control and enables dynamic adjustment of the analysis level, meeting the user's indicator analysis needs in special scenarios and improving system response efficiency.

[0067] In one exemplary embodiment, determining the target analytics level bound to the user account based on the user's user account further includes:

[0068] If the user account does not carry a permission change identifier, then the target analysis level is determined to be the level of the management unit to which the user belongs.

[0069] For example, when a user logs into the power index analysis system through the front end and initiates a configuration file retrieval request, the backend configuration service, when parsing the user account, if no permission change identifier is detected, determines the target analysis level as the level of the user's management unit according to the default rules. Specifically, the backend first determines the level of the user's management unit through the role file associated with the user account (stored in the configuration center, containing fields such as "maximum permission level"). For example, a grassroots power user in Province A is determined to belong to the provincial level (level code 1) after role matching. Since the user account does not carry a permission change identifier, it means that the user has not submitted an analysis level adjustment request or the request has not been approved by the administrator. The system does not need to perform additional permission expansion and directly determines the level of its management unit (provincial level) as the target analysis level. Subsequently, the backend configuration service will verify whether the target analysis level meets the rule of "not lower than the level of the user's management unit" (at this time, the provincial level is consistent with the level, which meets the condition), ensuring the consistency of the permission logic. At the same time, the system will integrate the target analysis level with the set of analysis levels (such as city level, county level, township level) in the original configuration file to generate a new configuration file containing the corresponding level.

[0070] In this embodiment, through the above process, even without receiving a permission change instruction, the default permission control framework can be maintained to ensure the standardization of hierarchical analysis. At the same time, by setting the level to the target analysis level, basic horizontal comparison capabilities can be provided to users (such as provincial users being able to view the same level indicators of their province and other provinces). This avoids business inconvenience caused by excessive permission restrictions and achieves a balance between default permissions and basic analysis needs.

[0071] In an exemplary embodiment, prior to the step of determining the hierarchy of the management unit to which the user belongs in response to a configuration file retrieval request, the method further includes:

[0072] Perform format validation and information integrity validation on the configuration file retrieval request;

[0073] If the format validation and information integrity validation pass, proceed with the steps to determine the user's management unit level in response to the configuration file retrieval request.

[0074] For example, after the frontend sends a configuration file retrieval request to the backend configuration service, before responding to the request and determining the user's management unit level, the system first performs format validation and information integrity validation on the request. In the format validation stage, the backend configuration service checks whether the request format conforms to preset specifications. For example, it verifies whether the request is transmitted via HTTPS, whether it is sent using a packaged HTTP request tool, whether the identity credential in the request header is in JWT encryption format, and whether the structure of the request parameters matches the preset interface specifications, ensuring the request's technical format compliance. Information integrity validation verifies whether the key information carried in the request is complete. This includes checking whether the request header contains a valid token (for identity verification), whether the request parameters carry the user's basic operational context (such as the current system module identifier to ensure the return of configuration files related to power indicator analysis), and for requests carrying the user's region and user permission level, verifying that these two pieces of information are complete and not missing, avoiding deviations in subsequent level determination steps due to incomplete key information. Only when both format validation and information integrity validation pass will the backend configuration service continue to execute subsequent steps such as responding to the configuration file retrieval request and determining the user's management unit level.

[0075] In this embodiment, this verification process can filter out requests with incorrect format or missing information in advance, ensuring the accuracy and stability of subsequent level determination and configuration file generation processes, and reducing the occupation of system resources by invalid operations.

[0076] In one exemplary embodiment, the method further includes:

[0077] If format validation or information integrity validation fails, an error message will be returned to the front end.

[0078] For example, when a configuration file retrieval request sent by the frontend fails format validation or information integrity validation, the backend configuration service generates corresponding error messages based on the specific reason for the validation failure. For instance, if the format validation fails due to the request not being transmitted via HTTPS, the token format not being JWT encrypted, or the information integrity validation fails due to a missing token in the request header or the request parameters not carrying the current system module identifier, the system will clearly identify the error type and specific reason (e.g., "Token format error, please use JWT encrypted format" or "Missing system module identifier, please complete it"). Subsequently, the backend sends this error message back to the frontend via HTTPS. Upon receiving it, the frontend displays the corresponding error message to the user in the interactive interface, guiding the user to resend a configuration file retrieval request that conforms to the format specifications and has complete information. This ensures that subsequent processes can proceed smoothly, reduces the consumption of system resources due to invalid requests, and improves the accuracy and efficiency of system processing.

[0079] 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.

[0080] Based on the same inventive concept, this application also provides an analysis level adjustment device for power indicators to implement the above-mentioned method for adjusting the analysis level of power indicators. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more embodiments of the analysis level adjustment device for power indicators provided below can be found in the limitations of the analysis level adjustment method for power indicators described above, and will not be repeated here.

[0081] In one exemplary embodiment, such as Figure 5 As shown, a device for adjusting the analysis level of power indicators is provided, comprising:

[0082] The request acquisition module 502 is used to receive a configuration file acquisition request sent by the front end when the user logs into the power index analysis system through the front end;

[0083] The configuration file determination module 504 is used to respond to the configuration file retrieval request, determine the level of the management unit to which the user belongs, and obtain the configuration file corresponding to the level of the management unit to which the user belongs; the configuration file carries a set of analysis levels; the set of analysis levels includes several analysis levels lower than the level of the management unit to which the user belongs;

[0084] The target analysis level determination module 506 is used to determine the target analysis level bound to the user account based on the user account. The target analysis level shall not be lower than the level of the management unit to which the user belongs.

[0085] The configuration file update module 508 is used to add the target analysis level to the analysis level set of the configuration file to obtain a new configuration file;

[0086] The configuration file feedback module 510 is used to feed back the new configuration file to the front end; the new configuration file is used to instruct the front end to render controls for each power indicator item that match the analysis level carried by the new configuration file.

[0087] In an exemplary embodiment, the above-described configuration file determination module 504 includes:

[0088] The user's management unit level determination unit is used to determine the level of the user's management unit based on the user's region and user permission level.

[0089] In an exemplary embodiment, the target analysis level determination module 506 includes:

[0090] The first target analysis level determination unit is used to determine the target analysis level based on the permission change identifier carried by the user account when the user account carries a permission change identifier.

[0091] In an exemplary embodiment, the target analysis level determination module 506 further includes:

[0092] The second target analysis level determination unit is used to determine the target analysis level as the level of the management unit to which the user belongs, when the user account does not carry a permission change identifier.

[0093] In an exemplary embodiment, the above-mentioned power index analysis level adjustment device further includes:

[0094] The verification module is used to perform format verification and information integrity verification on the configuration file retrieval request.

[0095] The verification execution module is used to execute the steps in response to the configuration file retrieval request and determine the level of the management unit to which the user belongs, provided that the format verification and information integrity verification have passed.

[0096] In an exemplary embodiment, the above-mentioned power index analysis level adjustment device further includes:

[0097] The "Failed Verification" module is used to return an error message to the front end if the format validation or information integrity validation fails.

[0098] Each module in the aforementioned power index analysis and adjustment 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 computer device's memory as software, so that the processor can call and execute the corresponding operations of each module.

[0099] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores configuration file data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a method for hierarchical adjustment of power indicators.

[0100] Those skilled in the art will understand that Figure 6 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.

[0101] In one exemplary 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.

[0102] 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.

[0103] 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.

[0104] 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, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0105] Those skilled in the art will understand that all or part of the processes in the methods of 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, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory 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, artificial intelligence (AI) processors, etc., and are not limited to these.

[0106] 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 application.

[0107] 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 method for adjusting the analysis hierarchy of power indicators, characterized in that, The method comprises: In the case that a user logs in a power index analysis system through a front end, a configuration file acquisition request sent by the front end is received; In response to the configuration file acquisition request, a level of a management unit to which the user belongs is determined, and a configuration file corresponding to the level of the management unit to which the user belongs is acquired; the configuration file carries an analysis level set; the analysis level set comprises a plurality of analysis levels lower than the level of the management unit to which the user belongs; According to a user account of the user, a target analysis level bound to the user account is determined, and the target analysis level is not lower than the level of the management unit to which the user belongs; The target analysis level is added to the analysis level set of the configuration file to obtain a new configuration file; The new configuration file is fed back to the front end; the new configuration file is used to instruct the front end to render controls matched with the analysis levels carried by the new configuration file for each power index item.

2. The method of claim 1, wherein, The information carried by the configuration file acquisition request comprises a region where the user is located and a user permission level, and the response to the configuration file acquisition request to determine the level of the management unit to which the user belongs comprises: According to the region where the user is located and the user permission level, the level of the management unit to which the user belongs is determined.

3. The method of claim 1, wherein, According to the user account of the user, the target analysis level bound to the user account is determined, and the target analysis level is not lower than the level of the management unit to which the user belongs. According to the user account of the user, the target analysis level bound to the user account is determined, and the target analysis level is not lower than the level of the management unit to which the user belongs.

4. The method of claim 3, wherein, Before the step of responding to the configuration file acquisition request to determine the level of the management unit to which the user belongs, the method further comprises: The configuration file acquisition request is subjected to format checking and information integrity checking; 5. The method of claim 1, wherein, If the format checking and the information integrity checking are passed, the step of responding to the configuration file acquisition request to determine the level of the management unit to which the user belongs is performed. The method further comprises: If the format checking or the information integrity checking is not passed, an error prompt is returned to the front end.

6. The method of claim 5, wherein, The device comprises: A request acquisition module is configured to, in the case that a user logs in a power index analysis system through a front end, receive a configuration file acquisition request sent by the front end; 7. A device for adjusting the analysis level of an electrical index, characterized in that, A configuration file determination module is configured to, in response to the configuration file acquisition request, determine a level of a management unit to which the user belongs, and acquire a configuration file corresponding to the level of the management unit to which the user belongs; the configuration file carries an analysis level set; the analysis level set comprises a plurality of analysis levels lower than the level of the management unit to which the user belongs; A target analysis level determination module is configured to, according to a user account of the user, determine a target analysis level bound to the user account, and the target analysis level is not lower than the level of the management unit to which the user belongs; ​ ​ A configuration file updating module is configured to add a target analysis level into the analysis level set of the configuration file to obtain a new configuration file. A configuration file feedback module is configured to feed back the new configuration file to the front end, and the new configuration file is used to instruct the front end to render a control matched with the analysis level carried by the new configuration file for each power index item.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to implement the steps of the method in any one of claims 1 to 6.

9. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 6. The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 6.

Images