To-do task processing system and method

Abstract

The embodiment of the invention provides a to-do task processing system and method, and relates to the field of information management. The system comprises a user side, a to-do system, a service system and an authority system, and the user side is configured to respond to access operation of a target user to a to-do task and send a to-do ID of the to-do task to the to-do system so as to acquire to-do template information associated with the to-do ID from the to-do system; in response to a processing operation of the target user on the to-be-handled task, sending the to-be-handled ID and the first page ID to a service system, so as to obtain page information of a first service page associated with the to-be-handled ID and the first page ID from the service system; associating the to-be-handled template ID with the first page ID, and sending the to-be-handled template ID, the first page ID, the to-be-handled ID and target user information of the target user to a permission system, so as to obtain first permission information of the target user for the first business page from the permission system; and rendering the page content based on the first permission information to present the page content to the target user.

Description

Technical Field

[0001] This invention relates to the field of information management, and in particular to a system and method for processing pending tasks. Background Technology

[0002] In to-do or approval workflow scenarios, to-do tasks (i.e., user-pending items) are widely used in various business processes. When processing a to-do task, a user needs to access the business page related to that task and complete the corresponding business operations based on that page. However, a user's access permissions are affected by their role. In some scenarios, although a user has not been granted permission to access the business page related to the to-do task in the permission system, they still need to access one or more subordinate business pages associated with that to-do task and complete the business operations corresponding to that to-do task. In this case, due to restricted permissions, the user cannot open the subordinate business pages associated with the to-do task, resulting in the to-do task not being processed effectively, thus affecting the overall business progress.

[0003] Therefore, it is necessary to provide a system and method for handling pending tasks that can dynamically authorize and revoke a user's access permissions to the subordinate business pages corresponding to the pending task based on the user's role information in the pending task, so as to ensure that the pending task can be processed smoothly. Summary of the Invention

[0004] The invention includes a task processing system. The system comprises a user terminal, a task management system, a business system, and a permission system. The user terminal is configured to: respond to a target user's access operation to a task, send the task's task ID to the task management system to obtain task template information associated with the task ID, the task template information including the task template ID; respond to the target user's processing operation on the task, send the task ID and a first page ID to the business system to obtain page information of a first business page associated with the task ID and the first page ID, the page information including page content corresponding to the first page ID; associate the task template ID with the first page ID, and send the task template ID, the first page ID, the task ID, and the target user's target user information to the permission system to obtain the target user's first permission information for the first business page; and render the page content based on the first permission information to present it to the target user.

[0005] The invention includes a method for processing pending tasks, implemented based on a pending task processing system. The method includes: responding to a target user's access operation to a pending task, sending the pending task's pending task ID to the pending task system to obtain pending task template information associated with the pending task ID, the pending task template information including the pending task template ID; responding to the target user's processing operation on the pending task, sending the pending task ID and a first page ID to a business system to obtain page information of a first business page associated with the pending task ID and the first page ID, the page information including page content and page content corresponding to the first page ID; associating the pending task template ID with the first page ID, and sending the pending task template ID, the first page ID, the pending task ID, and the target user's target user information to a permission system to obtain the target user's first permission information for the first business page from the permission system; and rendering the page content based on the first permission information to present it to the target user.

[0006] The beneficial effects of the above invention include, but are not limited to: (1) To ensure that the target user can access or process the pending tasks and smoothly access or process the corresponding first business page and common subpage, the user terminal can request the corresponding permissions from the permission system to ensure that the permissions obtained by the target user are accurately matched with the pending tasks and the first business page, so as to avoid the failure or delay of the processing of the pending tasks due to insufficient permissions; (2) In response to the user terminal detecting that the target user leaves the first business page, or the user terminal detecting that the target user has risky operations, the user terminal can disconnect the association between the first page ID and the pending template ID to reclaim the target user's permissions in the first business page, thereby enhancing the timeliness and security of permission control; (3) When the target user jumps from the first business page to the second business page, the user terminal It can determine whether the second business page is part of the to-do task processed by the target user. If so, the second permission information is obtained, realizing the continuity and consistency of permissions within the business process. If not, the to-do template ID bound to the first business page is cleared, and the third permission information is obtained, avoiding the problem of incorrectly extending permissions to unrelated pages, ensuring accurate binding and dynamic recycling of permissions, and improving the security of the to-do task processing system. (4) The user terminal can identify whether the target user has difficulty in operation or has not completed the to-do task for a long time when processing the to-do task, and determine whether to send an operation prompt request to the to-do system to obtain and display operation prompt information or a notification that no operation prompt information needs to be displayed, thereby improving the user's processing efficiency and experience, reducing the error rate of to-do task processing, and enhancing the auxiliary and intelligent level of to-do task processing. Attached Figure Description

[0007] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein: Figure 1 These are exemplary schematic diagrams of a task processing system according to some embodiments of this specification; Figure 2 This is an exemplary flowchart of a task processing procedure according to some embodiments of this specification; Figure 3 This is an exemplary flowchart illustrating the process of handling a target user's redirection operation according to some embodiments of this specification; Figure 4 This is an exemplary flowchart illustrating the verification of first authorization information according to some embodiments of this specification; Figure 5 This is an exemplary schematic diagram illustrating a task processing procedure according to some embodiments of this specification. Detailed Implementation

[0008] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.

[0009] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.

[0010] Unless the context clearly indicates an exception, words such as "a," "an," "a kind," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.

[0011] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0012] Figure 1 These are exemplary schematic diagrams of a task processing system according to some embodiments of this specification. In some embodiments, such as Figure 1 As shown, the task processing system 100 includes a user terminal 110, a task system 120, a business system 130, a permission system 140, and an operation and maintenance terminal 150.

[0013] Each of the user terminal 110, the to-do system 120, the business system 130, the permission system 140, and the operation and maintenance terminal 150 can be implemented by one or more processing devices. In some embodiments, the processing device can be a single server or a group of servers. In some embodiments, the server can include a processor, and the server group can be centralized or distributed. In some embodiments, the processing device can be local or remote. In some embodiments, the processing device can be implemented on a cloud platform. By way of example only, the cloud platform can include a private cloud, a public cloud, a hybrid cloud, or any combination thereof.

