A method for transmitting information and a storage medium

Abstract

This invention provides a method for sending an information body and a storage medium. The method includes: acquiring a general domain operation request sent by a business domain system; determining a target permission code based on business association information and the general domain request; determining the user identification information of the target user based on the target permission code and a permission code mapping table; generating a first user set based on the user identification information of the target user; and transmitting the business association information, the general domain request, and the first user set to the general domain system, so that the general domain system can generate a target information body based on the business association information and the general domain request, and send the target information body to the target user. This method executes computer instructions stored in a computer-readable storage medium after they are read. Through this method, the general domain system can send information bodies only to users who truly possess the corresponding business permissions, ensuring accurate delivery of information bodies and effectively avoiding information redundancy caused by sending to irrelevant users.

Description

Technical Field

[0001] This specification relates to the field of computer information technology, and in particular to a method for transmitting information and a storage medium. Background Technology

[0002] In business scenarios such as project management and enterprise resource planning, business domain systems typically need to send information to specific users, such as approval tasks, to-do items, or message notifications, to drive business process flow.

[0003] Currently, information is distributed widely but lacks specificity, resulting in users receiving many useless push notifications. Furthermore, the level of granularity in personnel permission management makes it difficult to accurately deliver information, thus affecting users' work efficiency.

[0004] Therefore, it is desirable to provide a method for sending information and a storage medium that can ensure the accurate delivery of information and improve users' work efficiency and user experience. Summary of the Invention

[0005] The invention includes a method for sending an information body. The method includes: acquiring a general domain operation request sent by a business domain system, the general domain operation request including business association information and a general domain request; determining a target permission code based on the business association information and the general domain request; determining user identification information of one or more target users based on the target permission code and a permission code mapping table; the permission code mapping table including a mapping relationship between user identification information and permission codes; generating a first user set based on the user identification information of the one or more target users; and transmitting the business association information, the general domain request, and the first user set to the general domain system, so that the general domain system generates a target information body based on the business association information and the general domain request, and sends the target information body to the one or more target users.

[0006] The invention includes a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions in the storage medium, the computer executes the information transmission method described above.

[0007] Beneficial effects: This method enables the general domain system to send information only to users who actually have the corresponding business permissions, ensuring accurate information delivery and effectively avoiding information redundancy caused by sending to irrelevant users, thereby improving user work efficiency and user experience. Attached Figure Description

[0008] 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:

[0009] Figure 1 This is a schematic diagram illustrating an application scenario of the information body transmission method according to some embodiments of this specification;

[0010] Figure 2 This is an exemplary flowchart of an information body transmission method according to some embodiments of this specification;

[0011] Figure 3 These are exemplary schematic diagrams of page views shown according to some embodiments of this specification;

[0012] Figure 4 This is an exemplary flowchart illustrating the determination of a permission code mapping table according to some embodiments of this specification;

[0013] Figure 5 This is an exemplary block diagram of an information transmission system according to some embodiments of this specification. Detailed Implementation

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

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

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

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

[0018] Figure 1 These are schematic diagrams illustrating application scenarios of the information transmission method according to some embodiments of this specification. For example... Figure 1 As shown, the application scenario of the information body sending method (hereinafter referred to as application scenario 100) may include server 110, storage device 120, network 130, user terminal 140 and user 150.

[0019] Server 110 refers to a processing device used to perform an information body transmission method. In some embodiments, server 110 may be a single server or a group of servers. The server group may be centralized or distributed (e.g., server 110 may be a distributed system). In some embodiments, server 110 may be local or remote. For example, server 110 may access information and / or data stored in storage device 120 and client 140 via network 130.

[0020] In some embodiments, server 110 may be implemented on a cloud platform. By way of example only, a cloud platform may include a private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, cross-cloud, multi-cloud, or any combination thereof.

[0021] Storage device 120 can be used to store data and / or instructions. For example, storage device 120 can store permission code mapping tables, business association information, etc. In some embodiments, storage device 120 can store information and / or instructions for execution or use by server 110 to perform the information body transmission method provided in this specification. In some embodiments, storage device 120 may include mass storage, removable storage, volatile read-write storage, read-only storage (ROM), etc., or any combination thereof.

[0022] In some embodiments, storage device 120 may be part of server 110 or an external storage device existing independently of server 110. In some embodiments, storage device 120 may be implemented on the aforementioned cloud platform.

[0023] Network 130 can be configured to facilitate the exchange of information and / or data. In some embodiments, one or more components in application scenario 100 (e.g., server 110, storage device 120, client 140) can send information and / or data to other components in application scenario 100 via network 130. In some embodiments, network 130 can be any type of wired or wireless network, or any combination thereof. For example, network 130 may include cable networks, wired networks, fiber optic networks, telecommunications networks, intranets, the Internet, local area networks (LANs), wide area networks (WANs), wireless local area networks (WLANs), metropolitan area networks (MANs), public switched telephone networks (PSTNs), Bluetooth networks, ZigBee networks, near field communication (NFC) networks, etc., or any combination thereof.

[0024] User terminal 140 refers to one or more terminal devices used by user 150. In some embodiments, user terminal 140 may include mobile devices, tablet computers, laptop computers, desktop computers, etc., or any combination thereof. In some embodiments, mobile devices may include smart home devices, wearable devices, smart mobile devices, virtual reality devices, augmented reality devices, etc., or any combination thereof.

[0025] In some embodiments, the user terminal 140 can be used to present the interactive interface of a business domain system (e.g., a web page or client) so that the user can initiate a business request; the user terminal 140 can also be used to present the interactive interface of a general domain system (e.g., instant messaging software) so as to receive and display target information bodies.

[0026] User 150 refers to the individual operating the user terminal 140. In some embodiments, user 150 may be the initiator of a business request (e.g., an employee submitting an expense report) or the recipient of the target information (e.g., a manager with approval authority). In some embodiments, user 150 may also be a system maintenance personnel.

[0027] In some embodiments, user 150 can initiate an operation request to server 110 (such as a business domain system) through client 140. Server 110 can receive the request through network 130 and use the permission code mapping table stored in storage device 120 to determine the target user, thereby generating the target information body. Subsequently, server 110 (specifically a general domain system) can send the target information body to the client 140 of one or more target users for display through network 130.

[0028] For more information on the above, please see [link to relevant documentation]. Figures 2 to 5 And its related descriptions.

[0029] It should be noted that application scenario 100 is provided for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can make various modifications or variations based on the description in this specification. For example, application scenario 100 can implement similar or different functions on other devices. However, these changes and modifications will not depart from the scope of this specification.

[0030] Figure 2 This is an exemplary flowchart illustrating an information body transmission method according to some embodiments of this specification. Figure 2 As shown, process 200 includes steps 210 to 250. In some embodiments, process 200 may be executed by server 110.

[0031] Step 210: Obtain the general domain operation request sent by the business domain system.

[0032] A business domain system refers to a computer system or software module responsible for processing specific business logic and managing business data. In some embodiments, a business domain system may include at least one of the following business-related transaction systems: task management system, attendance management system, work record management system, payroll management system, cost management system, quality management system, or safety management system. For example, a business domain system may be an enterprise's internal ERP (Enterprise Resource Planning) system.

[0033] A generic domain operation request refers to a data packet or instruction generated by a business domain system in order to trigger a specific operation in the generic domain system.

[0034] A general domain system refers to a computing system or software module used to provide information transmission, collaborative office work, unified messaging services, or human-computer interaction interfaces. In some embodiments, the general domain system is primarily responsible for performing general operations on data, such as generating and distributing different types of information bodies such as messages, to-do lists, approvals, and data. The general domain system can also serve as a unified output channel for different business domain systems, transforming business information into a user-readable or operable format. In some embodiments, the general domain system may include at least one of enterprise-level instant messaging (IM) tools, collaborative office (OA) platforms, email systems, SMS service platforms, or unified to-do centers. In some embodiments, the general domain system is also used to carry inherent functions extracted from specific business scenarios; these inherent functions include basic service capabilities that can be reused across businesses, such as personnel organizational structure maintenance and big data management.

[0035] In some embodiments, the general domain system may also provide an application programming interface (API) to receive data sent by the business domain system and generate corresponding cards, messages, or pop-ups.

[0036] In some embodiments, a general domain operation request includes business association information and a general domain request.

[0037] Business-related information refers to data relevant to the current business scenario. For example, business-related information may include key fields such as region, specialty, responsibility, and business order number. As another example, business-related information may include project number, contract amount, applicant name, and approval document ID. In some embodiments, server 110 can extract business-related information from the data fields of a general domain operation request based on predefined protocols or field mapping relationships. For example, server 110 can extract the business-related information from the business context (e.g., the project environment to which the current operation belongs), user permissions (e.g., the job role of the current user), and business documents (e.g., the specific form data filled in the document).

[0038] A generic domain request refers to a request message that instructs a generic domain system to execute a logical intent or target. Examples include approval flow requests, message requests, and pending task requests initiated by users in a business domain system. For instance, a generic domain request might instruct "send a notification to personnel with approval authority for a specific project" or "create a pending task." Understandably, generic domain requests guide the generic domain system on which type of permission or role should be matched. For example, a generic domain request might be a target project objective, such as "preliminary budget review for project A" or "contract review for region B."

