Enterprise and micro SCRM sidebar project aggregation method and storage medium

Abstract

The invention discloses an enterprise micro SCRM sidebar project aggregation method and a storage medium. The invention relates to the technical field of SCRM service development. An administrator inputs the URL, the icon, the label name and the corresponding authority information of each function entry in a management interface, wherein the authority information comprises cities, crowds and tenants. The permission information is sent to a server through a POST request, and the server verifies and stores the permission information in a database. Through the unified background management system, an administrator can complete configuration and permission setting of all function entrances at a time, and the management cost and time consumption are greatly reduced. By means of the centralized management mode, operation during organizational structure adjustment or permission change is quicker and more consistent. And moreover, the dynamically generated access control rule automatically limits the access permission of the user, manual wrong configuration is avoided, and the accuracy and the safety of permission management are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of SCRM business development, and in particular to a method and storage medium for aggregating sidebar items in a micro-enterprise SCRM system. Background Art

[0002] In the development practice of WeChat Enterprise SCRM business, the demand for integrating project pages into chat interfaces is growing, which requires the system to be able to flexibly and efficiently connect to various service provider (SP) resources. The traditional method relies on the manual configuration of the joint debugging toolbar entry for each service in the background, which is not only time-consuming and labor-intensive, but also as the number of SPs increases, the management of page entries becomes extremely cumbersome. This process not only requires SPs and customers to personally intervene in the background operations, but also lacks automation and centralized management mechanisms, which easily leads to configuration errors and service interruptions, resulting in unnecessary economic losses and user experience damage. More importantly, WeChat Enterprise does not currently directly support third-party platforms to directly access and conduct unified configuration management, further exacerbating this management problem.

[0003] In response to the above challenges, the existing solutions seem to be stretched. The mainstream solution strategy is to consult the official documents of WeChat for Business and clarify that WeChat for Business has not yet opened interfaces or documents that allow third-party platforms to directly intervene in the customer's backend configuration, but it cannot achieve unified configuration management across customers. On the other hand, although there is a method of trying to obtain access_token through code scanning authorization to indirectly call the WeChat for Business backend interface for configuration, this method essentially still relies on the interaction of each user, and cannot fundamentally solve the pain points of large-scale deployment and personalized configuration in a multi-tenant environment. Frequent code scanning login operations not only fail to reduce the workload, but may be resisted by SPs and customers due to operational complexity and potential security risks.

[0004] Therefore, the current technical problems to be solved are:

[0005] (1) During the creation phase of a micro-enterprise organization, how to preset the sidebar project entry framework for the entire organization through a one-time aggregation configuration operation.

[0006] (2) How to uniformly control all function page entrances of the enterprise micro-blog sidebar and support multi-dimensional configuration (such as by city, tenant or specific user group), so as to achieve configuration flexibility and efficiency and reduce the management burden of SP and customers.

[0007] To this end, the present invention proposes a sidebar project aggregation method and storage medium for Enterprise SCRM. Summary of the invention

[0008] In view of this, the present invention hopes to provide a method and storage medium for aggregating items in the sidebar of the enterprise micro SCRM to solve or alleviate the technical problems existing in the prior art; the technical solution of the present invention is implemented as follows:

[0009] 1. Overview:

[0010] By adding a set of functions to the management background, which is specifically used for the centralized management of the function entry addresses of the enterprise micro-sidebar, including the addition, deletion, modification and permission verification of addresses (based on city, population, tenant and other dimensions), centralized maintenance operations can provide SPs and customers with a unified configuration interface, greatly simplifying the configuration process and ensuring the accuracy and efficiency of the configuration. By introducing the cloud control interface to achieve real-time data distribution, the content displayed in the sidebar can be dynamically adjusted according to different access environments (such as user roles, geographic locations, etc.). At the same time, the function entry list is aggregated by adding a new Tab category. Reduce large-scale changes to the existing architecture and reduce implementation costs. Use JavaScript's window.location.href redirection technology to achieve fast jumps between pages, and add a back component to enhance navigation friendliness, so that users can switch between multiple function pages smoothly and naturally.