[0014] User terminal 110 refers to the terminal device used by the target user. The target user can interact with one or more of the to-do system 120, business system 130, and permission system 140 through user terminal 110. The target user is the user who needs to process the pending tasks. User terminal 110 may include mobile phone 110-1, tablet 110-2, and computer 110-3, etc.

[0015] In some embodiments, the client 110 is configured to, in response to a target user's access operation to a task, send the task's task ID to the task management system 120 to obtain task template information associated with the task ID from the task management system 120. The task template information includes the task template ID. In response to a target user's processing operation to the task, the client 110 sends the task ID and a first page ID to the business system 130 to obtain page information of a first business page associated with the task ID and the first page ID from the business system 130. The page information includes page content corresponding to the first page ID. The client 110 associates the task template ID with the first page ID and sends the task template ID, the first page ID, the task ID, and the target user's target user information to the permission system 140 to obtain the target user's first permission information for the first business page from the permission system 140. The client 110 renders the page content based on the first permission information to present it to the target user.

[0016] The to-do system 120 refers to a system used for creating and managing to-do tasks. For example, the initiator of a to-do task can create it through the to-do system 120 and set information such as the users who need to participate in the task and the completion time. In some embodiments, the to-do system 120 stores to-do templates corresponding to various types of to-do tasks. Each to-do template records the type of to-do task, the role group for that type of task, the associated business page, role permission information, etc. More information about to-do templates can be found in [link to relevant documentation]. Figure 2 Related descriptions.

[0017] Business system 130 refers to the system that processes and manages the business processes involved in pending tasks. For example, pending tasks may involve order processing, rectification, and other business processes. The person handling the pending task can process the business processes involved in the pending task through business system 130, thereby completing the pending task.

[0018] Permission system 140 refers to a system used to manage user permissions. Permission system 140 can grant temporary or permanent permissions to users based on rules, and can also revoke user permissions. Permission system 140 stores pre-stored permission information, including role permission information corresponding to multiple to-do templates. More information about pre-stored permission information can be found in [link to relevant documentation]. Figure 2 Related descriptions.

[0019] The operations and maintenance (O&M) terminal 150 refers to the terminal device used by the O&M user. The O&M user can interact with one or more of the following systems: the to-do system 120, the business system 130, and the permission system 140. The O&M user is the user who configures and manages role groups and role permission information. The O&M terminal 150 may include mobile phones 150-1, tablets 150-2, and computers 150-3, etc.

[0020] In some embodiments, the user terminal 110, the to-do system 120, the business system 130, and the permission system 140 can exchange information and / or data via a network. In some embodiments, the operation and maintenance terminal 150, the to-do system 120, the business system 130, and the permission system 140 can exchange information and / or data via a network. For example, the user terminal can obtain first permission information for a first business page from the permission system via the network. As another example, the operation and maintenance terminal can send role group and role permission information to the to-do system via the network. The network can include any suitable network that facilitates the exchange of information and / or data. For example, the network can include a local area network (LAN), a wide area network (WAN), a wired network, a wireless network, or any combination thereof. It should be understood that... Figure 1 The connection method of the components in the task processing system 100 shown can be changed. For example, the maintenance terminal 150 can communicate only with the task system 120.

[0021] In some embodiments, the to-do task processing system 100 further includes a storage device. The storage device can store data or information generated by the user terminal 110, the to-do system 120, the business system 130, the permission system 140, and the operation and maintenance terminal 150. For example, the storage device can store to-do template information. The storage device may include one or more storage device components, each of which can be a separate device or part of another device. The storage device can be local or implemented via the cloud. In some embodiments, the storage device can be implemented on a cloud platform. In some embodiments, each of the user terminal 110, the to-do system 120, the business system 130, the permission system 140, and the operation and maintenance terminal 150 has its own storage device.

[0022] Figure 2 This is an exemplary flowchart illustrating a to-do task processing procedure according to some embodiments of this specification. In some embodiments, process 200 may be executed by a user terminal.

[0023] Step 210: In response to the target user's access operation of the task to be done, the client sends the task ID to the task system to obtain the task template information associated with the task ID from the task system.

[0024] Target users refer to users who need to process pending tasks.

[0025] A pending task refers to a task assigned to a target user within a specific business process for their processing. Taking a procurement approval business process as an example, pending tasks could include filling out a procurement application, approving a procurement application, or other tasks awaiting processing. In some embodiments, pending tasks can be instantiated by the business process manager based on actual business needs by calling a pending task template, thereby generating corresponding pending tasks for the target user. For example, the business process manager can log in to the pending task system's corresponding app or webpage using their client and create a pending task to be assigned to the target user based on the pending task template; after the pending task is created, the pending task system can send a push notification for that task to the target user's client.

[0026] To-do tasks can be of various types. For example, a procurement approval process may include multiple processing steps such as procurement application, departmental approval, and financial review. Therefore, the types of to-do tasks may include different types such as application completion, application approval, or review.

[0027] An access operation refers to an action performed by a target user on their client device related to accessing a to-do task. For example, an access operation might include the target user navigating to the to-do task page, selecting a to-do task, or performing other actions related to accessing a to-do task. Another example is when the target user's client device receives a push notification from the to-do system; a prompt can be generated, and the target user can click on the to-do task in the push notification to perform the access operation.

[0028] A to-do ID is an identification information that identifies a task. In some embodiments, when a to-do system generates a task, it can generate a to-do ID for that task to identify it. The to-do ID can be generated randomly or based on preset rules, such as using a hash algorithm (e.g., MD5), an auto-incrementing ID, or a combination of a timestamp and a random number.

[0029] In some embodiments, in response to a target user's access operation to a task to be done, the client can encapsulate the task ID as a request parameter in a first request and send the first request to the task system. The first request may carry the task ID of the task to be done.