[0039] In some embodiments, server 110 can extract the generic domain request from the data field of the generic domain operation request according to a predefined protocol or field mapping relationship. In some embodiments, server 110 can also determine the generic domain request according to the current operation scenario. For example, server 110 can identify the specific business scenario that triggers the generic domain operation request (e.g., whether it is in the "submit application" stage or the "result announcement" stage), and map the corresponding generic domain request (e.g., "seek approval" or "send announcement notice") based on the operation scenario.

[0040] It should be noted that the aforementioned general domain operation requests are typically generated based on user-triggered actions on the business page. In some embodiments, to ensure that users can only trigger general domain operation requests they are authorized to perform, the business domain system will pre-authenticate the page and generate a page view containing specific trigger controls. Server 110 can obtain the authentication request sent by the business domain system; based on user identification information and page identification information, it determines the authentication result and sends the authentication result to the business domain system. For more details, please refer to [link to relevant documentation]. Figure 3 And its related descriptions.

[0041] In some embodiments, the general domain operation request is generated by the business domain system based on a preset business event.

[0042] Preset business events refer to state changes or operational behaviors that occur within a business domain system and are predefined to trigger external notifications or processing. In some embodiments, preset business events may include data creation, updating, deletion, or state transitions. For example, business events may include "submission of new project initiation application," "budget approval," "contract amount change," or "trigger of regular project progress reporting task," etc. In some embodiments, the business domain system can monitor whether the aforementioned preset business events occur through event listeners, database triggers, or scheduled task schedulers.

[0043] In some embodiments, when a preset business event is detected, the business domain system can automatically generate a pending business event, parse the pending business event, and extract relevant business data as business association information. For example, the project ID "P001" and the project amount "1 million" can be extracted from the "Project Application Submission" event. Furthermore, the business domain system can determine the corresponding general domain request based on the type of the pending business event. For example, if the event is "Approval Submission," the general domain request is determined to be "Find the approver and send pending tasks"; if the event is "Approval Approved," the general domain request is determined to be "Find the applicant and send a notification." After obtaining the business association information and the general domain request, the business domain system can also encapsulate the business association information and the general domain request, generate a general domain operation request, and send it to server 110.

[0044] In some embodiments of this specification, automated linkage between business processes and information notification processes is achieved by automatically generating general domain operation requests based on preset business events. Specifically, this mechanism allows periodically or threshold-triggered business processes (such as automatic submission for review due to budget overruns and regular progress reports) to be incorporated into the same processing logic as user-initiated operations. This enables the system to accommodate various business scenarios, including both proactively triggered (e.g., user button clicks) and passively triggered (e.g., system background monitoring), unifying diverse heterogeneous business needs into a single, precise push mechanism. Without manual intervention, the system automatically triggers subsequent information sending processes once the business status changes, improving the timeliness and accuracy of information flow and avoiding human error in missing or delaying information delivery.

[0045] Step 220: Determine the target permission code based on business association information and general domain request.

[0046] An authorization code is a structured identifier used to uniquely identify the permissions, roles, or functions required in a specific business scenario. In some embodiments, the authorization code is used to translate business requirements into system-recognizable authorization logic. For example, an authorization code can be a string consisting of multiple character segments, such as "SY01-B010200P01R01". In some embodiments, the authorization code is the link between abstract business requirements and specific entity users. It transforms "what business to do" (determined by business association information) and "what intent" (determined by the general domain request) into a system-queryable index key. Further explanation of authorization codes can be found in the relevant description of step 230.

[0047] Accordingly, the target permission code refers to the specific permission code determined for this search and matching for the current general domain operation request.

[0048] In some embodiments, server 110 can determine the target permission code based on preset encoding generation rules, using business association information and a general domain request. For example, server 110 can determine the type of permission code (such as approval type) based on the general domain request, and fill in the various fields of the permission code according to the specific parameters in the business association information (such as the region or professional line), thereby combining to generate the target permission code.

[0049] Taking the "construction payment approval scenario" as an example, assuming the business domain system is the "cost management system," and the current operation is to initiate a construction payment. In this case, the general domain request can be an identifier indicating the approval intent, such as "Payment_Audit_Civil" (approval for civil engineering payments); the business association information can include specific project attributes, such as "Project Region: North China," "Professional Line: Civil Engineering," and "Approval Level: Preliminary Review." Server 110 can determine the permission code segment "SY01" (representing a fixed process approval) based on the general domain request "Payment_Audit_Civil"; based on the business association information, it determines the permission code segment "B010200P01R01"; combining and concatenating the two permission code segments, it finally generates the target permission code "SY01-B010200P01R01."

[0050] In some embodiments, server 110 can determine the permission code segment "SY01" based on the business type implicit in the general domain request and a preset permission rule table. The permission rule table stores the permission code segment "SY01" corresponding to the permissions contained in the business type. For example, if the general domain request indicates "basic budget management permissions," the corresponding permission code segment is "SY01"; if it indicates "dynamic amount interception," the corresponding permission code segment is "SY02."

[0051] In some embodiments, the authorization rule table may be preset by the administrator and stored in the storage device 120.

[0052] In some embodiments, the server 110 can determine the business area code, professional code, and responsibility code by parsing business association information. For example, it can extract "Project location: Phase I community" from the business association information and determine the corresponding business area code as "B01" according to a preset coding generation rule; it can extract "Business type: Civil engineering" and determine the corresponding professional code as "P01", etc.

[0053] Step 230: Based on the target permission code and the permission code mapping table, determine the user identification information of one or more target users.

[0054] A permission code mapping table is a data structure or database table that stores the correspondence between user identities and permission identifiers. In short, a permission code mapping table can be used to record which users possess which permission codes.

[0055] In some embodiments, the permission code mapping table may be stored in storage device 120. For example, the permission code mapping table may be a relational database table containing a "user ID" field and a "permission code" field. Alternatively, the permission code mapping table may be a key-value pair storage structure, with the permission code as the key and a list of user IDs possessing that permission as the value.

[0056] In some embodiments, the permission code mapping table can be pre-built and dynamically maintained. The permission code mapping table can be obtained or built in various ways. For example, it can be obtained through administrator configuration, receiving the mapping relationship between users and permission codes manually entered by the administrator in the permission management interface or imported in batches from files (such as Excel spreadsheets) to build the permission code mapping table. Another example is that it can be obtained through synchronization with external systems, such as synchronizing user organizational structure and job information from a human resources system (HR), identity authentication system (IAM), or Active Directory (AD), and automatically generating mapping relationships according to preset job-permission conversion rules to obtain the permission code mapping table.

[0057] In some embodiments, server 110 may also obtain user identification information associated with the service expansion request and the data jurisdiction of the user identification information in the new service information, and generate an access code mapping table based on the user identification information and the data jurisdiction. For more information on this, please refer to [link to relevant documentation]. Figure 4 And its related descriptions.

[0058] In some embodiments, the permission code mapping table includes a mapping relationship between user identification information and permission codes.

[0059] User identification information refers to an identifier used to uniquely identify a user in a system. User identification information may include, but is not limited to: User ID, employee ID, system login account, email address, mobile phone number, or national ID card number. For example, user identification information could be "U001", "20238888", or "zhangsan@company.com". In some embodiments, user identification information is used by the communication system for message routing in subsequent steps.

[0060] In some embodiments, the permission code includes a dynamic permission segment. The dynamic permission segment includes a business area code, a professional code, and a responsibility code. The business area code, professional code, and responsibility code are each obtained based on a finite set of codes.

[0061] A dynamic permission segment refers to the part of a permission code that changes dynamically based on specific business attributes. Dynamic permission segments are used to finely define the scope of permissions by combining different business dimensions. For example, in the permission code "SY01-B010200P01R01", the "B010200P01R01" part can be a dynamic permission segment, which changes depending on the location of the business and the professional field involved.

[0062] The business area code is used to identify the geographical or logical management area to which the business belongs. For example, "B01" represents the North China region, and "B02" represents the South China region. In some embodiments, the first 7 bits of the dynamic permission segment can be used as the business area code. For example, the first seven bits of the dynamic code segment "B010204P01R01" are the business area code "B010204", which represents "Unit 4, Building 2, Phase I Community". That is, the first three bits "B01" represent the Phase I area, the fourth and fifth bits "02" represent Building 2, and the sixth and seventh bits "04" represent Unit 4.

[0063] Professional codes are used to identify the professional or functional category to which a business belongs. For example, "P01" represents civil engineering, and "P02" represents finance. In some embodiments, the eighth to tenth digits of a dynamic permission segment can be used as a professional code. For example, the eighth to tenth digits of the dynamic permission segment "B010204P01R01" with the code "P01" is a professional code that represents "civil engineering".

[0064] Job responsibility codes are used to identify the job level, position, or operational role required in business processes. For example, "R01" represents a preliminary review specialist, and "R02" represents a manager. In some embodiments, the last three digits of a dynamic permission segment can be used as a job responsibility code. For example, in the dynamic permission segment "B010204P01R01", the last three digits "R01" represent "preliminary review specialist".

[0065] A finite coding set refers to a predefined, standardized list of available codes. In some embodiments, the code for each dimension (such as region, specialty, or responsibility) is derived from its corresponding finite coding set. For example, the business region coding set could be {B01, B02, B03, ...}, {01, 02, 03, ...}, and {01, 02, 03, ...}; the specialty coding set could be {P01, P02, P03, ...}.

[0066] In some embodiments, a limited set of codes may be stored in storage device 120. When determining a dynamic permission segment, server 110 may perform matching or verification within the limited set of codes to ensure that the generated dynamic permission segment is a valid code.