[0011] It is proposed to extract the login logic of all aggregated pages, realize the unified login processing of Tab pages, and combine the cache strategy with the unified injection of micro-enterprise capabilities to improve the page loading speed and user experience. By reducing the authentication request at each page load and preparing the necessary micro-enterprise API resources in advance, the opening rate of Tab function pages can be effectively improved, and the system responsiveness can be enhanced.

[0012] (II) Technical solution:

[0013] To achieve the above technical objectives, the present invention needs to perform the following implementation steps:

[0014] 2.1 Step S1, initialization configuration:

[0015] The administrator configures the backend through secure login, reads the entry function details and permission rules, and dynamically generates a personalized access control system based on this.

[0016] 2.1.1 Step S100, configuration information entry:

[0017] The administrator enters the URL, icon, tag name and corresponding permission information of each function entrance in the management interface. The permission information includes city, group and tenant. The permission information is sent to the server through a POST request, and the server verifies and stores it in the database.

[0018] 2.1.3 Step S101, traverse and set permission rules:

[0019] Dynamically generate access control rules based on configuration, so that users can only see and access the authorized function entrances. The process includes:

[0020] S1010, connect to the database: The server uses the ORM (Object-Relational Mapping) tool or directly establishes a connection with the database through SQL statements. If you use the Python Django framework, you can use the ORM model to query the FeatureAccess table;

[0021] S1011, executing a rule generation algorithm: based on the permission rules represented by a preset data structure (such as a dictionary, a mapping table or a graph data structure, layered by city, population group, and tenant, each layer containing authorized function entrances), traverse each record retrieved from the database, and add it to the corresponding permission structure according to the city, population group, and tenant;

[0022] S1012, Optimization and merging: Optimize the generated permission structure, including removing empty items and merging duplicate rules to ensure that the rule set is efficient and has no redundancy;

[0023] S1013, specific implementation method of rule implementation: serialize the rule set and store it in a cache system (such as Redis), and load the generated permission rule set into the access control module of the system;

[0024] S1014, write access control logic: in the entry point of the system (such as API gateway, middleware or custom authentication class), parse the user's request header, cookie or token to determine the city, population group and tenant to which they belong, in order to check the user's identity and permissions;

[0025] S1015, dynamic update: pull the latest permission rules from the cache in real time or periodically to ensure that permission changes can be applied even without restarting the service.

[0026] 2.2 Step S2, data distribution and presentation:

[0027] Based on user identity, the cloud control interface is used to filter and push personalized function entrances to the client in real time. The client dynamically builds an interface to display to the user.

[0028] 2.2.1 Step S200, log in to the enterprise micro:

[0029] When the end user logs in to the WeChat Enterprise client, the system verifies the user's identity through the OAuth2 protocol and records the login status. The WeChat Enterprise client initiates a request to the cloud control interface, and the request contains a user identifier, which includes the user ID, role, and city.

[0030] 2.2.2 Step S201, data screening and push:

[0031] The cloud control service selects the function entry list visible to the user based on the user ID and preset permission rules, and pushes it to the client in real time through WebSocket or polling. It includes the following execution steps:

[0032] S2010, user identification matching: the cloud control service first receives the login information or session identification of the client and confirms the unique identity of the current active user;

[0033] S2011, permission rule query: Based on the user ID, the cloud control service queries the pre-set permission database or cached rules to read the multi-dimensional access rights of different user groups to functions, including user roles, departments, and geographic locations;

[0034] S2012, filter function entrances: Based on the queried multi-dimensional access rights, the server logic filters out all function entrances that the user has access to, including URLs, icons, labels and other information, to form a concise and personalized function list.

[0035] S2013 implements real-time push mechanism with two solutions:

[0036] 1) WebSocket: If the WebSocket protocol is used, the cloud control service establishes or uses an existing WebSocket connection to send the filtered function list directly to the client. This method provides full-duplex communication, and data transmission is instant and efficient;

[0037] 2) Polling: The client sends a request to the server at a preset time interval, and the server responds by returning only the changed data or the entire updated function list. Although not as real-time as WebSocket, it is a feasible solution in environments that do not support WebSocket;

[0038] S2014, data encapsulation and transmission: The filtered data is encapsulated into JSON data format to ensure efficient transmission to the client.

[0039] 2.2.3 Step S202, dynamically construct the sidebar:

[0040] After receiving the data, the client uses JavaScript to dynamically build a sidebar to display the tab categories and function entrances that meet the user's permissions. This includes executing the following steps:

[0041] S2020, receiving data: the client's JavaScript code listens to message events from WebSocket or processes polling responses, and receives function entry data pushed by the server;

[0042] S2021, Parse data: Use JSON.parse() to convert the received string data into a JavaScript object for further DOM (Document Object Model) operations;

[0043] S2022, DOM manipulation: Use native JavaScript libraries or jQuery libraries to dynamically create the HTML structure of the sidebar based on the received data. 、 , Elements such as , generate a clickable item for each function entrance;

[0044] S2023, permission display logic: if a user does not have permission to access a certain function, the corresponding menu item will not be generated, otherwise it will be generated;

[0045] S2024, event binding: bind a click event to each function entry. When the user clicks, use JavaScript to navigate to the URL of the corresponding function.

[0046] 2.3 Step S3, user interaction and data processing:

[0047] The page jumps caused by user navigation operations, the intelligent cache strategy accelerates loading, and the unified and seamless login verification mechanism are executed in sequence to achieve a page switching experience.

[0048] 2.3.1 Step S300, Tab click and page jump:

[0049] When the user clicks a tab in the sidebar, a JavaScript event is automatically triggered, and the browser address is changed using window.location.href to redirect the page. The process includes:

[0050] S3000, event listening: When the page is loaded, the JavaScript code binds a click event listener to each Tab button through the addEventListener method;

[0051] S3001, trigger jump: When the user clicks a Tab, the listener captures the event and executes a function that uses the window.location.href attribute to modify the URL of the current browser address bar, thereby achieving page jump to the corresponding function page.

[0052] 2.3.2 Step S301, page loading and caching:

[0053] When a new page is loaded, the local cache is checked. If there is cache, it is used directly to achieve a quick opening experience; if there is no cache, the page data is requested from the server and the data is cached locally for subsequent quick access. The execution process is:

[0054] S3010, check local cache: At the beginning of page loading, the JavaScript code first checks whether the browser's localStorage or sessionStorage has cached data for the page;

[0055] S3011, cache hit processing: If the cache exists, read the page data directly from the cache, use methods such as document.open() and document.write() or directly operate the DOM to quickly render the page, achieving a second-opening experience;

[0056] S3012, cache miss processing: If the required data is not in the cache, an Ajax request is sent to the server to obtain the page content. After the request is successful, in addition to rendering the page, the response data is also stored in the local cache for quick loading next time.

[0057] 2.3.3 Step S302, unified login verification:

[0058] When using single sign-on (SSO) to access a new page for the first time, if the user has not logged in under the tab, the system automatically calls the unified login verification interface and continues to load the page content after successful verification. The execution process is:

[0059] S3020, check login status: At the beginning of loading a new page, JavaScript checks local storage (cookies) or calls a backend API to confirm the user's current login status and session validity;

[0060] S3021, SSO authentication request: If it is detected that the user has not logged in under the current tab (or the login status is invalid), a background request is automatically initiated to the unified login verification interface. The request carries a token with necessary authentication information;

[0061] S3022, background verification: The server verifies the validity of the ticket and confirms the user's identity and permissions. If the verification is successful, the server will return a response confirming that the login is valid;

[0062] S3023, continue to load the page: after the front end receives a successful login response, it continues to load the remaining content of the page. The user does not need to log in again, thus achieving a seamless cross-tab experience.

[0063] S3024, maintain login status synchronization: When using SSO, inform other tabs through the event bus to update the login status to maintain consistency.

[0064] 2.3.4 Step S303, back and switch operation:

[0065] By adding a return component to the page and using JavaScript to monitor user click events, smooth switching and back operations between pages can be achieved by modifying window.history.

[0066] (III) Mechanism for solving technical problems:

[0067] 3.1 One-time aggregate configuration operation, unified control and multi-dimensional configuration:

[0068] Through the initial configuration process of step S1 in 2.1, especially the S100 configuration information entry, the administrator is allowed to enter all function entrances and their permission rules in the background at one time, including URLs, icons, label names, and permission information divided by city, population, and tenant. This information is submitted to the server through a POST request and stored persistently, presetting a flexible and scalable sidebar project framework for the entire organization. This process simplifies configuration work, reduces duplication of work, and ensures uniformity and standardization at the organizational level.