[0030] After receiving a to-do ID from the user, the to-do system can determine the to-do template information associated with that ID and send the template information back to the user. To-do template information refers to information related to the to-do template. This information may include the to-do template ID, etc. The to-do template ID is the identifying information that identifies the to-do template.

[0031] In some embodiments, the to-do system stores a first mapping relationship between multiple to-do IDs and multiple to-do templates. The to-do system can determine the to-do template corresponding to the current to-do ID based on the to-do ID currently received from the user and the first mapping relationship, and send the relevant information of the to-do template (such as the to-do template ID) as to-do template information to the user. For example, after receiving a first request, the to-do system can determine the to-do template corresponding to the to-do task based on the to-do ID and the first mapping relationship carried in the first request, and extract the to-do template ID and other information of the to-do template and return it to the user. The first mapping relationship can be established by the to-do system when the to-do task is generated, and is used to identify the to-do template associated with the to-do task.

[0032] The to-do system contains multiple to-do templates corresponding to different types of tasks. For example, it might include templates for approval tasks, procurement tasks, and security inspection tasks. Each template is a structured template associated with its specific type of task, used to standardize the creation and processing of that type of task. For instance, a to-do template records the type of task, the role group for that type of task, the associated business page, and role permission information.

[0033] A role group refers to a collection of various user roles involved in a task. For example, user roles may include initiator, processor, reviewer, approver, or archiver.

[0034] Associated business pages refer to the business pages associated with the to-do template. Each to-do template can be associated with one or more business pages. Business pages are used to present specific information related to the to-do task. A business page can include multiple page areas. For example, a business page can include page areas such as text description areas, business data display areas, graphic areas, and operation button areas. The text description areas, business data display areas, graphic areas, and operation button areas can present text descriptions, images, operation buttons, etc., related to the to-do task. Taking the procurement approval business as an example, the to-do template is "Procurement Approval Business Template". The to-do template can be associated with multiple business pages, such as a page for filling in the procurement application, a page for department heads to approve, and a page for finance personnel to review, to cover the business pages required by different user roles when processing to-do tasks.

[0035] Role permission information includes the operational permissions of each type of user role in a role group. In some embodiments, role permission information includes the permissions of each associated business page of the to-do template to each type of user role. Permissions may include access permissions, edit permissions, submit permissions, no permissions, etc. For example, assuming that the to-do template includes associated business pages A and B, and the corresponding user roles include roles 1, 2, and 3, the role permission information includes the permissions of associated business page A to roles 1, 2, and 3, and the permissions of associated business page B to roles 1, 2, and 3.

[0036] The associated business page can also include several subpages to present different business information related to the to-do task. Role permission information can further include the permissions of various user roles for the subpages of the associated business page, to support permission control of the subpages of the associated business page.

[0037] In some embodiments, role permission information may also include the target user's permissions for different page areas within the associated business page. For example, role permission information may include role 1's permission for the text description area of ​​associated business page A, but not the permission to click on the operation button area.

[0038] In some embodiments, the operations and maintenance (O&M) client is configured to accept role group and role permission information input by O&M users; and to send the role group and role permission information to the to-do system. The to-do system is configured to create a to-do template based on the role group and role permission information, assign a to-do template ID to it, and send the to-do template and the corresponding to-do template ID to the permission system.

[0039] Operations and maintenance (O&M) users are those who configure and manage role groups and role permission information. For example, an O&M user can be the administrator of an enterprise's internal to-do system. For a certain type of to-do task (such as an approval task), the O&M user can input the corresponding role group and the corresponding role permission information through the O&M terminal based on actual business needs. The O&M terminal then sends the role group and role permission information to the to-do system.

[0040] In some embodiments, the to-do system can create to-do templates based on role groups and role permission information, and assign a unique to-do template ID to each template. Specifically, after receiving the role group and role permission information, the to-do system can configure the type of to-do task, role group, role permission information, associated business page, etc., to create a to-do template and assign it a to-do template ID. The to-do template ID can be generated using a random algorithm or based on preset rules.

[0041] In some embodiments, the to-do system can send the to-do template and its corresponding to-do template ID to the permission system to update the pre-stored permission information. Specifically, the permission system can associate the to-do template with role permission information in the permission system based on the to-do template ID, thereby indicating the permissions of a user role in the to-do template on one or more associated business pages, and thus updating the pre-stored permission information. For more information on pre-stored permission information, please refer to step 230 and its description.

[0042] In some embodiments, the operation and maintenance terminal can send role groups and role permission information to the permission system; and register corresponding role permission information for each role through the permission system.

[0043] In some embodiments of this specification, by introducing role groups and role permission information, fine-grained management of permissions for various user roles is achieved; by registering role permission information in the permission system and creating to-do templates through the to-do system, the assignment of role permission information can be independently judged and controlled by the permission system without relying on the progress of the to-do system, thereby improving the real-time performance and accuracy of permission control.

[0044] Step 220: In response to the target user's processing operation of the task to be done, the user sends the task ID and the first page ID to the business system in order to obtain the page information of the first business page associated with the task ID and the first page ID from the business system.

[0045] Processing operations refer to the actions taken by the target user on the user's device related to handling pending tasks. For example, processing operations may include the target user clicking the "Process" or "View Details" button, filling out a form, uploading attachments, executing approvals, submitting data, or other processing operations related to pending tasks on the user's device.

[0046] In some embodiments, in response to the target user's processing operation of the task to be done, the user terminal can encapsulate the task ID and the first page ID as request parameters into a second request and send the second request to the business system.

[0047] The First Page ID refers to the identification information of the first business page. The First Page ID can be randomly generated or pre-generated based on preset rules, according to actual business needs.

[0048] The first business page refers to the business page that the user should be redirected to after the target user enters a processing operation. For example, taking the procurement approval business as an example, when the target user clicks the "View Details" button for the procurement approval task, the first business page can be the business page corresponding to that procurement approval task, which displays the procurement application that needs to be approved, the submitter of the procurement application, and operation buttons (such as the agree button and the reject button).