[0067] In some embodiments, the permission code further includes a basic permission segment. This basic permission segment reflects the service type.

[0068] The basic permission segment refers to the portion of the permission code used to identify the basic category or business affiliation of the permission. In some embodiments, the basic permission segment is typically located at the beginning of the permission code, serving as a primary category identifier. For example, in the permission code "SY01-B010200P01", "SY01" is the basic permission segment, which can be set to correspond to "budget management basic permissions". This means that the user corresponding to this basic permission code has "budget management business" or budget management-related business, so this user has "budget management basic permissions".

[0069] Business type can refer to the logical pattern of permission processing or the category of business scenarios. For example, budget management business, cost management business, quality management business, etc.

[0070] In some embodiments, server 110 is further configured to obtain a service expansion request, the service expansion request including new service information; and to add coding elements to one or more sets in the basic coding set based on the new service information; the basic coding set includes a service area coding set, a professional coding set, and a responsibility coding set.

[0071] Business expansion requests refer to configuration update requests triggered when the organizational structure, business scope, or management dimension is expanded.

[0072] The newly added business information describes the specific content of the expansion. For example, when a company opens a new "East China Branch", the newly added business information could be "New Region: East China"; when a company establishes a new "Artificial Intelligence Department", the newly added business information could be "New Specialty: AI Technology", etc.

[0073] In some embodiments, server 110 may obtain service expansion requests by receiving instructions entered by the administrator in the configuration interface, or by synchronously obtaining service expansion requests from an upstream master data system (such as a Unified Endpoint Management system).

[0074] In some embodiments, in business scenarios involving hierarchical management (such as real estate project management), the newly added business information may further include specified information about the newly added building and the parent information of the newly added building. Parent information refers to the superior information to which the newly added business object belongs, such as the project name, phase number, or cluster information. For example, an administrator can specify "Add Building 4" (new building information), "No unit division" (attribute information), and "Belongs to Phase 1" (parent information). By including parent information, the server 110 can accurately mount the newly added business object into the existing business tree structure, thereby achieving the inheritance or subdivision of permissions.

[0075] A base code set refers to a database or list of all available dynamic permission segment elements in a storage device. For example, a base code set may include the aforementioned: a business area code set (storing all available area codes), a profession code set (storing all available profession codes), and a responsibility code set (storing all available job level / role codes).

[0076] In some embodiments, the basic code set may be stored in storage device 120 in the form of key-value pairs or a dictionary. For example, the business area code set may be stored as [{Code: B01, Name: North China}, {Code: B02, Name: South China}].

[0077] In some embodiments, the process of adding coding elements based on new business information may include: taking a business area coding set as an example, parsing the new business information (e.g., "New Area: East China"), and performing deduplication in the corresponding business area coding set to confirm whether the area has not yet defined a corresponding code; if the area is not defined, generating a new unique coding element according to a preset coding rule; and writing the correspondence between the generated code (e.g., "B03") and the business meaning (e.g., "East China") into the business area coding set. The preset coding rule may be numerical increment (e.g., incrementing from B02 to B03), or it may be based on pinyin or English abbreviations. The same applies to professional coding sets and responsibility coding sets.

[0078] In some embodiments of this specification, a scaling mechanism based on a base code set enables "zero-code development" to address business changes. Business scaling involves adding new elements to the code set without modifying existing codes. This not only ensures the continued validity of historical permission codes but also eliminates the need for "re-flush" or "cleaning" of old data during phased project expansion, greatly enhancing the system's backward compatibility. When launching new businesses or expanding into new regions, simply adding configuration data to the set allows the system to automatically generate permission codes that include the new business dimensions, significantly reducing operational costs and improving the system's adaptability to rapid business expansion.

[0079] In some embodiments of this specification, a hierarchical management of permission logic is achieved by introducing basic permission segments that reflect business types. The system retains the stability of core permissions (controlled by basic permission segments) while allowing dynamic permission segments to change flexibly as projects or business operations adjust. This architectural design effectively isolates the risks of change when dealing with complex and ever-changing business requirements, reduces the difficulty and risk of later system maintenance, and enables a single permission code structure to be compatible with various complex business control logics, improving the system's versatility and parsing efficiency.

[0080] In some embodiments of this specification, dynamic permission segments containing business areas, specialties, and responsibilities are introduced and managed based on a finite set of codes, ensuring that the granularity of the system's permission definitions perfectly corresponds to the actual division of labor in engineering. This structured coding approach allows the system to cover an unlimited number of business scenarios (e.g., free combinations of different areas and specialties) with a limited set of codes, greatly improving the flexibility and scalability of the permission system and avoiding the need to develop hard-coded logic for each new combination. More importantly, when matching target users subsequently, the system can directly build an index based on the code set for fast retrieval, significantly narrowing the database search scope and thus greatly improving the computational efficiency of permission matching.

[0081] In some embodiments, the permission code mapping table is not static data but can be dynamically updated according to business needs. For example, when an enterprise's business scope expands, the system can respond to a business expansion request, automatically generate new permission code mapping data, and write it into the permission code mapping table. Server 110 can obtain user identification information associated with the business expansion request and the data jurisdiction of the user identification information in the newly added business information; based on the data jurisdiction of the user identification information in the newly added business information, determine the dynamic permission segment corresponding to the user identification information; based on the user identification information, determine the basic permission segment; based on the user identification information, the dynamic permission segment, and the basic permission segment, generate permission code mapping data and write the permission code mapping data into the permission code mapping table. For more details, see [link to documentation]. Figure 4 And its related descriptions.

[0082] A mapping relationship refers to the association between user identification information and authorization codes. This mapping relationship reflects the correspondence between users and their responsibilities and jurisdictions in the real world.

[0083] It should be noted that the mapping relationship can be many-to-many: that is, one user identification information can correspond to multiple permission codes (for example, one person is both "North China Region - Engineering Manager" and "Group - Technical Expert"); one permission code can also correspond to multiple user identification information (for example, the responsibility of "South China Region - Financial Preliminary Review" may be shared by multiple employees).

[0084] A target user refers to a specific object that, according to business logic, should receive information or process business requests. A target user is an entity possessing the permissions represented by the target permission code. For example, if the target permission code represents "North China Regional Engineering Manager," then the current North China Regional Engineering Manager, Zhang San, is the target user.

[0085] In some embodiments, server 110 can obtain user identification information of one or more users by querying a permission code mapping table based on the target permission code. For example, server 110 can use the aforementioned determined "target permission code" as a query index or search keyword to perform a matching search in the permission code mapping table. If a record matching the target permission code exists in the mapping table, the associated one or more user identification information records are read. For instance, if the target permission code is "SY01-B010200P01", and the system finds the user ID list corresponding to this permission code in the mapping table as {"U001", "U005"}, then "U001" and "U005" are determined to be the user identification information of the target user.

[0086] Step 240: Generate a first user set based on the user identification information of one or more target users.

[0087] The first user set refers to the set of valid user identification information that has been screened and verified and should actually receive the information body. The user identification information in the first user set is usually deduplicated and in a normal state. For example, the first user set can be a list or array of user identification information, such as ["U001", "U005"...].

[0088] In some embodiments, the server 110 can generate a first user set by performing deduplication, status filtering, and other processing on the found target users.

[0089] In some embodiments, server 110 may generate a candidate user set, which includes user identification information of one or more target users; determine whether one or more target users are in an invalid state based on the user identification information of one or more target users; wherein, invalid state includes resignation state and / or vacation state; delete the user identification information of target users in an invalid state from the candidate user set, and generate a first user set.

[0090] The candidate user set refers to the initial set of users obtained directly from the permission code mapping table that has not yet undergone validity verification. Understandably, because the permission code mapping table may contain redundant historical data (e.g., records of employees on leave, or those who have resigned and whose records have not been cleared), the candidate user set may contain invalid user identification information.

[0091] In some embodiments, server 110 may generate a candidate user set based on the sum of user identification information of all target users found in the manner described in step 230 above.

[0092] An invalid status refers to a state where a user is currently unable to perform their duties, receive information, or is no longer qualified to operate the business. In some embodiments, an invalid status includes a resigned status (the user has terminated their employment contract) and / or a leave status (the user is on annual leave, sick leave, or other leave). In some embodiments, an invalid status may also include an account frozen status, a deactivated status, etc.

[0093] Server 110 can use multiple methods to determine whether a target user is in an invalid state.

[0094] In some embodiments, server 110 can determine the status of a target user by interacting with an external human resource management system (HRM) or attendance system. For example, server 110 can use user identification information to call the HR system's status query interface (API) to obtain the user's current employment status (such as "Active" or "Resigned") and attendance status (such as "On Duty" or "On Leave"). If the interface returns a status of "Resigned" or "On Leave", the target user is determined to be in an invalid state.

[0095] In some embodiments, the administrator can also manually input / adjust lists and databases that store user statuses (such as user statuses marked as resigned or user statuses as normal). Correspondingly, the server 110 can directly read the user statuses in the corresponding lists and databases to determine whether the target user is in an invalid state.

[0096] In some embodiments, server 110 may iterate through each user identification information in the candidate user set and determine whether each user is in an invalid state. If the determination result is an invalid state, the user identification information is removed (deleted) from the candidate user set. If the determination result is a valid state (e.g., employed and on duty), the user identification information is retained. After iteration and filtering are completed, the remaining user identification information constitutes the first user set.