[0069] 2.1.3 Steps S101 to S1015 show how to dynamically generate access control rules based on the entered permission information. These rules are highly flexible and can be finely controlled by city, tenant or specific user group. Through database query, permission rule algorithm generation, optimization merging and storage in cache, efficient execution and real-time update of rules are ensured. This series of steps builds a powerful permission management system that supports rapid response to changes in organizational structure or permission requirements.

[0070] 3.2 Achieve configuration flexibility and efficiency:

[0071] Step S2 of 2.2 utilizes the cloud control interface to dynamically filter and push personalized function portals to the client in real time according to the identifier provided by the user when logging in. Combined with the WebSocket or polling mechanism, it ensures that the user sees the sidebar layout that matches their permissions immediately after logging in, which improves the user experience and system response speed.

[0072] Step S3 of 2.3 further optimizes the user experience through intelligent page jump logic, efficient caching strategy and unified login verification mechanism. In particular, the page caching strategy significantly improves the page loading speed, and the integration of SSO ensures that users do not need to log in repeatedly when switching between different functions, simplifying the operation process.

[0073] (IV) Compared with the prior art, the beneficial effects of the present invention are:

[0074] (1) Improve management efficiency: Through a unified backend management system, the present invention enables administrators to complete the configuration and permission settings of all functional entrances at one time, greatly reducing management costs and time consumption. This centralized management method makes operations when adjusting the organizational structure or changing permissions faster and more consistent. In addition, dynamically generated access control rules automatically limit user access rights, avoid manual misconfiguration, and improve the accuracy and security of permission management.

[0075] (2) Enhanced user experience: The present invention pushes personalized function portals in real time based on the user's role, department, city, and other information, ensuring that each user only sees the functions that are relevant to them and for which they have permission, thereby improving usage efficiency and enhancing user satisfaction. At the same time, the cache strategy and SSO login verification mechanism reduce page loading time and enable fast switching between pages, allowing users to experience a smooth and unimpeded experience during use.

[0076] (3) Flexibility and scalability: The present invention supports the configuration of function entrances according to multiple dimensions (cities, tenants, specific user groups). This flexibility can adapt to the diverse organizational structure and business needs of enterprises and is easy to adjust and expand as the enterprise grows. In addition, the latest permission rules are pulled from the cache in real time or regularly, ensuring the instant update of system rules. Permission adjustments can be completed without downtime, which facilitates the continuous optimization and upgrade of the system.

[0077] (4) Advanced technology stack: The present invention utilizes modern technologies such as ORM, WebSocket, SSO, etc., which not only improves the development efficiency and performance of the system, but also ensures the advanced technology stack and future maintainability. BRIEF DESCRIPTION OF THE DRAWINGS

[0078] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0079] Figure 1 It is a schematic diagram of the method flow of the present invention. DETAILED DESCRIPTION

[0080] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0081] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0082] Example: Figure 1 As shown, this embodiment discloses a method for aggregating sidebar items of a micro-enterprise SCRM, which needs to perform the following steps S1 to S3.

[0083] In this embodiment, regarding step S1, initialization configuration: the administrator configures the backend through secure login, reads the input function entry details and permission rules, and dynamically generates a personalized access control system based on them.

[0084] Specifically, step S100, configuration information entry: the administrator logs in to a highly secure background management system with an intuitive user interface. In this interface, the administrator enters detailed information for each function entrance one by one, including access URL, icon resources, label names displayed in the sidebar, and the most critical permission information. Permission information is subdivided into three dimensions: city, specific group of people (such as sales team, customer service team) and tenants, to ensure that the granularity of permission division is fine enough to meet the needs of different organizational structures. These data are sent to the server through a secure POST request. After receiving the request, the server first performs a legitimacy check (such as checking the integrity of the permission information, the correctness of the format, etc.), and then stores the valid data persistently in the database.

[0085] Furthermore, the Java underlying code for the backend processing of the configuration information entry in step S100 is as follows. The FeatureAccessService class is responsible for processing the entry of configuration information:

[0086]

[0087]

[0088] Specifically, in step S101, traverse and set the permission rules:

[0089] Dynamically generate access control rules based on configuration, so that users can only see and access the authorized function entrances. The process includes:

[0090] Connect to the database (S1010): The server uses ORM tools. For example, in the Python Django framework, the ORM model simplifies database operations and automatically maps database tables to Python classes, making querying the FeatureAccess table direct and efficient. This step ensures that the permission data can be read quickly and accurately. If implemented through Spring Data JPA or other ORM frameworks, the query method is directly defined in the Repository interface:

[0091]

[0092]

[0093] Execution rule generation algorithm (S1011): Based on the permission records retrieved from the database, the system runs an algorithm to dynamically build a permission rule system. This algorithm uses a data structure (such as a multi-level dictionary or graph) to organize the permission information of cities, groups, and tenants layer by layer, ensuring that each layer only contains the functional entrances that users at that layer are authorized to access. Such a hierarchical structure clearly reflects the hierarchical relationship of permissions and is easy to manage and expand. The underlying Java code is as follows:

[0094]

[0095]

[0096] The access control logic is implemented in the controller or filter of the API. Take Spring Security as an example:

[0097]

[0098]

[0099] Optimize and merge rules (S1012): The generated permission rules are optimized, such as removing unnecessary empty items and merging overlapping rules, to improve the execution efficiency of the rule set, reduce memory usage, and ensure the response speed of the system.

[0100] Rule implementation (S1013): In order to improve the efficiency of access control, the optimized rule set is serialized and stored in a high-performance cache system (such as Redis). In this way, the system does not need to directly query the database every time a user requests, but quickly obtains permission information from the cache, which greatly improves the response speed of the access control module.

[0101] Execute access control logic (S1014): In the application entry layer (API gateway, middleware) or custom authentication module, implement logic to identify the user (by parsing the request header, cookie or JWT token), and determine whether the user has the right to access the requested function entry based on the city, population group and tenant to which the user belongs, and compare the permission rules in the cache. This process ensures the real-time and accuracy of permission control.

[0102] Dynamic update mechanism (S1015): An automatically or manually triggered mechanism that refreshes the permission rules from the cache periodically or when the permission information changes. Permission changes can take effect immediately without restarting the service, ensuring stable operation of the system while being flexible.

[0103] It is understandable that the multi-dimensional configuration capability of step S1 allows for precise control of the visibility of function entrances according to different dimensions, meeting the personalized needs under complex organizational structures. By dynamically generating access control rules, the configuration takes effect immediately, greatly improving management efficiency. The administrator only needs to configure once, and the subsequent permission control is completely handled automatically by the system, reducing frequent manual adjustments and reducing the operation and maintenance workload of SPs and customers. With the help of the cache system to store permission rules, the frequency of database access is reduced, and the system response speed and overall performance are improved.

[0104] In this embodiment, regarding step S2, data distribution and presentation: based on user identity, the cloud control interface is used to filter and push the personalized function entrance to the client in real time, and the client dynamically constructs an interface to display to the user.

[0105] Specifically, step S200, logging into the enterprise micro, includes:

[0106] S2000, OAuth2 protocol verification: This step ensures the security and legitimacy of the user's identity. When the user logs in to the enterprise micro client, the authentication is completed through the OAuth2 protocol, which not only simplifies the user login process, but also enhances security, because the user credentials will not be directly exposed to the sidebar application, but indirectly verified through the authorization code or token.

[0107] S2001, record login status and user identification transmission: After successful login, the system records the user status and prepares for the subsequent personalized function push through identification information such as user ID, role and city. This information is the basis for building a personalized interface.

[0108] Specifically, step S201, data screening and push: the cloud control service screens the function entry list visible to the user according to the user identification and the preset permission rules, and pushes it to the client in real time through WebSocket or polling. It includes the following execution steps:

[0109] S2010, user identification matching: the cloud control service first receives the client's login information or session identification to confirm the unique identity of the current active user; the cloud control service uniquely determines the active user through the user identification, which is the premise for personalized configuration push;

[0110] S2011, permission rule query: Based on the user ID, the cloud control service queries the pre-set permission database or cached rules to read the multi-dimensional access rights of different user groups to functions, including user roles, departments, and geographic locations;

[0111] S2012, filter function entrances: Based on the multi-dimensional access rights queried, the server logic filters out all function entrances that the user has access to, including URL, icon and label information, to form a concise and personalized function list. Based on the query results, a unique function list for each user is dynamically generated to ensure that the sidebar content seen by each user is customized according to their permissions, improving the user experience and system security.