[0049] Page information refers to information related to a business page. In some embodiments, page information may include the page content corresponding to a first page ID, etc. The page content may include text, graphics, images, options, and buttons displayed in various areas of the business page. For example, the page content may be text in the text description area, graphics in the graphics area, and buttons in the operation button area of ​​the first business page corresponding to the first page ID.

[0050] In some embodiments, the user client can send the to-do ID and the first page ID to the business system. The business system can then use a lookup table to find the page information corresponding to the to-do ID and the first page ID, thereby determining the page information of the first business page, and returning the page information of the first business page to the user client. The lookup table can be generated based on the to-do template used when creating the to-do task and includes the correspondence between the to-do ID, page ID, and page information.

[0051] Step 230: The user terminal associates the to-do template ID with the first page ID, and sends the to-do template ID, the first page ID, the to-do ID, and the target user's target user information to the permission system in order to obtain the target user's first permission information for the first business page from the permission system.

[0052] Target user information refers to information related to a target user. For example, target user information may include the target user's user ID, username, token, etc. In some embodiments, in response to the target user being logged into the user's client, the client can extract the target user information based on the local login status.

[0053] The first permission information refers to the target user's permissions related to the first business page. For example, the first permission information may show that the target user has one or more of the following permissions: access permission, editing permission, and submit permission, or it may show that the target user has no permissions for the first business page. In some embodiments, the first business page contains multiple areas, and the first permission information includes the target user's permissions for each area. The permission information is similar to the role-based permission information described above and will not be repeated here.

[0054] In some embodiments, the client can associate the to-do template ID with the first page ID in various ways. For example, the client can create a mapping table and record the correspondence between the to-do template ID and the first page ID in the mapping table. Alternatively, the client can use the first page ID as the key and the to-do template ID as the value to establish a key-value pair association between the to-do template ID and the first page ID.

[0055] In some embodiments, the to-do template information further includes first subpage information of the associated business page corresponding to the to-do template ID, and the page information further includes second subpage information of the first business page. The client can determine whether the first business page and the associated business page contain a common subpage based on the first and second subpage information; in response to determining that a common subpage is contained, the to-do template ID is associated with the first page ID and the page ID of the common subpage.

[0056] The first subpage refers to a subpage under the associated business page corresponding to a specific to-do template ID. First subpage information refers to information related to the first subpage. This information may include the first subpage's page ID, page name, and navigation path. For example, if an associated business page is an approval page, then the first subpage may include subpages such as "Approval Subpage," "View Attachments Subpage," and "Flowchart Subpage" under that approval page, and the first subpage information may include the page ID and navigation path of each subpage.

[0057] The second subpage refers to a subpage of the first business page. Second subpage information refers to information related to the second subpage. This information may include the second subpage's page ID, page name, and redirect path.

[0058] In some embodiments, the client can extract information such as the page ID and jump path from the first subpage information and the second subpage information respectively, and compare the first subpage information and the second subpage information; when the first subpage information and the second subpage information have the same page ID and jump path, the client can determine that the first subpage and the second subpage are common subpages, thereby determining that the first business page and the associated business page contain common subpages.

[0059] In some embodiments, in response to determining that the first business page and the associated business page contain a common subpage, the to-do template ID is associated with the first page ID and the page ID of the common subpage. For example, this association can be achieved by recording the correspondence between the to-do template ID and the first page ID and the page ID of the common subpage in a mapping table.

[0060] In some embodiments of this specification, by determining whether the first business page and the associated business page contain a common subpage, the to-do template ID can be associated with both the first business page and the first subpage simultaneously. This eliminates the need for the authorization system to repeatedly perform role identification and authorization processes for each subpage, significantly improving the efficiency and response speed of permission issuance, and thereby enhancing the processing performance and operating efficiency of to-do tasks in scenarios with multiple business pages.

[0061] In some embodiments, the permission system is configured to query the target user's role information in the to-do task based on the target user information and the to-do ID; and to determine the target user's first permission information for the first business page based on the role information, the to-do template ID, the first page ID, and the pre-stored permission information, and send the first permission information to the user terminal. The pre-stored permission information includes role permission information corresponding to multiple to-do templates, and the role permission information reflects the permissions of each associated business page of each to-do template for various user roles.

[0062] Role information refers to the target user's role in the role group corresponding to the to-do task. For example, the target user's role in an approval task is approver. The permission system can query the target user's role information in the corresponding to-do task in the to-do system based on the target user information (such as user ID) and the to-do ID. Specifically, the permission system can send the to-do ID and the target user information to the to-do system; the to-do system can query the target user's role information in the to-do task corresponding to the to-do ID based on the second mapping relationship and return the role information to the permission system.

[0063] The second mapping relationship is pre-stored in the to-do system, reflecting the mapping relationship between to-do tasks, users, and roles. This second mapping relationship can be determined based on the users corresponding to each role entered by the user when creating the to-do task. For example, in a procurement approval business process, if the role group in the to-do template includes initiator, approver, and financial reviewer, then when instantiating and creating a procurement approval task, the user needs to enter user A as the initiator, user B as the approver, and user C as the financial reviewer, etc.

[0064] Pre-stored permission information refers to the role permission information corresponding to multiple to-do templates. It can indicate the permissions of various user roles in the to-do template for each associated business page of the to-do template. In some embodiments, as described in step 230, after the to-do system generates the to-do template and the corresponding to-do template ID, it sends the to-do template and the corresponding to-do template ID to the permission system. The permission system can extract the permissions of each associated business page in each to-do template for each user role from the received information and store it as pre-stored permission information.

[0065] In some embodiments, the permission system can retrieve the role permission information corresponding to the to-do template corresponding to the to-do template from the pre-stored permission information based on the to-do template ID; based on the target user's role information and the first page ID, it can find the associated business page corresponding to the first page ID in the role permission information of the to-do template, and extract the access permissions, editing permissions, submission permissions, etc. that the target user's corresponding role has on the business page, as the target user's first permission information for the first business page.