[0097] In some embodiments of this specification, the "information black hole" problem is effectively avoided by adding a user status verification and filtering mechanism before sending information. That is, it prevents important approval tasks or business notifications from being sent to personnel who have left the company or are on leave, thereby preventing business processes from stalling due to personnel absence. At the same time, this also improves the accuracy and security of information transmission, ensuring that sensitive business data only flows to valid users who currently have legitimate permissions and are on duty.

[0098] Step 250: Transmit the business association information, the general domain request, and the first user set to the general domain system, so that the general domain system can generate a target information body based on the business association information and the general domain request, and send the target information body to one or more target users.

[0099] A target message body refers to a formatted data entity that can be directly displayed to users for viewing or interaction within a general domain system. In short, a target message body transforms structured business data into user-friendly visual elements. For example, a target message body can be a "card message" in instant messaging software, containing a title, summary field, image, and action buttons. Another example is the body of a formatted HTML email.

[0100] In some embodiments, the general domain system (or server 110) can receive business-related information and general domain requests, and embed the business-related information into a specific display format to generate the target information body.

[0101] In some embodiments, server 110 (or general domain system) may also determine the target template through a template library based on business association information and general domain requests; the template library includes multiple templates, each of which has a corresponding information body type and applicable scenario; each template includes one or more form fields, which are related to the information body type and applicable scenario of each template; the form fields in the target template are filled in based on the business association information.

[0102] A template library is a collection of pre-stored message display styles. Each template in the library defines the layout structure of the information, fixed text, and the location for dynamic data to be filled. In some embodiments, each template has a corresponding information body type (such as "approval type") and applicable scenario (such as "financial reimbursement").

[0103] In some embodiments, the template library may be stored in the storage device 120 in the form of a JSON configuration file, or it may be a cloud template resource stored in the backend of a general domain system.

[0104] Information body type refers to the standardized output format of a general domain system. It is a predefined standard container used by the general domain system to carry different business logics. No matter how the content of business-related information changes, the interface ultimately presented to the user must conform to these standardized output formats.

[0105] In some embodiments, the information body type includes approvals, pending tasks, messages, and data archives.

[0106] Approval refers to high-priority information that requires user decision-making (such as agreeing / rejecting). The corresponding templates typically include decision buttons. For example, a template for approval-type information could include a civil engineering budget approval template.

[0107] "To-do" refers to information that requires users to perform specific tasks. The corresponding templates typically include links that guide users to the relevant business domain system to complete the task. For example, a template for a "to-do" type of information could include a civil engineering task to-do template.

[0108] A message refers to notification-type information used solely to inform users of something. Examples include "CC notifications" and "system announcements." For instance, the template corresponding to the message body could include a civil engineering business notification template.

[0109] Data archiving refers to the process of generating target information bodies from data from the business domain and transmitting these target information bodies to one or more target users in a common domain system for data archiving. Templates corresponding to the information bodies of data archiving types can include civil engineering budget data templates.

[0110] In some embodiments, taking construction project management as an example, the project task management process generally involves the general contractor issuing task orders to specialized subcontractors, who then accept the task orders and further distribute them to labor subcontractors. This process continues layer by layer down to work teams and individual workers. Workers clock in upon receiving their task orders, creating attendance records. Team leaders record work hours based on task completion and attendance. After construction is completed, the team leader applies for acceptance, which is then conducted by both the subcontractor and the general contractor. Following acceptance, the team leader applies for payroll based on the work record, which is then approved at each level before being disbursed to the workers. The construction project management system can use the "Pending Tasks" target information body to assign tasks to target users, the "Approval" target information body to assist relevant management personnel in completing review and approval processes, the "Message" target information body to push business data to relevant personnel for reading or notification, and the "Data Archiving" target information body to send business data or internal management data to a designated database within the construction management software system for data archiving.

[0111] In some embodiments of this specification, by distinguishing information body types, the system can adapt different display strategies and reminder intensities for different types of information. For example, for the "approval" type, the general domain system can use a strong pop-up reminder; for the "message" type, it will only be displayed silently in the notification bar. This helps users distinguish between priorities and improves the efficiency of handling core business. By limiting the information body types to four categories—approval, to-do, message, and data archive—the template library, permission codes, and general domain system are fully aligned, achieving closed-loop management of "permissions-templates-push notifications."

[0112] The applicable scenario refers to the specific environment or sub-category of the business that occurs. For example, the applicable scenario could be "travel expense reimbursement", "contract signing", or "visitor appointment".

[0113] Form fields are reserved variable slots in the template for populating dynamic data. In some embodiments, form fields are related to the template's body type and applicable scenario. For example, for a template with an "approval" body type applicable to a "leave application" scenario, form fields may include: {applicant}, {leave type}, {start time}, {end time}, {number of days}, etc. As another example, for a template with an "approval" body type applicable to a "purchase request" scenario, form fields may include: {item name}, {specifications}, {quantity}, {requested budget amount}, {supplier}, etc. Yet another example, for a template with a "message" body type applicable to a "visitor appointment" scenario, form fields may include: {visitor name}, {arrival time}, etc.

[0114] In some embodiments, the multiple templates stored in the template library are maintained in a refined manner based on business scenarios and process nodes. For example, for information body types involving multi-stage flows, taking approval-type scenarios (such as purchase applications and leave applications) as an example, a complete business process may include one or more approval nodes (or approvers). Therefore, the general domain system will maintain corresponding templates for different process nodes (such as "preliminary review template" and "final review template"), or pre-set status fields in the templates to adapt to different node statuses, thereby ensuring that the information body can accurately reflect the progress of the current process.

[0115] In some embodiments, continuing with approval-type scenarios (such as purchase requests and leave applications) as examples, the corresponding templates not only include static content definitions (such as basic information and form fields) but also dynamic process definitions (such as approval paths and rules). Basic information refers to the basic, general content included in the template, typically viewed by users on the list page. For example, basic information includes basic fields such as title, initiator, and initiation time. The approval path defines which approval nodes are involved in the approval process and the order in which the approval flows through these nodes (e.g., first the project manager, then the CFO). Approval rules define the processing logic within each node, including rules for parallel approval and co-signature approval. Parallel approval (co-signature) means that a node requires approval from multiple people simultaneously (e.g., both review experts A and B must agree). Co-signature approval means that a node has multiple people involved, and approval from any one of them is sufficient to move to the next node.

[0116] Similarly, the general domain system also maintains a series of to-do templates, message templates, and data templates. They also have corresponding types, applicable scenarios, basic information, and form fields, which will not be elaborated here.

[0117] In some embodiments, server 110 can directly map and obtain the information body type corresponding to the target template based on the instruction intent (such as "request for approval") in the general domain request.

[0118] In some embodiments, server 110 can extract a business identifier (such as "Biz_Type=Travel") from business association information to obtain the applicable scenario corresponding to the target template.

[0119] In some embodiments, server 110 (or general domain system) can use the acquired information body type (such as “approval”) and applicable scenario (such as “travel reimbursement”) as a composite index to search in the template library, thereby uniquely identifying a matching target template (such as “travel approval standard template V1”).

[0120] In some embodiments, server 110 can also extract "general domain type" and "jurisdiction dimension" based on business association information and general domain requests. The "general domain type" corresponds to the aforementioned information body type (e.g., approval, pending task), and the "jurisdiction dimension" corresponds to the region or professional scope where the business occurs. These two features are matched with the associated attribute tags of each template in the template library to determine a batch of candidate templates. In some embodiments, to ensure the stability of information transmission, server 110 performs validity checks on the candidate templates, excluding invalid templates, and determining the remaining template with the highest matching degree or highest priority as the target template.

[0121] Invalid templates refer to templates that are not suitable for the current stable business flow. For example, invalid templates may include "templates with no recent flow records" (such as "zombie" templates that have not been used in the past 3 months) or "temporary templates" (such as informal templates used only for short-term testing or temporary activities).

[0122] In some embodiments, server 110 can map and populate key-value pairs in business-related information with form fields in the target template. For example, server 110 can parse business-related information and extract key business data, including but not limited to: regional information (e.g., "North China Region"), professional information (e.g., "Civil Engineering"), responsibility information (e.g., "Preliminary Review"), and business order number (e.g., "BX-20231201-001"). The extracted information is then accurately mapped and filled into the corresponding form fields of the target template to generate the final target information body. For example, the generated card might display: "[North China Region - Civil Engineering] You have a [Preliminary Review] task with order number BX-..." pending processing.

[0123] In some embodiments of this specification, the separation of the presentation layer (View) and the data layer (Model) is achieved by generating the target information body using a "template library + automatic form field filling" approach. Specifically, the business domain only needs to provide core business-related information, and the general domain system can automatically generate approval forms or to-do items with a uniform format and complete fields. This mechanism avoids repetitive development work by various business domain systems to adapt to different display requirements, while ensuring the standardization of information output under different business scenarios. Furthermore, when the business department needs to adjust the style of the notification card (e.g., add a font color or adjust the field order), it only needs to update the template configuration in the template library without modifying the code logic of the business domain system, greatly improving the system's response speed to changes in front-end display requirements.

[0124] In some embodiments, after generating the target information body, the server 110 (or general domain system) can, based on the user identification information in the first user set, call the message push interface to distribute the target information body to the user terminal 140 of the corresponding target user (e.g., send it in the form of an information). For example, send the generated "travel approval card" to the user list [U001, U005].