[0112] S2013 implements real-time push mechanism with two solutions:

[0113] 1) WebSocket: If the WebSocket protocol is used, the cloud control service establishes or uses an existing WebSocket connection to send the filtered function list directly to the client. This method provides full-duplex communication, and data transmission is instant and efficient;

[0114] 2) Polling: The client sends a request to the server at a preset time interval, and the server responds by returning only the changed data or the entire updated function list. Although not as real-time as WebSocket, it is a feasible solution in environments that do not support WebSocket;

[0115] S2014, data encapsulation and transmission: The filtered data is encapsulated into JSON data format to ensure efficient transmission to the client.

[0116] Specifically, step S202, dynamically building a sidebar: after receiving the data, the client uses JavaScript to dynamically build a sidebar to display the tab categories and function entrances that meet the user's permissions. This includes executing the following steps:

[0117] S2020, receiving data: the JavaScript code on the client listens to the message events from the WebSocket or processes the polling response, and receives the function entry data pushed by the server;

[0118] S2021, Parse data: Use JSON.parse() to convert the received string data into a JavaScript object for further DOM (Document Object Model) operations;

[0119] S2022, DOM manipulation: Use native JavaScript libraries or jQuery libraries to dynamically create the HTML structure of the sidebar based on the received data. 、 、 Elements such as , generate a clickable item for each function entrance;

[0120] S2023, permission display logic: if a user does not have permission to access a certain function, the corresponding menu item will not be generated, otherwise it will be generated;

[0121] S2024, event binding: bind a click event to each function entry. When the user clicks, use JavaScript to navigate to the URL of the corresponding function.

[0122] It is understandable that in step S2, users only see the functions that are relevant to them and that they have access to, which avoids information overload and improves the convenience and efficiency of operations. Centralized management and real-time configuration distribution through cloud control services reduces the tediousness of manual configuration and updates, and reduces the maintenance burden of system administrators and customers. Multi-dimensional configuration support enables the system to adapt to different organizational structures and user role requirements, and quickly adjusts as the organization changes, without the need to frequently update client software.

[0123] Furthermore, the Java underlying code of step S2 is as follows:

[0124]

[0125]

[0126] In the above program, CustomWebSocketHandler inherits from

[0127] TextWebSocketHandler, overrides the afterConnectionEstablished method, which is triggered when the WebSocket connection between the client and the server is established. Here, the user details are obtained from the database through the user ID, and the list of functions that the user has access to is further obtained. In UserService, the getFunctionsForUser method first obtains the user information based on the user ID, and then queries the permission rules related to the user. These rules may be stored in a separate table, associated with user roles, departments, cities and other attributes. After that, all function entries are traversed, and the permissionService.isUserAllowed method is used to filter out the functions that the user has access to according to the rules. The filtered function list is converted into a JSON string and pushed to the client in real time using the sendMessage method of WebSocket. In this way, the front end can receive a filtered list of functions that meet the user's permissions and dynamically build a sidebar based on it.

[0128] In this embodiment, regarding step S3, user interaction and data processing: page jumps caused by user navigation operations, intelligent cache strategy accelerated loading, and a unified and seamless login verification mechanism are sequentially executed to achieve a page switching experience.

[0129] Specifically, step S300, Tab click and page jump: After the page DOM is loaded, JavaScript uses document.addEventListener('DOMContentLoaded', function(){...}) to ensure that the DOM is fully loaded before executing event binding. For each Tab button, use element.addEventListener('click', function(event){...}) to register a click event listener. This mechanism ensures that even dynamically generated Tabs can be correctly monitored.

[0130] Furthermore, the execution process of step S300 includes:

[0131] S3000, event monitoring: When the page loads, JavaScript code passes

[0132] The addEventListener method binds a click event listener to each Tab button;

[0133] S3001, trigger jump: When the user clicks Tab, the logic in the listener is triggered, and the URL in the browser address bar is instantly changed using window.location.href = 'target URL', prompting the page to jump to the corresponding function page. This method directly utilizes the browser's navigation mechanism to achieve simple and intuitive page switching.