[0066] In some embodiments, the first permission information may further include the target user's access permissions, editing permissions, and submission permissions to common subpages contained in the first business page and the associated business page.

[0067] In some embodiments, in response to a target user performing a processing operation on a common subpage of a first business page and an associated business page, the user terminal can send the to-do template ID, the page ID of the common subpage, the to-do ID, and the target user's target user information to the permission system. The permission system can determine the target user's first permission information for the common subpage based on the target user's role information, the to-do template ID, the page ID of the common subpage, and pre-stored permission information. Determining the target user's first permission information for the common subpage is similar to determining the target user's first permission information for the first business page, and will not be repeated here. For more information on how to determine that the first business page and the associated business page contain a common subpage, please refer to other parts of this specification.

[0068] In some embodiments, the permission system may send first permission information to the user terminal.

[0069] In some embodiments, in response to the absence of an associated business page matching the first page ID in the to-do template, the client can determine that the first business page corresponding to the first page ID is a page unrelated to the to-do task and return inherent permission information to the client. More information regarding inherent permission information can be found elsewhere in this specification.

[0070] In some embodiments of this specification, by introducing pre-stored permission information, the permission system can directly match and determine the first permission information from the pre-stored permission information, thereby avoiding real-time permission calculation and improving the processing efficiency and response speed of the permission system. Furthermore, the pre-stored permission information includes role permission information corresponding to multiple to-do templates, making the pre-stored permission information highly scalable and reusable, facilitating role permission allocation in different business scenarios. By having the permission system centrally generate the first permission information, sensitive permissions are avoided from being exposed, which is beneficial to the consistency of permission control.

[0071] Step 240: The client renders the page content based on the first permission information to present it to the target user.

[0072] Rendering page content based on first permission information refers to displaying, hiding, or disabling page content or parts thereof based on the target user's first permission information, so that the page content presented to the user is consistent with their permissions.

[0073] In some embodiments, after the permission system sends the first permission information to the user terminal, the user terminal can verify the permissions of the first permission information. Specifically, the user terminal can verify the text description area, graphic area, and operation button area of ​​the first business page according to the access permission, editing permission, and submit permission in the first permission information to determine whether the target user has the corresponding permissions for the above-mentioned page areas; based on the verification results of each area, the corresponding page content is rendered to be presented to the target user. For example, the user terminal can determine that the text description area requires access permission and editing permission, the graphic area requires access permission, and the operation button area requires submit permission; the user terminal can determine whether the target user has these permissions according to the first permission information and control the display, editing ability, or operable state of the above-mentioned page areas respectively. If the target user lacks the required permissions for a certain area, the user terminal can hide the area or set it to a read-only or unclickable state.

[0074] In some embodiments, process 200 further includes step 250.

[0075] Step 250: In response to the target user's exit operation on the first business page, the user client can clear the to-do template ID associated with the first page ID.

[0076] The "leave" operation refers to the action taken by the target user to jump from the first business page to another business page or to close the first business page.

[0077] In some embodiments, in response to a target user leaving the first business page, the client can clear the mapping relationship between the pending template ID and the first page ID in the mapping table, or clear the key-value pair association between the pending template ID and the first page ID, so as to clear the pending template ID associated with the first page ID.

[0078] In some embodiments of this specification, since the first permission information is generated based on the to-do template ID associated with the first page ID, by clearing the to-do template ID associated with the first page ID, the first business page corresponding to the first page ID will no longer be regarded as the associated business page corresponding to the to-do template. This makes the first permission information immediately invalid when the target user leaves the first business page, thereby realizing the dynamic release and revocation of permissions and preventing permission leakage or unauthorized access.

[0079] In some embodiments of this specification, a to-do template ID is introduced to obtain the target user's first permission information for the first business page, thereby enabling the permission system to allocate permissions to different to-do tasks. During the processing of to-do tasks, the user requests permissions from the permission system by carrying the to-do template ID associated with the first page ID. This ensures that the target user's first permission information accurately matches the to-do task and the first business page they are processing, avoiding processing failures or delays due to insufficient permissions. Simultaneously, the permission system supports dynamic updating or revocation of the target user's permissions across different business pages, enhancing the timeliness and security of permission control, and improving the efficiency, accuracy, and security controllability of to-do task processing.

[0080] Figure 3 This is an exemplary flowchart illustrating the process of handling a redirection operation for a target user according to some embodiments of this specification. Flow 300 can be executed by the user terminal.

[0081] Step 310: The client receives the target user's redirection operation from the first business page to the second business page.

[0082] A navigation action refers to the action of a target user jumping from one business page to another on a user's device. For example, a navigation action can include clicking a navigation button on a business page, clicking a link on a business page, selecting a drop-down menu option, or other interactive behaviors.

[0083] The second business page refers to the new business page that the target user enters after being redirected from the first business page. The second business page corresponds to a second page ID. The second page ID is the identification information of the second business page. The second page ID can be randomly generated or pre-generated based on preset rules, according to actual business needs.

[0084] Step 320: The user terminal determines whether there is a relationship between the second business page and the to-do template ID.

[0085] As described in step 230, in response to determining that the first business page and the associated business page contain a common subpage, the client can associate the to-do template ID with the first page ID and the page ID of the common subpage. If the second business page is a common subpage, the second page ID of the second business page has been associated with the to-do template ID; if it is not a common subpage, no association has been made. In some embodiments, the client can determine whether there is an association between the second business page and the to-do template ID based on the mapping table described above.

[0086] Step 330: In response to determining that the second business page is associated with the to-do template ID, the to-do template ID, the second page ID of the second business page, the to-do ID, and the target user information are sent to the permission system to obtain the target user's second permission information for the second business page.

[0087] Secondary permission information refers to the permission information of the target user for the secondary business page. For example, secondary permission information may include the target user's access permissions, editing permissions, submission permissions, approval permissions, etc. for the secondary business page.