[0125] The information body sending method provided in some embodiments of this specification decouples the business domain system from the user by introducing an authorization code mechanism, establishing a chain-like filtering path of "business-related information + general domain request - target authorization code - user authorization code mapping table". This mechanism ensures that the general domain system sends information bodies only to users who truly possess the corresponding business permissions, guaranteeing accurate information delivery and effectively avoiding information redundancy caused by sending to irrelevant users, thus improving user efficiency and experience. This method also enables enterprises to maintain system stability and flexibility when facing complex organizational restructuring, frequent personnel changes, and ever-changing business notification needs, reducing IT maintenance costs and ensuring efficient and accurate business information flow.

[0126] In some embodiments, server 110 may obtain an authentication request sent by the business domain system; the authentication request is generated based on a user's access request to a page, and includes the user's user identification information and the page's page identification information; based on the user identification information and the page identification information, an authentication result is determined, and the authentication result is sent to the business domain system; the authentication result includes the valid operation type that the user has permission to perform on the page and the user's data jurisdiction, enabling the business domain system to generate a page view of the page based on the page data and the authentication result; the page view includes one or more data items in the page data that belong to the user's data jurisdiction; each of the one or more data items has a trigger control corresponding to the valid operation type.

[0127] Figure 3 These are exemplary schematic diagrams of page views shown according to some embodiments of this specification.

[0128] For more information on user identification information, business domain systems, etc., please refer to Figure 2 And its related descriptions.

[0129] An authentication request is a verification query initiated by a business domain system to server 110 when it receives a user's attempt to access a specific page. In short, an authentication request aims to confirm whether the user is authorized to access the page, and what they can see and do on that page.

[0130] In some embodiments, the authentication request is generated based on the user's access request to the page. For example, when a user clicks "To-Do Items" in the system menu or accesses a specific URL, the business domain system intercepts the access request, extracts the user identification information of the currently logged-in user (such as "U001") and the page identification information of the target page (i.e., the page ID, such as "Page_TodoList"), encapsulates and generates an authentication request, and sends it to the server 110.

[0131] In some embodiments, server 110 may receive authentication requests sent by business domain systems through internal microservice interfaces or remote calls.

[0132] Page identification information refers to the identifier used to uniquely identify a specific functional page or view in a business domain system.

[0133] In some embodiments, when generating an authentication request, the server 110 determines the corresponding page identification information based on the target address requested by the user.

[0134] In some embodiments, page identification information may be the page's URL path, front-end route name, or back-end defined resource ID, etc. For example, page identification information may be "Page_ID_001" (corresponding to "Project List Page") or "Page_ID_002" (corresponding to "Contract Approval Page"), etc.

[0135] The authentication result refers to the control data calculated based on the user's permission configuration, used to guide the rendering of pages by the business domain system. For example, the authentication result can be a permission decision on the user's actions and data visibility on a certain page, including whether access / action is allowed, as well as the data viewing scope and general domain push dimensions.

[0136] In some embodiments, the authentication result may include a valid action type (determining the availability of page functionality) and the user's data jurisdiction (determining the visibility of page data). For example, the authentication result may be: {Valid action type: ["Agree", "Deny"], Data jurisdiction: "Region=North China"}. This means that the user can perform an "Agree" or "Deny" action on the page and can only see data from the "North China" region.

[0137] A valid action type refers to the specific interactive behavior or functional instruction that a user is allowed to perform on the target page. Understandably, valid action types typically correspond to function buttons or menu items on the page. For example, valid action types may include: initiating approval, initiating a message, initiating a to-do list, initiating data archiving, editing, deleting, exporting, etc. In some embodiments, if the authentication result does not include a certain action type (such as not including "delete"), the business domain system should hide the corresponding trigger control or make it unavailable when rendering the page.

[0138] A user's data jurisdiction refers to the boundary conditions of the set of data that a user is authorized to view or process on a target page. In some embodiments, data jurisdiction is typically embodied in a set of filter conditions or SQL query parameters. For example, data jurisdiction could be "Business Region = North China AND Specialty = Civil Engineering", meaning that the user can manage the data / permissions corresponding to civil engineering business in the North China region. In some embodiments, when querying the database to display a list of pages, server 110 can force the appending of data jurisdiction as a filter condition to ensure that the user can only see data rows within their jurisdiction.

[0139] In some embodiments, server 110 can determine the authentication result by directly matching user identification information (User ID) and page identification information (Page ID). For example, server 110 can use the received user identification information and page identification information as joint query conditions to perform a search and match in a pre-stored permission code mapping table; through matching, it obtains the full range of permissions currently held by the user (i.e., the set of permission codes held by the user); based on the full range of permissions, it determines whether the user has the right to access the target page, and further parses out the user's operation permissions and data visibility within the page, ultimately generating an authentication result containing the above information.

[0140] In some embodiments, server 110 may determine the permission code corresponding to user identification information based on a user identification information and permission code mapping table; obtain the basic permission segment corresponding to user identification information based on the permission code corresponding to user identification information; determine the valid operation type based on the basic permission segment corresponding to user identification information, page identification information, and association rule table; obtain the dynamic permission segment corresponding to user identification information based on the permission code corresponding to user identification information; and determine the data jurisdiction based on the dynamic permission segment corresponding to user identification information.

[0141] For more information on permission code mapping tables, permission codes, basic permission segments, and dynamic permission segments, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0142] In some embodiments, server 110 can use the user identification information in the authentication request as an index to perform a reverse lookup in the permission code mapping table. As mentioned earlier, the permission code mapping table stores the correspondence between users and permission codes. Through matching, server 110 can obtain one or more permission codes possessed by the user. For example, for user "U001", the corresponding permission code found is "SY01-B010200P01R01".

[0143] In some embodiments, server 110 can parse the permission code according to a preset segmentation rule and extract the basic permission segment. For example, the preset segmentation rule could be "take the first four digits of the permission code as the basic permission segment". Therefore, for the permission code "SY01-B010200P01", server 110 can extract the first four digits "SY01" as the basic permission segment. Furthermore, as mentioned earlier, the basic permission segment (such as SY01) reflects the business type or job nature (such as "fixed job approval"), which determines the user's functional role on the page.

[0144] An association rule table is a pre-configured logical table that defines the "operation permissions" of a "basic permission segment" on "different pages". In other words, the association rule table establishes a mapping of [{basic permission segment, page identification information} -> {list of valid operation types}]. For example, the association rule table might record: when the basic permission segment is "SY01" (approval role) and the page is the "project list page", the valid operations are ["Initiate approval", "View details"]; while when the basic permission segment is "SY03" (observer) and the page is the same "project list page", the valid operation is only ["View details"]. In some embodiments, the association rule table can be pre-configured by the administrator and stored in storage device 120.

[0145] In some embodiments, server 110 can use the extracted basic permission segment (such as SY01) and page identification information (such as Page_Project_List) from the authentication request as joint query conditions, match them in the association rule table, find the operation list corresponding to the joint query condition, and determine it as the valid operation type of the user on the page. In this way, server 110 implements page function-level control based on the "basic permission segment" (e.g., determining whether the user has the right to see or trigger the "Initiate Approval" button).

[0146] In some embodiments, similarly, server 110 can continue to parse the remaining part of the permission code or fields at specified positions according to preset segmentation rules to extract dynamic permission segments. For example, the code "B010200P01R01" after the fifth digit can be extracted from the permission code "SY01-B010200P01R01" as a dynamic permission segment. As mentioned above, the dynamic permission segment contains specific business attributes (region B01, specialty 02, etc.).

[0147] In some embodiments, server 110 can determine the data jurisdiction based on dynamic permission segments through parsing and mapping transformation. For example, server 110 can parse the dynamic permission segment to extract the business codes of multiple dimensions contained within it. As mentioned earlier, the dynamic permission segment consists of business area codes, professional codes, and responsibility codes. Server 110 can decompose the dynamic permission segment (e.g., "B010200P01R01") into sub-elements such as business area codes ("B01") and professional codes ("02") according to preset bit length rules or delimiters. Server 110 can convert the above sub-elements into filtering conditions recognizable by the database query language based on a basic code set or preset data field mapping relationships.

[0148] For example, server 110 identifies that the value of the database field `region_id` corresponding to the business region code "B01" is 1001; and the value of the database field `profession_code` corresponding to the professional code "02" is `CIVIL`. It combines the filtering conditions of each dimension (usually using an AND operation, i.e., taking the intersection) to generate the final data jurisdiction. For example, the generated data jurisdiction can be represented as a structured query object or a fragment of an SQL query statement, such as `WHERE region_id='1001' AND profession_code='CIVIL'`. In this way, server 110 achieves fine-grained control at the data row level based on "dynamic permission segments," ensuring that the generated page view only contains specific data rows belonging to the user's jurisdiction (e.g., only displaying the list of civil engineering projects in North China), thereby guaranteeing data security and business isolation.

[0149] For more information on business area coding, professional coding, responsibility coding, and the basic coding set, please refer to [link / reference]. Figure 2 And its related descriptions.