[0134] Specifically, step S301, page loading and caching: when a new page is loaded, the local cache is checked. If there is a cache, it is used directly to achieve a second-opening experience; if there is no cache, the page data is requested from the server, and the data is cached locally for subsequent quick access.

[0135] Furthermore, the execution process of step S301 is as follows:

[0136] S3010, check local cache: In the JavaScript of the new page, use if(localStorage.getItem('pageKey')) to check whether there is cache data for the specified page. Here, 'pageKey' is a key value representing the content of a specific page;

[0137] S3011, cache hit processing: If the cache exists, use var cachedData =

[0138] JSON.parse(localStorage.getItem('pageKey')); Get cached data and quickly render the page through DOM operations such as document.getElementById('content').innerHTML = cachedData.content to achieve an almost instantaneous loading experience;

[0139] S3012, cache miss processing: When the cache is missing, initiate an asynchronous Ajax request (fetch(url).then(response=>response.json()).then(data=>{...})) to obtain the page content and render the page using a similar method as before.

[0140] localStorage.setItem('pageKey',JSON.stringify(data)); Store the data in the local cache to prepare for the next access acceleration.

[0141] Specifically, step S302, unified login verification: when using single sign-on (SSO) to access a new page for the first time, if the user has not logged in under the Tab, the system automatically calls the unified login verification interface, and continues to load the page content after the verification is successful.

[0142] Furthermore, the execution process of step S302 is as follows:

[0143] S3020, detect login status: when the page is initialized, use

[0144] if(document.cookie.includes('sessionToken')) or call the API to check the user login status and confirm whether there is a valid login session;

[0145] S3021, SSO authentication request: If you are not logged in or your login has expired, initiate an Ajax request to the SSO authentication interface, and carry the necessary authentication information in the request, such as the ticket extracted from the cookie (fetch(' / api / auth / verify',{headers:{'Authorization':'Bearer'+

[0146] getTokenFromCookie()}});

[0147] S3022, background verification: The front end allows the page to continue loading based on the successful verification response, ensuring that the user does not need to log in again when switching between different tabs;

[0148] S3023, continue to load the page: after the front end receives a successful login response, it continues to load the remaining content of the page. The user does not need to log in again, thus achieving a seamless cross-tab experience.

[0149] S3024, maintain login status synchronization: through Event Bus or BroadcastChannel and other technologies, notify other tabs to update the user's login status to ensure the consistency of the login status in the entire application.

[0150] Specifically, step S303, back and switch operations: bind an event listener to the back button (document.getElementById('backButton').addEventListener('click',function(){window.history.back();});), and use the window.history.back() method to achieve smooth backing of the page, maintaining good navigation continuity.

[0151] It is understandable that step S3 significantly speeds up page loading through intelligent caching strategies, reduces user waiting time, and improves overall fluency and satisfaction. The unified login verification mechanism ensures that users do not need to log in repeatedly on each functional page when moving within the application, enhancing the seamlessness of the user experience. The caching strategy reduces unnecessary server requests, reduces server load, and optimizes the use of network resources. Maintaining login status synchronization ensures that users can maintain consistency in login status no matter which part of the application they are in, avoiding confusion or operation interruption caused by inconsistent status.

[0152] Furthermore, the Java underlying logic of step S3 is as follows:

[0153]

[0154]

[0155]

[0156]

[0157] In the above program, this Java code snippet provides a login authentication interface in the form of a RESTful API. The front end sends a JSON request containing the username and token to

[0158] / api / auth / verify, the backend AuthResource class handles this request.

[0159] The tokenService.validateToken() method simulates the logic of verifying the validity of the Token, that is, decrypting the Token, checking whether the Token is expired, and the user permissions corresponding to the Token, etc. Based on the verification result, the backend returns the corresponding HTTP response to inform the frontend whether the login is successful.

[0160] When the front-end needs to obtain cache data for a certain page, it initiates a GET request to / api / cache / {pageKey}, and the back-end looks up the corresponding data from the cache service and returns it. If the front-end needs to set (or update) the cache, it sends the page data in JSON format to the same endpoint via a POST request, and the back-end saves the data to the cache.

[0161] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0162] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0163] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. The method for aggregating items in the sidebar of the micro-enterprise SCRM is characterized by: The steps include: S1, initial configuration: through the secure login configuration background, read the entry function entry details and permission rules, and dynamically generate a personalized access control system based on this; S2, data distribution and presentation: based on user identity, the cloud control interface is used to filter and push personalized function entrances to the client in real time. The client dynamically builds an interface to display to the user; S3, user interaction and data processing: execute page jumps caused by user navigation operations, intelligent caching strategies to accelerate loading, and unified and seamless login verification mechanisms in sequence to achieve page switching.