[0088] In some embodiments, in response to determining that the second business page is associated with the to-do template ID, it indicates that the second business page is determined to be a subpage of the first business page. The user can directly send the to-do template ID, the second page ID, the to-do ID, and the target user's target user information to the permission system. The permission system can determine the target user's second permission information for the second business page based on the target user's role information, the to-do template ID, the second page ID, and pre-stored permission information. The process of determining the target user's second permission information for the second business page is similar to that of determining the target user's first permission information for the first business page, and will not be described again here.

[0089] Step 340: In response to determining that the second business page is not associated with the to-do template ID, the user terminal clears the to-do template ID associated with the first business page and sends the second page ID and target user information to the permission system to obtain the target user's third permission information for the second business page.

[0090] The third permission information refers to the permission information for the second business page determined based on the target user's inherent permission information. Inherent permission information refers to permission information that is permanently bound to the user. Inherent permission information can be the basic permissions applicable to the user in performing all types of to-do tasks. Inherent permission information can be assigned based on the user's identity, position, organization, etc. For example, for a user with the role of a finance manager, their inherent permission information may include access to the financial approval page, editing permissions for the budget submission page, etc. Even if the user is not assigned a specific to-do task, they can still access parts of the relevant pages or perform certain operations based on their inherent permission information.

[0091] In some embodiments, the operation and maintenance user can pre-set inherent permission information for each user based on actual business needs through the operation and maintenance terminal and send it to the permission system. The permission system can register inherent permission information for each user.

[0092] In some embodiments, the permission system can determine the inherent permission information of the target user based on the target user information, and query the permissions that the target user has for the second business page based on the inherent permission information and the second page ID, as the third permission information. For example, the permission system queries the business system for the page content corresponding to the second business page based on the second page ID, and determines the permissions that the target user has for each area of ​​the second business page based on the inherent permission information, and uses these permissions as the third permission information.

[0093] In some embodiments, after the permission system sends third permission information to the user terminal, the user terminal can verify the permission of the third permission information; upon response and completion of permission authentication, the user terminal can render page content based on the third permission information to present it to the target user. The permission verification of the third permission information is similar to that of the first permission information and will not be described again here. For more information on how to verify the first permission information, please refer to step 240 and its explanation.

[0094] In some embodiments of this specification, when a target user navigates from a first business page to a second business page, the user terminal can determine whether the second business page is associated with the to-do template ID. If an association exists, it indicates that the second business page is part of the to-do task being processed by the target user. In this case, the second permission information can be obtained through the to-do template ID, the second page ID, the to-do ID, and the user information, thus achieving the continuity and consistency of permissions within the business process. If no association exists, the to-do template ID bound to the first business page is cleared, and the third permission information is obtained. This avoids the problem of incorrectly extending permissions to unrelated pages, ensures accurate binding and dynamic revocation of permissions, and improves the security of the to-do task processing system.

[0095] It should be noted that the above description of process 300 is for illustrative purposes only and does not limit the scope of this specification. Those skilled in the art can make various modifications and changes to the process under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.

[0096] Figure 4 This is an exemplary flowchart illustrating the verification of first authorization information according to some embodiments of this specification. Figure 4 As shown, process 400 includes the following steps. In some embodiments, process 400 may be executed by a user terminal.

[0097] Step 410: The user client requests the inherent permission information of the target user from the permission system.

[0098] In some embodiments, the client may send target user information to the permission system to obtain the target user's inherent permission information from the permission system.

[0099] Step 420: The user terminal determines whether the first permission information is consistent with the inherent permission information.

[0100] In some embodiments, the client can extract the first permission information of the target user to the first business page and the inherent permission information corresponding to the target user, and compare the permissions in the first permission information and the inherent permission information; if the permissions in the first permission information and the inherent permission information are inconsistent, it is determined that the first permission information and the inherent permission information are inconsistent.

[0101] Step 430: In response to the determination that the first permission information is inconsistent with the inherent permission information, the user terminal sends an operation prompt request to the to-do system to obtain the operation prompt information corresponding to the to-do task or a notification that no operation prompt information needs to be displayed from the to-do system.

[0102] An operation prompt request refers to a request related to operation prompts on a business page. For example, an operation prompt request might request information about editable areas of a business page, instructions for using the submit button, or prompts for operational steps the user needs to follow. When the initial permission information and inherent permission information are inconsistent, it indicates that there are some matters on the current initial business page that the target user is unfamiliar with or has never handled before. Operation prompt information can be provided to the target user to guide them in handling pending tasks. In some embodiments, the operation prompt request may carry the target user's information, to-do ID, etc.

[0103] Operation prompts refer to information related to the specific operation process of a business page, used to guide users in completing the operations on the business page. For example, operation prompts may include explanations of editable areas on the business page, instructions on using the submit button, or the order of operations that users must follow when processing pending tasks. In some embodiments, operation prompts can be entered by maintenance users through the maintenance terminal and sent to the to-do system according to business needs. The to-do system can then preset corresponding operation prompts for different related business pages in the to-do template.

[0104] In some embodiments, after receiving an operation prompt request, the to-do system can determine whether there is pre-stored operation prompt information for the to-do task corresponding to the to-do ID. If so, the operation prompt information is sent to the user's client. If not, a notification is sent that the operation prompt information does not need to be displayed.

[0105] In some embodiments, the to-do system may execute steps 431-433 to determine whether to return an operation prompt message to the user or return a notification that no operation prompt message needs to be displayed.

[0106] Step 431: Based on the target user's historical to-do processing records, the to-do system determines the target user's historical processing count and historical average processing time for similar to-do tasks.

[0107] Historical task processing records refer to the processing operations of a target user when performing various tasks in the past. For example, historical task processing records can include the correspondence between task type, number of processing attempts, and time taken for each processing attempt. Historical task processing records can be pre-built based on historical data or prior knowledge.

[0108] In some embodiments, the to-do system can determine the to-do task corresponding to the to-do ID based on the target user information and the to-do ID, and determine the historical processing count and historical average processing time of similar to-do tasks by the target user based on historical to-do processing records. For example, the to-do system can extract to-do tasks of the same or similar type as the current to-do task from historical to-do processing records, and calculate the historical processing count and historical average processing time of these to-do tasks.