[0150] In some embodiments of this specification, the permission code is split into two segments, "basic" and "dynamic," for separate processing. The basic permission segment, combined with the association rule table, flexibly controls "page functions" (button-level permissions); the dynamic permission segment is directly mapped to data attributes, precisely controlling "data range" (row-level permissions). This dual authentication mechanism, which decouples functional permissions from data permissions, is not only logically clear and can be processed in parallel, improving authentication speed, but also greatly reduces configuration complexity—when the business data range is adjusted (such as a regional change), only the dynamic segment needs to be changed, without affecting the function buttons; when the page function is adjusted, only the association rule table needs to be updated, without affecting the data range.

[0151] In some embodiments, page data refers to the original set of business data associated with the target page in the business domain system. For example, for a "contract management page," page data may include all contract records within the system (regardless of region, status, or type). In some embodiments, page data may be stored in the database of the business domain system. The business domain system (or server 110) can query the database to retrieve the initial page data based on page identification information. At this point, the page data has not yet been filtered for user-specific permissions.

[0152] A page view refers to the personalized interactive interface presented to the user after the business domain system processes the page data based on the authentication results. For example... Figure 3 As shown, the page view is the result of "cropping" and "assembling". The page view only displays data within the scope of the user's data (i.e., filtered data, such as data-1, data-2, ..., data-N), and only renders controls with valid user operation types (such as trigger control-1, trigger control-2, ..., trigger control-N). For example, for the same "Contract Management Page", the page view seen by the manager may include "All Contracts in North China" and the "Approval Button"; while the page view seen by a regular staff member may only include "Contracts I am responsible for in North China" and the "View Details Button".

[0153] One or more data entries within the data jurisdiction (such as...) Figure 3 The data entries (data-1, data-2, ..., data-N) refer to specific business records within the user's data scope on the page. Each data entry represents an independent business object, such as a project, a document, or a task. Understandably, this data represents content that the user is authorized to view and process under their current permissions.

[0154] A trigger control is an interactive element in a page view used to respond to user actions and trigger business logic. In some embodiments, a trigger control may include a button, link, icon, switch, or menu item.

[0155] In some embodiments, trigger controls (such as...) Figure 3 The trigger controls (-1, ..., trigger controls-N) in the system correspond one-to-one with the valid operation types. The business domain system will only render the trigger control next to the corresponding data entry when the authentication result contains a certain valid operation type.

[0156] In some embodiments, the trigger control corresponding to the valid operation type includes one or more of the following: trigger control for initiating approval, trigger control for initiating a message, trigger control for initiating a pending task, and trigger control for initiating data archiving, etc.

[0157] Trigger controls for initiating approvals can be used to start a business process that requires a decision-making flow. For example, an approval trigger control could be a "Submit for Review" or "Request Payment" button. For instance, when a user clicks this control, they can search for a superior or specialist with approval authority, and the business domain system will generate a request containing the "Approval" intent accordingly.

[0158] Trigger controls for initiating messages can be used to send notifications or reminders to others. For example, a trigger control could be a "Reminder," "Notify Project Team," or "Share" button. Clicking this control, for instance, can push the current data information to relevant personnel.

[0159] Trigger controls for initiating to-do items can be used to assign specific tasks to others. For example, trigger controls for initiating to-do items could be "Assign Rectification" or "Transfer for Handling" buttons. For instance, clicking this control can create a to-do item (Task) in the recipient's general domain system.

[0160] Trigger controls for initiating data archiving can be used to change the lifecycle state of data, marking it as completed or historical data. For example, this control could be a "Confirm Archiving" or "Close Item" button. Clicking this control could trigger an archiving confirmation notification to the archivist or directly lock the current data record.

[0161] In some embodiments of this specification, by defining multiple types of trigger controls and binding them to valid operation types in the backend (and thus to basic permission segments), deep linkage between front-end interaction and backend permissions is achieved. This mechanism ensures that the display of the user interface (UI) strictly follows the permission logic—users can only see buttons they are authorized to operate on. Simultaneously, the clear control classification (approval / message / pending tasks) standardizes the logic for subsequent information body sending, enabling the system to accurately determine the type of target user to be sought based on the user's click behavior. Furthermore, this mechanism achieves direct alignment between page trigger controls and common domain request types (e.g., the "Initiate Approval" control directly corresponds to an "Approval" request), allowing the business domain system to directly reuse control attributes to construct the corresponding common domain request without complex type conversions or secondary inferences when generating common domain operation requests, ensuring the accuracy and timeliness of request generation.

[0162] In some embodiments, a general domain operation request is generated by the business domain system based on the user's trigger operation on the trigger control corresponding to the valid operation type.

[0163] For more information on general domain operation requests and business domain systems, please refer to [link / reference]. Figure 2 And its related descriptions.

[0164] A trigger operation refers to a user's input behavior on the interactive interface of the user terminal 140 in response to a trigger control. In some embodiments, the form of the trigger operation depends on the type of device on the user terminal. For example, on a PC, a trigger operation may be a mouse click, double-click, or keyboard shortcut; on a mobile device, a trigger operation may be a finger click, long press, or swipe.

[0165] The trigger operation targets a specific trigger control, which in turn is bound to a specific piece of page data (as mentioned above). Figure 3 The trigger control-1 in the code is bound to data-1. Therefore, the trigger operation implies the user's intention to perform "what kind of operation" on "which data".

[0166] In some embodiments, when the business domain system detects a triggered operation, it performs the following steps to generate a generic domain operation request: The business domain system identifies the page data bound to the triggered control, extracts key business parameters (such as project ID, amount, professional code, etc.) from it, and encapsulates them into business-related information; The business domain system identifies the type of the triggered control (i.e., the valid operation type), and converts the control type into the corresponding generic domain request according to a preset mapping logic. For example, if the user clicks the "Initiate Approval" control, the business domain system generates a generic domain request indicating the intent to "seek decision-making" (this request may subsequently be parsed into the basic permission segment SY01); if the user clicks the "Initiate Message" control, the business domain system generates a generic domain request indicating the intent to "issue a general notification" (this request may subsequently be parsed into the basic permission segment SY02).

[0167] The business domain system can package the above-mentioned business association information and general domain requests to generate the final general domain operation request and send it.

[0168] In some embodiments of this specification, a "what you see is what you do, what you do is what you achieve" interactive logic is realized by dynamically generating generic domain operation requests based on trigger operations. Each user click (front-end behavior) can be accurately converted into a generic domain operation request (back-end data) containing "data context" and "operation intent." This mechanism not only simplifies the user's operation process and avoids the system generating unnecessary tasks / messages through self-looping, but more importantly, it ensures that the generic domain operation requests sent to the generic domain system strictly correspond to the current business scenario and data state, thereby guaranteeing the accuracy of subsequent permission code generation.

[0169] In some embodiments, the business domain system executes control rendering matching logic when generating a page view. For example, the business domain system iterates through each piece of page data within the scope of user data. For each piece of data, the system checks the valid operation type contained in the authentication result. The business domain system can find the trigger control component corresponding to the valid operation type based on a preset UI mapping relationship, and embed one or more matching trigger controls into the display area of ​​that piece of data (e.g., the operation bar of a list row). For example, if the valid operation type includes "Initiate Approval," the system loads the "Approval Button" component; if it includes "Initiate Pending Tasks," the system loads the "Assign Button" component. Through this process, the system ensures that each piece of displayed data includes the operation entry point that the user is currently authorized to perform.

[0170] The authentication and page view generation methods provided in the embodiments of this specification achieve dual fine-grained control of "data + function". On the one hand, based on the filtering of "data jurisdiction", it ensures that users can only see data within their scope of responsibility (data jurisdiction), achieving strict row-level data isolation and protecting the security and privacy of business data. On the other hand, based on the dynamic rendering of trigger controls according to "valid operation type", it achieves function-level permission control. This avoids displaying unavailable operation buttons to unauthorized users (preventing users from getting an "unauthorized" error after clicking), significantly improving the user experience, and also preventing the risk of unauthorized operations. In addition, this design of externalizing the authentication logic eliminates the need for business domain systems to pile up complex permission judgment logic in the front-end page code, maintaining the simplicity and maintainability of the front-end code.

[0171] Figure 4 This is an exemplary flowchart illustrating the determination of a permission code mapping table according to some embodiments of this specification. Figure 4 As shown, process 400 includes steps 410 to 440. In some embodiments, process 400 may be executed by server 110.

[0172] Step 410: Obtain the user identification information associated with the business expansion request and the data jurisdiction of the user identification information in the new business information.

[0173] For more information on service expansion requests, new service information, and user identification information, please refer to [link / reference]. Figure 2 And its related description. For more information on data jurisdiction, please see [link / reference]. Figure 3 And its related descriptions.

[0174] In some embodiments, server 110 may receive configuration instructions from an administrator or synchronize data from a human resources system to obtain user identification information associated with the business expansion request. The user identification information associated with the business expansion request refers to the person or relevant personnel responsible for handling the new business. For example, if a company adds a "East China Region," and the administrator designates "Zhang San (U008)" as the East China Region Manager, then the user identification information obtained by server 110 is "U008."

[0175] In some embodiments, server 110 can directly determine the data jurisdiction of a user based on the new business information in the business expansion request. For example, if the new business information is "New Region: East China", then the data jurisdiction of the associated user is determined to be "Region = East China". This means that the user will be authorized to process all data belonging to "East China".

[0176] Step 420: Based on the data jurisdiction of user identification information in newly added business information, determine the dynamic permission segment corresponding to the user identification information from one or more sets in the basic coding set.