2. The project aggregation method according to claim 1, characterized in that: In S1, the implementation method of entering the function entry and the permission rules is: S100, the administrator enters the URL, icon, tag name and corresponding permission information of each function entrance in the management interface, and the permission information includes city, group and tenant; the permission information is sent to the server through a POST request, and the server verifies and stores it in the database; S101, S101, dynamically generate access control rules according to the configuration, so that users can only see and access their authorized function entrances.

3. The project aggregation method according to claim 2, characterized in that: The implementation method of S101 is: S1010, connecting to database: the server establishes a connection with the database; S1011, based on the permission rules represented by the preset data structure, traverse each record retrieved from the database and add it to the corresponding permission structure according to the city, population group and tenant; S1012, removing empty items from the generated authority structure; S1013, serializing the rule set and storing it in a cache system, so as to load the generated permission rule set into the access control module of the system; S1014, parse the user's request header, cookie or token at the system entry point to determine the city, population group and tenant to which the user belongs, so as to check the user's identity and authority.

4. The project aggregation method according to claim 1, characterized in that: In S2, the screening and pushing method is: the cloud control service screens out a list of function entrances visible to the user according to the user identification and preset permission rules, and pushes it to the client in real time through WebSocket or polling.

5. The project aggregation method according to claim 4, characterized in that: In S2, the execution steps of the cloud control service are: S2010, the cloud control service receives the login information or session identifier of the client and confirms the unique identity of the current active user; S2011, based on the user identification, the cloud control service queries the pre-set permission database or cached rules to read the multi-dimensional access rights of different user groups to the functions; S2012: Based on the queried multi-dimensional access rights, the server logic filters out all the function entrances that the user has access to; S2013, execute real-time push; S2014, data encapsulation and transmission: The filtered data is encapsulated into JSON data format and transmitted to the client.

6. The project aggregation method according to claim 5, characterized in that: In the S2, it also includes dynamically building a sidebar: after the client receives the data, it uses JavaScript to dynamically build a sidebar to display Tab categories and function entrances that comply with user permissions.

7. The project aggregation method according to claim 1, 2 or 4, characterized in that: In the S3, the page jump, the intelligent cache strategy accelerated loading and the unified and seamless login verification mechanism are implemented as follows: S300, when the user clicks a tab in the sidebar, a JavaScript event is automatically triggered to change the browser address and realize page jump; S301, when a new page is loaded, the local cache is checked. If there is a cache, it is used directly; if there is no cache, the page data is requested from the server and the data is cached locally for subsequent access; S302, when using single sign-on to access a new page for the first time, if the user has not logged in under the Tab, the system automatically calls the unified login verification interface, and continues to load the page content after the verification is successful.

8. The project aggregation method according to claim 7, characterized in that: In the S301, the execution process is as follows: S3010, at the initial stage of page loading, check whether the browser has cached data of the page; S3011, if the cache exists, directly operate the DOM and read the page data from the cache; S3012, if the required data is not in the cache, an Ajax request is sent to the server to obtain the page content; After the request is successful, in addition to rendering the page, the response data will also be stored in the local cache for the next load.

9. The project aggregation method according to claim 7, characterized in that: In the S302, the execution process is as follows: S3020, at the beginning of loading a new page, checking the local storage to confirm the user's current login status and session validity; S3021, if it is detected that the user has not logged in under the current Tab, a background request is automatically initiated to the unified login verification interface; S3022, confirm the user's identity and permissions; if the verification is successful, the server will return a response confirming that the login is valid; S3023: After the front end receives a successful login response, it continues to load the remaining content of the page. The user does not need to log in again, thus achieving a seamless cross-Tab experience. S3024, when using SSO, inform other tabs through the event bus to update the login status to maintain consistency.

10. A storage medium, characterized in that: The storage medium stores program instructions that can implement the project aggregation method as described in any one of claims 1-9.

Images