[0109] Step 432: In response to determining that the historical processing count is less than the count threshold or the historical average processing time exceeds the time threshold, the to-do system obtains the operation prompt information corresponding to the to-do task and sends it to the user terminal. The count threshold and time threshold can be preset based on actual business needs.

[0110] In some embodiments, in response to determining that the historical processing count is less than a threshold or the historical average processing time exceeds a time threshold, indicating that the target user has little experience in handling similar tasks or spends a lot of time, the task management system can obtain operation prompts from the task template corresponding to the task and send the operation prompts to the user's terminal. For example, the operation prompts may be explanatory text explaining when to use the submit button, or a brief operation guide reminding users of the approval process steps.

[0111] In some embodiments, the client may render page content based on operation prompts to present it to the target user.

[0112] Step 433, or in response to determining that the number of historical processing attempts is not less than the number threshold and the historical average processing time does not exceed the time threshold, the to-do system sends a notification to the user that no operation prompt information needs to be displayed.

[0113] In some embodiments, in response to determining that the number of historical processing times is not less than a threshold and the historical average processing time does not exceed a time threshold, indicating that the target user has more experience in handling similar tasks and spends less time, the task system can return a notification that no operation prompt information needs to be displayed. The user can then skip the display of the operation prompt information based on this notification, thereby avoiding rendering any content related to the operation prompt.

[0114] In some embodiments of this specification, in response to determining that the target user's historical processing count for similar tasks is less than a preset threshold, or the historical average processing time exceeds a preset time threshold, it indicates that the target user may have difficulty or be unfamiliar with processing the current task. Therefore, operation prompts are obtained and sent to the user to assist the target user in successfully completing the task. In response to determining that the target user's historical processing count for similar tasks is not less than a preset threshold and the historical average processing time does not exceed a preset time threshold, it indicates that the target user is familiar with processing the current task and has high efficiency. In this case, a notification is sent to the user that operation prompts do not need to be displayed to avoid redundant prompts interfering with the user's operation.

[0115] Step 440: In response to the target user's current processing time exceeding the time threshold, the user terminal sends an operation prompt request to the to-do system again to obtain operation prompt information.

[0116] In some embodiments, the client can monitor the current processing time of the target user on the first business page; in response to the target user's current processing time exceeding a time threshold, the client sends an operation prompt request to the to-do system again to obtain operation prompt information.

[0117] Step 450: Monitor the target user on the client side to see if there are any risky operations performed on the first business page.

[0118] In some embodiments, the client can also monitor whether the target user performs any risky actions on the first business page. For example, risky actions may include, but are not limited to, taking screenshots, copying, screen recording, data exposure due to prolonged inactivity on the first business page, or other actions that violate page access security policies.

[0119] Step 460: In response to the detection of a risky operation, the client clears the to-do template ID associated with the first page ID and re-requests the inherent permission information of the target user from the permission system.

[0120] In some embodiments, in response to the detection of a risky operation, the client can clear the to-do template ID associated with the first page ID, so that the first business page corresponding to the first page ID will no longer be regarded as the associated business page of the to-do template, thereby invalidating the first permission information; the client can then request the inherent permission information of the target user from the permission system again based on the target user information. For details on how to request the inherent permission information of the target user from the permission system, please refer to step 410.

[0121] In some embodiments, the permission system can send the inherent permission information of the target user to the user's client.

[0122] Step 470: The client renders the page content based on the inherent permission information to present it to the target user.

[0123] In some embodiments, after the permission system sends inherent permission information to the user terminal, the user terminal can verify the inherent permission information. Upon response and completion of permission authentication, the user terminal can render page content based on the inherent permission information to present it to the target user. The permission verification of the inherent permission information is similar to that of the first permission information and will not be described again here. For more information on how to verify the first permission information, please refer to step 240 and its explanation.

[0124] In some embodiments of this specification, if the target user's current processing time exceeds a time threshold, it indicates that the target user has not completed the pending task for an extended period and is experiencing operational difficulties. Therefore, an operation prompt message can be retrieved again and sent to the user's terminal to guide the target user to complete the pending task promptly. By monitoring the target user's risky operations and removing the pending template ID associated with the first page ID upon detecting a risky operation, the first permission information can be immediately invalidated, and the inherent permission information can be returned. This method effectively prevents permission abuse and information leakage, improving the security and responsiveness of the permission control in the pending task processing system.

[0125] In some embodiments of this specification, by comparing the target user's first permission information on the first business page with its inherent permission information, it can be determined whether the target user has long-term operational experience or ability on that page. In response to a discrepancy, the user terminal can display operation prompts to guide the target user to better understand and execute the current task. This method helps identify whether the target user has operational obstacles, and improves user processing efficiency and experience through operation prompts, reducing the error rate of task processing and enhancing the assistance and intelligence level of task processing.

[0126] It should be noted that the above description of process 400 is for illustrative purposes only and does not limit the scope of this specification. Those skilled in the art can make various modifications and changes to the process under the guidance of this specification. However, these modifications and changes remain within the scope of this specification.

[0127] Figure 5 This is an exemplary schematic diagram illustrating a task processing procedure according to some embodiments of this specification.

[0128] like Figure 5 As shown, in response to the target user's access operation of the task to be done, the user can send the task ID of the task to the task system through the first request.

[0129] The to-do system can identify the to-do template information associated with the to-do ID and return the to-do template information and to-do information to the user. To-do information refers to information related to the to-do task, such as the to-do deadline, a detailed description of the to-do task, and the person who assigned it.

[0130] The client can display the to-do information corresponding to the tasks to be done.

[0131] In response to the target user's processing operation of the pending task, the user can send the pending task ID and the first page ID to the business system through a second request.

[0132] The business system can return the page information of the first business page corresponding to the to-do ID and the first page ID to the user.