[0177] For more information on basic encoding sets and dynamic permission segments, please refer to [link / reference]. Figure 2 And its related descriptions.

[0178] In some embodiments, server 110 can match a user's data jurisdiction with a basic code set to determine a dynamic permission segment. For example, if Zhang San is the manager in charge of civil engineering business in East China, then server 110 searches for the code corresponding to "East China" (e.g., "B03") in the business area code set; searches for the code corresponding to the profession "civil engineering" (e.g., "01") in the professional code set; searches for the code corresponding to the job level "manager" (e.g., "M1") in the responsibility code set; and combines these codes to generate a dynamic permission segment (e.g., "B0301M1") corresponding to Zhang San's user identification information.

[0179] In some embodiments, after generating a dynamic permission segment, server 110 also performs a deduplication check. For example, server 110 can perform a search query in the permission code mapping table based on the newly generated business area code (such as "B03") or the complete dynamic permission segment to determine whether the business area code has been occupied or whether there is a duplicate record. In response to detecting a duplicate (e.g., the code already exists), the system will generate an exception prompt and send it to the administrator to remind the administrator to check and correct it, thereby avoiding logical errors caused by code conflicts.

[0180] Step 430: Determine the basic permission segment based on user identification information.

[0181] For more information on basic permission sections, please refer to [link / reference]. Figure 2 And its related descriptions.

[0182] In some embodiments, server 110 determines the basic permission segment based on the user's role or the administrator's designation. For example, if the user is designated as "Approval Responsible Person," the basic permission segment is determined to be "SY01"; if designated as "CC Recipient," it is determined to be "SY02." In some embodiments, the system may also assign a default set of basic permission segments so that the user has a full set of permissions.

[0183] In some embodiments, server 110 may also determine the basic permission segment based on the service type and authorization rule table of the user. For more information on this, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0184] Step 440: Based on user identification information, dynamic permission segments, and basic permission segments, generate permission code mapping data and write the permission code mapping data into the permission code mapping table.

[0185] For more information on permission code mapping tables, please see [link to documentation]. Figure 2 And its related descriptions.

[0186] Permission code mapping data refers to one or more records to be written to the permission code mapping table. Each record contains the correspondence between user identification information and the generated complete permission code. For example, if the aforementioned company adds "East China Region", and the administrator designates "Zhang San (U008)" as the East China Region Manager (specifically, the manager responsible for civil engineering business in East China Region), and Zhang San is designated as the approval person in charge, then the generated permission code mapping data could be: {User_ID: U008, Permission_Code: SY01-B0301M1}.

[0187] In some embodiments, server 110 can concatenate a defined basic permission segment (such as SY01) with a dynamic permission segment (such as B0301M1) to generate a complete new permission code. Server 110 can associate this new permission code with user identification information (such as U008) to generate permission code mapping data, and perform a write operation (Insert / Update) to store it in the permission code mapping table.

[0188] In some embodiments, server 110 also supports modifying and updating existing permission code mapping relationships. For example, the modification process may include: an administrator submitting a modification request in the system, specifying a new data jurisdiction for a particular user. For instance, changing the jurisdiction of "User U001" from "Building 2, Phase 1" to "Building 3, Phase 1". Server 110 parses the new jurisdiction, determines the corresponding new dynamic permission segment (e.g., parsing "Building 3, Phase 1" yields "B010300P01R01"), retains the basic permission segment from the user's original permission code (e.g., "SY01"), and combines it with the new dynamic permission segment to generate a new permission code (e.g., "SY01-B010300P01R01"). After obtaining the new permission code for the user, server 110 can replace the old permission code for the user with the new permission code in the permission code mapping table, thereby completing the permission change.

[0189] In some embodiments, server 110 also supports deleting permission code mapping relationships. For example, the deletion process may include: an administrator submitting a deletion request, specifying the user to be removed and the corresponding jurisdiction. For instance, deleting the permissions of "User U001" regarding "Phase 1, Building 2, Civil Engineering, Budget Review". Server 110 determines the user's basic permission segment (e.g., SY01) based on the user ID and parses the jurisdiction to be deleted to obtain a dynamic permission segment (e.g., B010200P01R01), thereby concatenating the segments to obtain the permission code to be deleted. After determining the permission code to be deleted, server 110 retrieves the corresponding record of the permission code and user U001 in the permission code mapping table and performs the deletion operation to remove the permission code from the permission code mapping table.

[0190] In some embodiments, server 110 may employ a hierarchical storage strategy for the permission code mapping table. For example, the full data of the permission code mapping table may be stored in a full database (e.g., a MySQL database) to ensure data persistence and integrity; data in the permission code mapping table with an "activity level" greater than a set threshold may be stored in a cache database (e.g., a Redis database).

[0191] Redis (Remote Dictionary Server) is a high-performance key-value store database that runs in memory. It features extremely fast read and write speeds (microsecond to millisecond latency) and is suitable for real-time data processing.

[0192] In some embodiments, activity can be measured based on "number of updates in the last three days". For example, if a user's permission code is added or modified once within a preset period (such as the last three days), the activity level is recorded as 1 (or 2), which meets the set threshold (such as 0 or 1).

[0193] In some embodiments, data stored in the cache database is set with a preset duration (e.g., 24 hours). When data is stored in the cache for more than this duration and is not accessed or updated, the server 110 deletes it from the cache to free up memory resources.

[0194] Through this hot and cold data separation mechanism, server 110 effectively reduces storage costs while ensuring performance.

[0195] In some embodiments, server 110 may determine an operation test request, which includes test service association information related to the newly added service information and a general domain test request; determine a test permission code based on the test service association information and the general domain test request; determine user identification information of one or more test users based on the test permission code and a permission code mapping table; generate a second user set based on the user identification information of one or more test users; transmit the test service association information, the general domain test request, and the second user set to the general domain system, so that the general domain system generates a target test information body based on the test service association information and the general domain test request, and sends the target test information body to one or more test users; confirm whether one or more test users have received the target test information body; and confirm that the test has passed if one or more test users have received the target test information body.

[0196] It should be noted that the operation test request, test business association information, general domain test request, test permission code, and test user refer to the test / virtual data used when testing the validity of newly added mapping relationships (such as mapping relationships added in response to business expansion requests). In some embodiments, the above test data is substantially the same as the corresponding data in the aforementioned formal scenarios (such as general domain operation requests, business association information, general domain requests, target permission codes, and target users) in terms of data structure, field definitions, data types, and generation logic.

[0197] For example, the encoding format of the test permission code (such as "SY01-B0301M1") is completely consistent with the official target permission code, and both are generated by the same server 110 based on the same rules. The only difference is that the test data is used to verify the validity and connectivity of the newly added mapping relationship, and the business content it carries may be virtual or specific (e.g., the business amount is 0, or the project name contains the identifier "Test"), and the subsequent processes it triggers are intended to obtain feedback confirmation, and generally do not trigger real business consequences (e.g., no real fund deduction or formal file archiving).

[0198] An operation test request refers to a virtual generic domain operation request automatically generated by the server to simulate real business scenarios. Operation test requests include test business association information related to the newly added business information (i.e., virtual business association information) and generic domain test requests (i.e., virtual generic domain test requests). For example, an operation test request could be a simulated approval form marked "TEST".

[0199] In some embodiments, the test service association information must include the key characteristics of the newly added service. For example, if "East China Region" is added, the test service association information must include "Region: East China Region" to verify whether the service can be correctly routed to the person in charge of East China Region.

[0200] For more information on general domain operation requests, business association information, and general domain test requests, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0201] The test permission code refers to the permission code used during the testing process (a permission code is a structured identifier used to uniquely identify the permissions, roles, or functions required in a specific business scenario). In some embodiments, the server 110 can utilize the aforementioned... Figure 2 Using the same method as step 220, the test permission code is determined based on the test business association information and the general domain test request.

[0202] Test users refer to virtual users or testers during the testing process. In some embodiments, server 110 can use test permission codes to retrieve information from a permission code mapping table to determine the user identification information of one or more test users. If configured correctly, the retrieved test user should be the newly configured responsible person (e.g., "Zhang San / U008"). For more information on this, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0203] The second user set refers to the set of valid user identification information that, after screening and verification during the testing process, should actually receive the target test information body. In some embodiments, server 110 generates the second user set based on the retrieved user identification information of the test users. The generation logic of the second user set is similar to that of the aforementioned first user set. For more information on the first user set, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0204] In some embodiments, server 110 sends test service association information, a general domain test request, and a second user set to the general domain system. The general domain system generates a target test information body and sends it to the test users in the second user set. The method for generating the test service association information, the general domain test request, the second user set, and the target test information body is similar to the aforementioned method for generating the service association information, the general domain request, the first user set, and the target information body. For more information on generating the service association information, the general domain request, the first user set, and the target information body, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0205] In some embodiments, server 110 can confirm receipt in various ways. For example, it can receive a "sent successfully" receipt returned by a generic domain system. Another example is that the target test message body may contain a "confirm receipt" button, which the system receives a feedback signal upon being clicked by the test user.

[0206] In some embodiments, in response to confirming that all test users have successfully received the information, server 110 determines that the test has passed and marks the newly added mapping relationship as "officially effective".

[0207] In some embodiments of this specification, a "safety valve" is constructed before the configuration takes effect by executing a test verification mechanism. By simulating real business flow paths, the system can automatically verify whether the newly configured permission rules are effective and whether the personnel mapping is accurate without affecting actual business operations. This effectively avoids the risk of information sending failures or to the wrong recipients after the formal business goes live due to configuration errors (such as incorrect regional codes), ensuring the security of expansion and the reliability of the system.

[0208] In some embodiments of this specification, dynamic configuration is supported throughout the entire process, from the definition of basic code to the mapping of specific personnel. When an enterprise's business scope expands, no developer intervention is required to modify the code. Operations personnel only need to configure the newly added business dimensions and personnel in the backend, and the corresponding permission logic will be automatically generated and put into use. This mechanism also realizes a highly efficient management mode of "one-time expansion, batch authorization". Administrators only need to complete the expansion configuration of the basic business dimension once (such as adding a building), and the system can support batch generation and authorization of permissions for multiple users or multiple positions involved in that dimension based on rules, avoiding repetitive and inefficient work and significantly reducing the workload of manual configuration. This "configure and use" capability greatly shortens the launch cycle of business domain systems and improves the enterprise's responsiveness to market changes.

[0209] Figure 5 These are exemplary block diagrams of an information transmission system according to some embodiments of this specification. Figure 5The information transmission system 500 includes an acquisition module 510, an authorization determination module 520, an identification information determination module 530, a generation module 540, and a transmission module 550.

[0210] In some embodiments, the information transmission system 500 may also be referred to as the Human Rights and Transaction Intelligent Verification System (hereinafter referred to as the Human Rights and Transaction System). The Human Rights and Transaction Intelligent Verification System is a core processing system used to uniformly manage permission logic, parse the identity of target users, and coordinate information transmission. In some embodiments, the Human Rights and Transaction Intelligent Verification System acts as intelligent middleware between the business domain system (demand side) and the general domain system (executor). It stores a permission code mapping table, used to receive authentication requests initiated by the business domain system and general domain requests initiated by users in the business domain system, complete authentication, and invoke the general domain system to complete the user's general domain request.

[0211] For more information on permission code mapping tables, business domain systems, general domain systems, and general domain requests, please refer to [link to relevant documentation]. Figure 2 And its related description. For more information on authentication requests, please refer to... Figure 3 And its related descriptions.

[0212] In some embodiments, one or more of the acquisition module 510, the permission determination module 520, the identification information determination module 530, the generation module 540, and the transmission module 550 may be integrated into the server 110. Further details about the server 110 can be found in [link to relevant documentation]. Figure 1 Related descriptions.

[0213] In some embodiments, the acquisition module 510 is configured to acquire a general domain operation request sent by the business domain system. The general domain operation request includes business association information and a general domain request.

[0214] In some embodiments, the permission determination module 520 is configured to determine the target permission code based on business association information and general domain requests.

[0215] In some embodiments, the identification information determination module 530 is configured to determine user identification information of one or more target users based on the target permission code and a permission code mapping table. The permission code mapping table includes the mapping relationship between user identification information and permission codes.

[0216] In some embodiments, the generation module 540 is configured to generate a first user set based on user identification information of one or more target users.

[0217] In some embodiments, the generation module 540 is further configured to generate a candidate user set, which includes user identification information of one or more target users; determine whether one or more target users are in an invalid state based on the user identification information of one or more target users; wherein, an invalid state includes a resignation state and / or a vacation state; delete the user identification information of the target users in the candidate user set who are in an invalid state, and generate a first user set.

[0218] In some embodiments, the transmission module 550 is configured to transmit service association information, a general domain request, and a first user set to a general domain system, so that the general domain system generates a target information body based on the service association information and the general domain request, and sends the target information body to one or more target users.

[0219] For further explanation of the above content, please refer to Figures 1-4 and its corresponding embodiments.

[0220] This specification provides a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions from the storage medium, the computer executes the information transmission method described above.

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

[0222] Furthermore, unless expressly stated in the claims, the order of elements and sequences, the use of numbers and letters, or other names 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 an existing server or mobile device.

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

[0224] Finally, it should be understood that the embodiments 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 in this specification are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments in this specification are not limited to those explicitly described and illustrated herein.

Claims

1. An information volume transmission method characterized by comprising: The method is executed by a server. The information transmission system includes an acquisition module, an authorization determination module, an identification information determination module, a generation module, and a transmission module. One or more of the acquisition module, the authorization determination module, the identification information determination module, the generation module, and the transmission module are integrated into the server. The method includes: The acquisition module obtains a general domain operation request sent by the business domain system. The general domain operation request includes business association information and a general domain request. The permission determination module determines the target permission code based on the business association information and the general domain request. The identification information determination module determines the user identification information of one or more target users based on the target permission code and the permission code mapping table. The permission code mapping table includes the mapping relationship between user identification information and permission codes. The permission code includes dynamic permission segments. The dynamic permission segments include business area codes, professional codes, and responsibility codes. The business area codes, professional codes, and responsibility codes are each obtained based on a finite set of codes. The permission code also includes a basic permission segment. The basic permission segment reflects the business type. The permission code mapping table is pre-built and dynamically maintained. The generation module generates a first user set based on the user identification information of the one or more target users; The transmission module transmits the business association information, the general domain request, and the first user set to the general domain system, so that the general domain system can generate a target information body based on the business association information and the general domain request, and send the target information body to the one or more target users. The target information body refers to a data entity that has been formatted and can be directly displayed to the one or more target users for viewing or interaction by the general domain system.

2. The method of claim 1, wherein, The method further includes: Obtain the authentication request sent by the business domain system; the authentication request is generated based on the user's access request to the page, and the authentication request includes the user's user identification information and the page identification information of the page; Based on the user identification information and the page identification information, an authentication result is determined and sent to the business domain system. The authentication result includes the valid operation types that the user has permission to perform on the page and the user's data jurisdiction. This enables the business domain system to generate a page view of the page based on the page data and the authentication result. The page view includes one or more data items from the page data that belong to the user's data jurisdiction. Each of the one or more data items has a trigger control corresponding to the valid operation type.

3. The method of claim 2, wherein, The determination of the authentication result based on the user identification information and the page identification information includes: Based on the user identification information and the permission code mapping table, the permission code corresponding to the user identification information is determined; Based on the permission code corresponding to the user identification information, obtain the basic permission segment corresponding to the user identification information; Based on the basic permission segment corresponding to the user identification information, the page identification information, and the association rule table, the valid operation type is determined; Based on the permission code corresponding to the user identification information, obtain the dynamic permission segment corresponding to the user identification information; The scope of data jurisdiction is determined based on the dynamic permission segment corresponding to the user identification information.

4. The method of claim 2, wherein, The trigger control corresponding to the valid operation type includes one or more of the following: Trigger controls for initiating approvals, initiating messages, initiating pending tasks, and initiating data archiving.

5. The method of claim 4, wherein, The general domain operation request is generated by the business domain system based on the user's trigger operation on the trigger control corresponding to the valid operation type.

6. The method according to claim 1, characterized in that, The general domain operation request is generated by the business domain system based on a preset business event.

7. The method according to claim 1, characterized in that, The step of generating the first user set based on the user identification information of the one or more target users includes: Generate a candidate user set, the candidate user set including user identification information of the one or more target users; Based on the user identification information of the one or more target users, determine whether the one or more target users are in an invalid state; wherein, the invalid state includes a resigned state and / or a vacation state; Delete the user identification information of the target users in the invalid state from the candidate user set, and generate the first user set.

8. The method according to claim 1, characterized in that, The generation of the target information body based on the business association information and the general domain request includes: Based on the business association information and the general domain request, a target template is determined through a template library; the template library includes multiple templates, each of which has a corresponding information body type and applicable scenario; each template includes one or more form fields, which are related to the information body type and applicable scenario corresponding to each template; Fill in the form fields in the target template based on the business association information.

9. The method according to claim 8, characterized in that, The information types include approvals, pending tasks, messages, and data archives.

10. The method according to claim 1, characterized in that, The method further includes: Obtain a service expansion request, wherein the service expansion request includes information on adding new services; Based on the newly added business information, coding elements are added to one or more sets in the basic coding set; the basic coding set includes a business area coding set, a professional coding set, and a responsibility coding set.

11. The method according to claim 10, characterized in that, The method further includes: Obtain the user identification information associated with the service expansion request and the data jurisdiction of the user identification information in the new service information; Based on the data jurisdiction of the user identification information in the newly added business information, determine the dynamic permission segment corresponding to the user identification information from one or more sets in the basic coding set; Based on the user identification information, the basic permission segment is determined; Based on the user identification information, the dynamic permission segment, and the basic permission segment, permission code mapping data is generated and written into the permission code mapping table.

12. The method according to claim 11, characterized in that, The method further includes: Determine the operation test request, which includes test service association information related to the newly added service information and a general domain test request; Based on the test service association information and the general domain test request, the test permission code is determined; Based on the test permission code and the permission code mapping table, determine the user identification information of one or more test users; A second user set is generated based on the user identification information of the one or more test users; The test service association information, the general domain test request, and the second user set are transmitted to the general domain system, so that the general domain system generates a target test information body based on the test service association information and the general domain test request, and sends the target test information body to the one or more test users; Confirm whether the one or more test users have received the target test message body; If all or more test users receive the target test information body, the test is confirmed to have passed.

13. A computer-readable storage medium, characterized in that, The storage medium stores computer instructions. When the computer reads the computer instructions from the storage medium, the computer executes the method as described in any one of claims 1-12.

Images