[0133] The client can associate the to-do template ID in the to-do template information with the first page ID, and send the to-do template ID, first page ID, to-do ID and target user information of the target user to the permission system.

[0134] The permission system can send the to-do template ID and the target user's information to the to-do system; the to-do system can query the target user's role information in the to-do tasks and return that role information to the permission system.

[0135] The permission system can determine the target user's first permission information for the first business page based on role information, to-do template ID, first page ID, and pre-stored permission information, and return the first permission information to the user's client.

[0136] The client can render page content based on the first permission information and present it to the target user.

[0137] In response to a target user leaving the first business page, the user client can clear the to-do template ID associated with the first page ID.

[0138] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.

[0139] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.

[0140] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.

[0141] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.

[0142] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values ​​are set as precisely as feasible.

[0143] For each patent, patent application, patent application publication, and other material such as articles, books, specifications, publications, and documents referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.

[0144] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.

Claims

1. A task processing system, characterized in that, This includes a user client, a to-do system, a business system, and a permission system, wherein the user client is configured as follows: In response to the target user's access operation of the task to be done, the task ID of the task to be done is sent to the task system to obtain the task template information associated with the task ID from the task system. The task template information includes the task template ID. In response to the target user's processing operation on the pending task, the pending task ID and the first page ID are sent to the business system to obtain the page information of the first business page associated with the pending task ID and the first page ID from the business system. The page information includes the page content corresponding to the first page ID. The to-do template ID is associated with the first page ID, and the to-do template ID, the first page ID, the to-do ID, and the target user information of the target user are sent to the permission system to obtain the target user's first permission information for the first business page from the permission system; and The page content is rendered based on the first permission information and presented to the target user.

2. The task processing system according to claim 1, characterized in that, The permission system is configured as follows: Based on the target user information and the to-do ID, query the target user's role information in the to-do task in the to-do system; as well as Based on the role information, the to-do template ID, the first page ID, and the pre-stored permission information, the first permission information of the target user on the first business page is determined, and the first permission information is sent to the user terminal. The pre-stored permission information includes role permission information corresponding to multiple to-do templates, and the role permission information reflects the permissions of each associated business page of each to-do template to various user roles.

3. The task processing system according to claim 1, characterized in that, The system also includes an operations and maintenance terminal, configured to: accept role group and role permission information input by operations and maintenance users; and send the role group and role permission information to the to-do system; The to-do system is configured to: create a to-do template based on the role group and the role permission information, and assign a to-do template ID to it; the to-do template records the role group and the role permission information corresponding to the to-do template ID; and send the to-do template and the corresponding to-do template ID to the permission system.

4. The task processing system according to claim 1, characterized in that, The user terminal is further configured as follows: In response to the target user's exit operation on the first business page, the to-do template ID associated with the first page ID is cleared.

5. The task processing system according to claim 1, characterized in that, The to-do template information further includes the first subpage information of the associated business page corresponding to the to-do template ID, and the page information further includes the second subpage information of the first business page. Associating the to-do template ID with the first page ID includes: Based on the first subpage information and the second subpage information, determine whether the first business page and the associated business page contain a common subpage; In response to determining that the common subpage is included, the to-do template ID is associated with the first page ID and the page ID of the common subpage.

6. The task processing system according to claim 5, characterized in that, The user terminal is further configured as follows: In response to the target user's navigation from the first business page to the second business page, determine whether the second business page is associated with the to-do template ID; In response to determining that the second business page is associated with the to-do template ID, the to-do template ID, the second page ID of the second business page, the to-do ID, and the target user information are sent to the permission system to obtain the target user's second permission information for the second business page; or In response to determining that the second business page is not associated with the to-do template ID, the to-do template ID associated with the first business page is cleared, and the second page ID and the target user information are sent to the permission system to obtain the target user's third permission information for the second business page.

7. The task processing system according to claim 1, characterized in that, The user terminal is further configured as follows: Request the inherent permission information of the target user from the permission system; Determine whether the first permission information is consistent with the inherent permission information; In response to determining that the first permission information is inconsistent with the inherent permission information, an operation prompt request is sent to the to-do system to obtain the operation prompt information corresponding to the to-do task or a notification that the operation prompt information does not need to be displayed from the to-do system.

8. The task processing system according to claim 7, characterized in that, The operation prompt request includes the target user information, and the to-do system is further configured as follows: Based on the target user's historical to-do processing records, determine the target user's historical processing frequency and historical average processing time for similar to-do tasks. In response to determining that the historical processing count is less than a count threshold or the historical average processing time exceeds a time threshold, the system obtains the operation prompt information corresponding to the pending task and sends it to the user terminal; or In response to determining that the number of historical processing attempts is not less than a threshold and the average historical processing time does not exceed a time threshold, a notification is sent to the user terminal that the operation prompt information does not need to be displayed.

9. The task processing system according to claim 8, characterized in that, The user terminal is further configured as follows: In response to the target user's current processing time exceeding the time threshold, the operation prompt request is sent again to the to-do system to obtain the operation prompt information; Monitor whether the target user performs any risky operations on the first business page; In response to the detection of the risky operation, the to-do template ID associated with the first page ID is cleared, and the inherent permission information of the target user is requested again from the permission system; The page content is rendered based on the inherent permission information and presented to the target user.

10. A method for processing pending tasks, characterized in that, The method is implemented based on a task processing system, which includes a processor, a user terminal, a task system, a business system, and a permission system. The method includes: In response to the target user's access operation of the task to be done, the task ID of the task to be done is sent to the task system to obtain the task template information associated with the task ID from the task system. The task template information includes the task template ID. In response to the target user's processing operation on the pending task, the pending task ID and the first page ID are sent to the business system to obtain the page information of the first business page associated with the pending task ID and the first page ID from the business system. The page information includes the page content corresponding to the first page ID. The to-do template ID is associated with the first page ID, and the to-do template ID, the first page ID, the to-do ID, and the target user information of the target user are sent to the permission system to obtain the target user's first permission information for the first business page from the permission system; and The page content is rendered based on the first permission information and presented to the target user.

Images