Multi-level knowledge sharing and approval methods and systems based on organizational structure

Abstract

This invention discloses a multi-level knowledge sharing and approval method and system based on organizational structure, relating to the fields of knowledge management, workflow approval, and access control. It addresses the lack of flexibility and configurability in the scope and approval process of knowledge sharing in existing technologies. This invention pre-constructs an organizational structure tree and defines the sharing scope type and approval flow. Responding to knowledge publishing requests, it dynamically parses the target organization node set as the approval context based on the user's node and the sharing scope type. During the approval process, it dynamically parses the approver based on the target organization node set and the approval role, and supports knowledge classification path correction at the final node. After approval, it establishes access permission rules based on the target organization node set to achieve precise authorization. For deletion requests of published knowledge, it triggers a reverse approval process to revoke access permissions. This invention achieves dynamic approval and access control based on organizational structure, improving the automation and flexibility of the knowledge sharing process.

Description

Technical Field

[0001] This invention belongs to the fields of knowledge management, workflow approval and access control, specifically a multi-level knowledge sharing and approval method and system based on organizational structure. Background Technology

[0002] With the continuous deepening of enterprise informatization, knowledge management systems have become an important infrastructure for organizations to accumulate experience, share information, and improve collaboration efficiency. In large enterprises or institutions, the organizational structure is usually a complex structure with multiple levels, departments, and positions. Employees at different levels have different needs for knowledge access, and the scope of knowledge sharing needs to be precisely controlled while ensuring information security.

[0003] Current knowledge-sharing systems typically employ role-based or position-based access control, which predefines user roles and assigns access permissions to each role. However, this static permission configuration is ill-suited to dynamic changes in organizational structure. When departments reorganize, positions change, or personnel move, permission maintenance becomes labor-intensive and prone to oversights. Furthermore, knowledge publishing often requires multi-level approvals. Traditional approval processes are usually tied to specific positions, with relatively fixed approvers at each stage, making it impossible to flexibly adjust based on the actual scope of knowledge sharing. This results in a disconnect between the approval process and the target audience of the knowledge itself.

[0004] On the other hand, in knowledge lifecycle management, the classification path of knowledge is key metadata affecting subsequent retrieval and utilization. However, existing knowledge publishing processes typically determine the classification upon submission, and the approval process cannot correct it, reducing the accuracy of knowledge organization. Furthermore, the deletion of published knowledge usually lacks a corresponding reverse approval mechanism, which can easily lead to the accidental or unauthorized deletion of important knowledge, affecting the integrity of knowledge assets.

[0005] Therefore, how to achieve a dynamic correlation between the scope of knowledge sharing and the approval process, so that the approval node can automatically match the approver according to the actual audience of the knowledge, support metadata correction during the approval process, and establish a complete knowledge release and revocation permission control mechanism are technical problems that urgently need to be solved in this field.

[0006] The following problems exist in the existing technology: In existing methods, the approval process is usually statically bound to the submitter's job role, and is not related to which organizational units the knowledge will ultimately be shared with. When the scope of knowledge sharing is different (e.g., limited to within a department or for the entire group), the approval path cannot be automatically adapted to the sharing goal, resulting in a mismatch between the approval process and business needs. Existing methods require users to manually select visible departments or personnel, and cannot complete the scope setting with one click through abstract semantics such as "share to this department and all its subordinate units"; the operation is cumbersome for users, and when the organizational structure is adjusted, the set knowledge sharing scope cannot be automatically synchronized, requiring manual maintenance one by one, which is prone to permission vulnerabilities. In existing methods, the knowledge classification path is fixed at the time of submission, and the approver can only make a decision to approve or reject, and cannot correct classification errors during the approval process; if the classification is inappropriate, it can only be rejected and resubmitted, which leads to a longer approval cycle and reduced efficiency. Existing methods typically allow knowledge owners or authorized administrators to directly delete published knowledge, lacking the necessary reverse review process; important knowledge may be deleted arbitrarily due to misoperation or human factors, affecting the integrity and security of knowledge assets. Summary of the Invention

[0007] The present invention aims to solve at least one of the technical problems existing in the prior art; to this end, the present invention proposes a multi-level knowledge sharing and approval method and system based on organizational structure to solve the above-mentioned technical problems.

[0008] The first aspect of this invention provides a multi-level knowledge sharing and approval method based on organizational structure, comprising the following steps: S1: A pre-built organizational structure tree, which consists of a set of organizational nodes representing organizational units and a set of edges representing the hierarchical relationships between organizational units; multiple predefined shared scope types, each associated with a parsing rule that calculates the target organizational node set from the user's organizational node; multiple predefined approval flow definitions, each associated with at least one shared scope type, and the approval nodes in the approval flow definition are configured with approval roles related to the target organizational node set; S2: In response to a user's request to operate on knowledge, determine the type of the operation request; if it is a knowledge publishing request, receive the knowledge submitted by the user, and obtain the target sharing scope type selected by the user from the sharing scope type, the user's position node in the organizational structure tree, and the knowledge classification path of the knowledge; calculate the target organizational node set according to the parsing rules and position nodes corresponding to the target sharing scope type, and associate and store the target organizational node set and the knowledge classification path with the metadata of the knowledge; S3: Generate an approval process instance based on the approval flow definition associated with the target shared scope type, and use the target organization node set as the context data of the approval process instance; S4: During the execution of the approval process instance, for the current approval node, based on the approval role configured in the approval node and the target organization node set, query the user who belongs to the target organization node set and has the approval role, and make them the approver of the current approval node, and push the approval task to the approver; when the approval node is the last approval node and the approver approves, if a correction instruction for the knowledge classification path of the knowledge is received, update the metadata of the knowledge according to the correction instruction; S5: After all approval nodes of the approval process instance have been approved, update the status of the knowledge to published, and establish access permission rules for the knowledge based on the target organization node set; S6: If the operation request is a deletion request for published knowledge, a reverse approval process is triggered. Once the reverse approval process is completed, the access permission for the knowledge is revoked.

[0009] Preferably, S1 includes: The organizational nodes of the organizational structure tree have type attributes that represent organizational levels. These type attributes are used to identify organizational units at different levels in the parsing rules. The parsing rule corresponding to the shared scope type is as follows: starting from the organizational node where the user is located in the organizational structure tree, traverse along the hierarchical direction of the organizational structure tree according to the preset hierarchical search direction to obtain the set of organizational nodes that meet the specific type conditions as the target organizational node set; let the target organizational node set be S, and the organizational node where the user is located be S. If the shared scope type is scope, then the parsing rule can be represented as follows: ,in This is an analytical function that iterates according to a preset direction. The approval roles configured in the approval flow definition and associated with the target organization node set are defined by role expressions. The role expressions specify the user roles corresponding to specific types of organization nodes in the target organization node set, and are resolved to specific approvers at runtime based on the target organization node set.

[0010] Preferably, in step S2, the target organization node set is calculated based on the parsing rules and location nodes corresponding to the target sharing scope type, and the target organization node set and knowledge classification path are associated and stored with the metadata of the knowledge, including the following steps: Using the user's location node in the organizational structure tree as input parameters, the parsing rule associated with the target shared scope type is invoked, the node traversal logic defined in the parsing rule is executed, and the target organizational node set consisting of several organizational node identifiers is output. Establish a many-to-many association between the identifier of each organization node in the target organization node set and the unique identifier of the knowledge, and write the knowledge classification path into the metadata record of the knowledge.

[0011] Preferably, step S3 includes the following steps: Based on the target shared scope type, query the predefined association relationship to obtain the corresponding approval flow definition; The workflow engine is invoked to generate an approval process instance using the approval flow definition as a template, and the target organization node set is bound to the approval process instance as a process variable, so that the target organization node set can be accessed by each approval node during the execution of the approval process instance. Establish and store the association between the unique identifier of the approval process instance and the unique identifier of the knowledge.

[0012] Preferably, step S4 includes the following steps: When the approval process instance reaches the current approval node, the approval role configured for that approval node is parsed to determine the target organization node type t and the approval role name r associated with the approval role; From the target organizational node set S, select organizational nodes whose organizational node type matches the target organizational node type t to form a subset of target type organizational nodes. ; For each organization node v in the subset of organization nodes of the target type, query the users with the same approval role name r under that organization node, and merge all the queried users as the approver set of the current approval node. , where role(u,v) represents the approval role that user u has under organization node v; Generate approval tasks for each user in the approver set and push the approval tasks to the corresponding users; When the current approval node is an unapproved node, an entry point for correcting the knowledge classification path of the knowledge is provided on the approval interface; in response to the new knowledge classification path submitted by the approver through the correction entry point, and after the approver makes an approval decision, the new knowledge classification path is written into the metadata record of the knowledge to replace the original knowledge classification path.

[0013] Preferably, in step S5, establishing the access permission rules for the knowledge based on the target organization node set includes the following steps: For each organization node in the target organization node set, obtain all descendant organization nodes of that organization node in the organization structure tree, and use the set of all obtained descendant organization nodes as the visible organization node set of the knowledge. The set of visible organization nodes is associated with the identifier of the knowledge and stored in the permission storage; In response to a user's request to access the knowledge, the set of organizational nodes to which the user belongs is obtained, and it is determined whether there is an intersection between the set of organizational nodes to which the user belongs and the set of visible organizational nodes of the knowledge. If there is an intersection, access is allowed.

[0014] Preferably, step S6 includes the following steps: In response to a deletion request for published knowledge in an operation request, retrieve the set of target organization nodes associated with the knowledge at the time of publication; Based on the preset association relationship, match the reverse approval flow definition corresponding to the knowledge; A reverse approval process instance is generated using the reverse approval flow definition as a template, and the target organization node set is bound to the reverse approval process instance as context data. During the execution of the reverse approval process instance, for the current approval node, the approver is dynamically parsed and the approval task is pushed according to the approval role configured for the node and the target organization node set; Once all approval nodes of the reverse approval process instance have been approved, the access permission for the knowledge is revoked, making the knowledge invisible to the user.

[0015] A second aspect of the present invention provides a multi-level knowledge sharing and approval system based on organizational structure, comprising the following modules: Basic building blocks: A pre-built organizational structure tree, which consists of a set of organizational nodes representing organizational units and a set of edges representing the hierarchical relationships between organizational units; multiple predefined shared scope types, each associated with a parsing rule that calculates the target organizational node set from the user's organizational node; and multiple predefined approval flow definitions, each associated with at least one shared scope type, and the approval nodes in the approval flow definition are configured with approval roles related to the target organizational node set. Request parsing module: In response to a user's request to operate on knowledge, it determines the type of the operation request; if it is a knowledge publishing request, it receives the knowledge submitted by the user and obtains the target sharing scope type selected by the user from the sharing scope type, the user's position node in the organizational structure tree, and the knowledge classification path of the knowledge; according to the parsing rules corresponding to the target sharing scope type and the position node, it calculates the target organizational node set, and associates and stores the target organizational node set and the knowledge classification path with the metadata of the knowledge; Process instantiation module: Based on the approval flow definition associated with the target shared scope type, it generates an approval process instance and uses the target organization node set as the context data of the approval process instance; Dynamic Approval Module: During the execution of the approval process instance, for the current approval node, based on the approval role configured for the approval node and the target organization node set, query the user belonging to the target organization node set and having the approval role, and appoint the user as the approver for the current approval node, and push the approval task to the approver; when the approval node is the last approval node and the approver approves, if a correction instruction for the knowledge classification path of the knowledge is received, update the metadata of the knowledge according to the correction instruction; Release Authorization Module: After all approval nodes of the approval process instance have been approved, the status of the knowledge is updated to published, and access permission rules for the knowledge are established according to the target organization node set; Reverse Approval Module: If the operation request is a deletion request for published knowledge, the reverse approval process is triggered. Once the reverse approval process is completed, the access permission for the knowledge is revoked.

[0016] Compared with the prior art, the beneficial effects of the present invention are: This invention predefines multiple shared scope types and associates the approval flow definition with the shared scope type. After the user selects the target shared scope type, it automatically matches and generates the corresponding approval process instance, so that the approval path can be dynamically adjusted according to the shared target, thus solving the problem of fixed approval process. This invention uses predefined parsing rules for shared scope types to dynamically calculate the target organizational node set based on the user's position node in the organizational structure tree after the user selects the shared scope, and stores the node set in association with knowledge metadata; when publishing, access permission rules are established based on the node set, which realizes precise authorization that matches the organizational tree level, simplifies user operations, and the permission semantics can be automatically maintained when the organizational structure changes. This invention provides an entry point for correcting knowledge classification paths at the end of the approval process. Approver can submit new knowledge classification paths while approving the application, thereby updating the knowledge's metadata. This mechanism allows for direct correction of classification errors during the approval process, avoiding the cumbersome process of rejection and resubmission, and improving the accuracy of knowledge organization and approval efficiency. This invention triggers a reverse approval process for deletion requests of published knowledge. Access to the knowledge can only be revoked after the reverse approval is approved. This mechanism forms a two-way approval closed loop of forward publication and reverse deletion, effectively preventing important knowledge from being deleted arbitrarily and ensuring the integrity and security of knowledge assets. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0018] Figure 2 This is a schematic diagram of the module flow of the present invention. Detailed Implementation

[0019] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0020] Please see Figure 1 This invention is a multi-level knowledge sharing and approval method based on organizational structure, comprising the following steps: S1: A pre-built organizational structure tree, which consists of a set of organizational nodes representing organizational units and a set of edges representing the hierarchical relationships between organizational units; multiple predefined shared scope types, each associated with a parsing rule that calculates the target organizational node set from the user's organizational node; multiple predefined approval flow definitions, each associated with at least one shared scope type, and the approval nodes in the approval flow definition are configured with approval roles related to the target organizational node set; S2: In response to a user's request to operate on knowledge, determine the type of the operation request; if it is a knowledge publishing request, receive the knowledge submitted by the user, and obtain the target sharing scope type selected by the user from the sharing scope type, the user's position node in the organizational structure tree, and the knowledge classification path of the knowledge; calculate the target organizational node set according to the parsing rules and position nodes corresponding to the target sharing scope type, and associate and store the target organizational node set and the knowledge classification path with the metadata of the knowledge; S3: Generate an approval process instance based on the approval flow definition associated with the target shared scope type, and use the target organization node set as the context data of the approval process instance; S4: During the execution of the approval process instance, for the current approval node, based on the approval role configured in the approval node and the target organization node set, query the user who belongs to the target organization node set and has the approval role, and make them the approver of the current approval node, and push the approval task to the approver; when the approval node is the last approval node and the approver approves, if a correction instruction for the knowledge classification path of the knowledge is received, update the metadata of the knowledge according to the correction instruction; S5: After all approval nodes of the approval process instance have been approved, update the status of the knowledge to published, and establish access permission rules for the knowledge based on the target organization node set; S6: If the operation request is a deletion request for published knowledge, a reverse approval process is triggered. Once the reverse approval process is completed, the access permission for the knowledge is revoked.

[0021] Specifically, firstly, an organizational structure tree is pre-constructed, consisting of organizational nodes representing organizational units and edges indicating hierarchical relationships. Simultaneously, multiple shared scope types are pre-defined, each associated with a parsing rule used to calculate the target organizational node set from the user's organizational node. Additionally, multiple approval flow definitions are pre-defined, each associated with at least one shared scope type, and the approval node is configured with an approval role related to the target organizational node set. When a user initiates a knowledge operation request, the request type is determined: if it's a knowledge publishing request, the submitted knowledge is received, and the user's selected target shared scope type, the user's position node in the organizational structure tree, and the knowledge classification path are obtained. Then, the parsing rule corresponding to that shared scope type is invoked, using the position node as input to calculate the target organizational node set, and this node set and knowledge classification path are associated and stored with the knowledge's metadata. Subsequently, an approval process instance is generated based on the approval flow definition associated with the target shared scope type, and the target organizational node set is bound to this instance as context data. During the approval process, for the current approval node, based on the node's configured approval role and the target organization's node set, the system dynamically queries users belonging to that node set and possessing that role to act as approvers, and pushes the approval task to the corresponding approver. If the current node is the last node and the approver receives a correction instruction for the knowledge classification path upon approval, the knowledge's metadata is updated according to the instruction. Once all approval nodes have been approved, the knowledge status is updated to "published," and access permission rules are established based on the target organization's node set, allowing users under that node set and its descendant nodes to access the knowledge. If a user request is a deletion request for published knowledge, a reverse approval process is triggered, and access permissions for the knowledge are revoked after the reverse approval is successful.

[0022] In one embodiment of the present invention, S1 includes: The organizational nodes of the organizational structure tree have type attributes that represent organizational levels. These type attributes are used to identify organizational units at different levels in the parsing rules. The parsing rule corresponding to the shared scope type is as follows: starting from the organizational node where the user is located in the organizational structure tree, traverse along the hierarchical direction of the organizational structure tree according to the preset hierarchical search direction to obtain the set of organizational nodes that meet the specific type conditions as the target organizational node set; let the target organizational node set be S, and the organizational node where the user is located be S. If the shared scope type is scope, then the parsing rule can be represented as follows: ,in This is an analytical function that iterates according to a preset direction. The approval roles configured in the approval flow definition and associated with the target organization node set are defined by role expressions. The role expressions specify the user roles corresponding to specific types of organization nodes in the target organization node set, and are resolved to specific approvers at runtime based on the target organization node set.

[0023] Specifically, the organizational structure tree consists of organizational nodes and edges, used to describe the hierarchical relationships of an enterprise or organization. Each organizational node represents an organizational unit, containing a unique identifier, name, and type attribute. The type attribute distinguishes organizational units at different levels, such as pre-defined groups, subsidiaries, departments, and teams. The group is the highest-level organizational node (root node), subsidiaries are the sub-subsidiaries of the group, departments are the functional departments of subsidiaries, and teams are the smallest working units within departments. Each organizational node in the organizational structure tree points to its direct superior organizational node through its parent organizational node identifier; this pointing relationship is the edge. All edges originate from the root organizational node and connect layer by layer to the leaf organizational nodes, forming a complete tree structure.

[0024] Several shared scope types are predefined. These shared scope types are user-visible semantic options, each bound to a resolution rule used to transform the user-selected semantic scope into a specific set of organizational nodes. For example, they can be predefined into four basic types: Private, Department, Subordinate Second-Level Enterprise, and Entire Group. Private indicates visibility only to the user, and its resolution rule returns an empty set. Department represents the user's current department node, and its resolution rule returns the user's own organizational node. Subordinate Second-Level Enterprise represents the user's subordinate company and all its subordinate departments; its resolution rule first searches upwards to the user's subordinate company node, then returns that organizational node and all its descendant organizational nodes. Entire Group represents all organizational nodes in the entire organizational structure tree, and its resolution rule returns the root organizational node and all its descendant organizational nodes. To formally describe the resolution rules, a resolution function is defined. This function uses the user's organization node. The function Φ takes the shared scope type as input and outputs the target organization node set S. The internal logic of function Φ performs different traversal operations depending on the scope. Specifically, for the corresponding second-level enterprise type, The execution process is as follows: from Begin traversing upwards along the parent organization node chain, searching for the first node organization v with the type attribute of a second-level company. If v is found, then traverse downwards from v to all descendant organization nodes (including v itself), adding all these organization nodes to S. If not found, either return an empty set or, by default, return the root organization node and its descendants, depending on the predefined criteria. For this department type, Directly return containing A collection of single elements. For the entire group type, Starting from the root node, traverse down through all organizational nodes and return the complete set.

[0025] The approval flow is defined as a predefined approval process template. Each approval flow definition is associated with one or more shared scope types. For example, for the shared scope type "belonging to a second-level enterprise", an approval flow containing two approval nodes, "department manager approval" and "second-level company director approval", can be associated. Each approval node in the approval flow definition is configured with an approval role, which is defined by a role expression. The role expression specifies the user role corresponding to a specific type of organizational node in the target organizational node set. For example, "department manager@target_dept" represents the department manager role for all organizational nodes of type "department" in the target organizational node set.

[0026] During the approval process, the role expression configured for the current approval node is parsed. Specifically, when the approval process reaches a certain approval node, a subset of organizational nodes matching the type specified by the expression is first selected based on the target organizational node set S. Then, for each organizational node, users with the specified role name under that organizational node are queried. Finally, all the queried users are merged into the set of approvers for that approval node. The association between users, roles, and organizational nodes is stored in a pre-built user role table. Each record contains a user identifier, an organizational node identifier, and a role name. For example, if user Li Si is granted the role of "Department Manager" in the "Energy Sales Department," then there is a record in the user role table (user identifier = Li Si, organizational node identifier = Energy Sales Department, role name = "Department Manager").

[0027] In one embodiment of the present invention, step S2 involves calculating a target organization node set based on the parsing rules and location nodes corresponding to the target sharing scope type, and then associating and storing the target organization node set and the knowledge classification path with the metadata of the knowledge. This includes the following steps: Using the user's location node in the organizational structure tree as input parameters, the parsing rule associated with the target shared scope type is invoked, the node traversal logic defined in the parsing rule is executed, and the target organizational node set consisting of several organizational node identifiers is output. Establish a many-to-many association between the identifier of each organization node in the target organization node set and the unique identifier of the knowledge, and write the knowledge classification path into the metadata record of the knowledge.

[0028] Specifically, when a user initiates a knowledge operation request, the type of the request is determined. If it is a knowledge publishing request, the user's position node in the organizational structure tree must first be determined. Each user is assigned a default organizational node upon registration, and this affiliation is recorded in the user's organizational relationship data. The user's organizational relationship data includes the user identifier and the identifier of the user's affiliated organizational node. For example, it can be stored in a two-dimensional table, with each record corresponding to a user's affiliation information. Assuming user Zhang San's user identifier is 10001 and his affiliated organizational node identifier is 1005, corresponding to the "Energy Sales Department" node. When processing a publishing request, the user identifier is obtained from the request context, and then the user's affiliated organizational node identifier is retrieved from the user's organizational relationship data based on this identifier. This identifier represents the user's position node in the organizational structure tree.

[0029] Next, the corresponding parsing rule is invoked based on the shared scope type selected by the user. The association between the shared scope type and the parsing rule is predefined and stored in the shared scope rule data. The shared scope rule data includes the shared scope type identifier and the rule definition. The rule definition describes the specific traversal logic in structured text form (e.g., JSON format). For example, the rule definition corresponding to the shared scope type "belonging to a second-level enterprise" can be expressed as: the traversal direction is upward, the target organization node type is second-level company, and the operation type is to retrieve all descendant organization nodes. The specific execution process of the parsing rule is as follows: starting from the user's location node, traversal begins according to the traversal direction (upward) defined by the rule; the parent organization node of the current organization node is repeatedly obtained, and the type attribute of the current organization node is checked each time until the first organization node whose type attribute is equal to the target type (i.e., second-level company) specified in the rule is found; if found, traversal downward from that organization node, collecting the identifiers of that organization node and all its descendant organization nodes to form the target organization node set; if the specified type of organization node is not found after traversing upward to the root organization node, an empty set or the root organization node and all its descendant organization nodes are returned according to the preset processing method, depending on the actual business configuration. After the parsing rules are executed, the target organization node set is obtained, which consists of several organization node identifiers. Simultaneously, when submitting knowledge, the user provides a knowledge classification path, such as "technical materials / core algorithms"; the knowledge classification path is a string used to identify the storage location of the knowledge in the knowledge base.

[0030] Subsequently, the target organization node set and knowledge classification path are associated and stored with the knowledge's metadata. First, a unique identifier is generated for each knowledge item; this identifier can be an auto-incrementing integer or a universally unique identifier. The knowledge's metadata includes fields such as the unique identifier, title, content, uploader, upload time, and knowledge classification path. The user-submitted knowledge classification path is written into the corresponding field in the metadata, completing the storage of the knowledge classification path. Next, the association between the knowledge and each organization node in the target organization node set is established. Specifically, for each organization node identifier in the target organization node set, a correspondence between the unique identifier of the knowledge and the organization node identifier is recorded. These correspondences are stored in the form of many-to-many association data (e.g., a two-dimensional association table), with each record containing two fields: the unique identifier of the knowledge and the organization node identifier. Finally, the knowledge and its shared scope (i.e., the target organization node set) are persistently associated. For example, if the target organization node set contains five organization node identifiers: 1002, 1004, 1005, 1006, and 1007, then five association records are established, each containing the unique identifier of the knowledge and one of the organization node identifiers.

[0031] In one embodiment of the present invention, step S3 includes the following steps: Based on the target shared scope type, query the predefined association relationship to obtain the corresponding approval flow definition; The workflow engine is invoked to generate an approval process instance using the approval flow definition as a template, and the target organization node set is bound to the approval process instance as a process variable, so that the target organization node set can be accessed by each approval node during the execution of the approval process instance. Establish and store the association between the unique identifier of the approval process instance and the unique identifier of the knowledge.

[0032] Specifically, firstly, based on the target shared scope type selected by the user, a predefined association is queried to obtain the corresponding approval flow definition. This association is pre-configured and stored in step S1, for example, it can be stored in the shared scope and approval flow association data. The shared scope and approval flow association data includes a shared scope type identifier and an approval flow definition identifier. Each record represents a correspondence between a shared scope type and an approval flow definition. Assuming that user Zhang San selected the shared scope type as "belonging to a secondary enterprise", the corresponding approval flow definition identifier is obtained from the association data based on this type identifier, for example, denoted as flow_id=002. Then, based on this approval flow definition identifier, the complete approval flow definition content is loaded from the approval flow definition data. The approval flow definition is usually stored in structured text form, such as using JSON format to describe the approval nodes, transfer conditions, approval role configurations, etc. of the process. Assuming that the approval flow definition corresponding to flow_002 contains two approval nodes, the first approval node is configured with the approval role as "department manager@department", and the second approval node is configured with the approval role as "secondary company director@secondary company", and the sequential relationship between the approval nodes is defined.

[0033] Next, the workflow engine is invoked to generate an approval process instance from the obtained approval flow definition as a template. The workflow engine is the module responsible for creating and managing process instances. Based on the approval nodes and transition rules in the approval flow definition, the workflow engine instantiates an executable approval process instance and assigns a unique approval process instance identifier to it. Simultaneously, the target organization node set (denoted as S) is bound to the approval process instance as a process variable. Process variables are data attached to the approval process instance and can be accessed at each approval node during the approval process execution. Here, the target organization node set is bound to the process variable, typically stored as key-value pairs, such as a list of variables named `targetOrgNodes` with values ​​of `S`. Finally, when the approval process progresses to a certain approval node, that node can read `S` from the process context and dynamically parse the specific approver based on the approval role expression configured for that node.

[0034] After an approval process instance is generated, the association between the approval process instance and the knowledge is established and stored. The unique identifier of the knowledge is generated in step S2 and denoted as k_id; the unique identifier of the approval process instance is denoted as p_id. The correspondence between p_id and k_id is stored in the process instance and knowledge association data. For example, a two-dimensional association table can be used, where each record contains two fields: process instance identifier and knowledge identifier, and information such as creation time can also be added.

[0035] For example, user Zhang San publishes knowledge and selects the sharing scope type as the affiliated second-level enterprise; step S2 has calculated the target organization node set S={1002,1004,1005,1006,1007} ​​and generated a unique knowledge identifier k_id=20001; in step S3, based on the "affiliated second-level enterprise", the corresponding approval flow definition identifier flow_002 is found from the sharing scope and approval flow association data, and its approval flow definition is loaded; then the workflow engine is called to create an approval process instance using flow_002 as a template, obtaining the approval process instance identifier p_id=30001, and binding S as a process variable, for example, setting the value of the variable targetOrgNodes in the workflow engine to [1002,1004,1005,1006,1007]; finally, a record (p_id=30001, k_id=20001) is inserted into the process instance and knowledge association table.

[0036] Throughout the process, the workflow engine can adopt any existing business process management engine, such as Activiti or Flowable, or it can be a self-implemented lightweight engine, as long as it can create approval process instances and manage process variables according to the approval process definition.

[0037] In one embodiment of the present invention, step S4 includes the following steps: When the approval process instance reaches the current approval node, the approval role configured for that approval node is parsed to determine the target organization node type t and the approval role name r associated with the approval role; From the target organizational node set S, select organizational nodes whose organizational node type matches the target organizational node type t to form a subset of target type organizational nodes. ; For each organization node v in the subset of organization nodes of the target type, query the users with the same approval role name r under that organization node, and merge all the queried users as the approver set of the current approval node. , where role(u,v) represents the approval role that user u has under organization node v; Generate approval tasks for each user in the approver set and push the approval tasks to the corresponding users; When the current approval node is an unapproved node, an entry point for correcting the knowledge classification path of the knowledge is provided on the approval interface; in response to the new knowledge classification path submitted by the approver through the correction entry point, and after the approver makes an approval decision, the new knowledge classification path is written into the metadata record of the knowledge to replace the original knowledge classification path.

[0038] Specifically, in step S4, the approval process instance has been generated and carries the target organization node set S. When the approval process instance executes to an approval node, it first needs to parse the approval role configured for that approval node to determine the target organization node type and approval role name associated with that approval role. The configuration of the approval node is usually stored in the form of a role expression, such as Department Manager@Department; during parsing, the target organization node type t after the "@" symbol and the approval role name r before the "@" symbol are extracted from the role expression. In this example, t = Department, and r = Department Manager. The value range of the target organization node type t is one of the organization node types defined in step S1. The value range of the approval role name r is a predefined set of roles, such as Department Manager, Director, Legal Review, etc., and the specific value is set according to the actual situation when configuring the approval flow.

[0039] Next, select all organizational nodes in the target organizational node set S whose organizational node type matches t, forming a subset of organizational nodes of the target type. ,Right now Here, `type(v)` is the type attribute of organization node `v`, obtained by querying the organizational structure tree data. Each organization node in the organizational structure tree data stores its type; for example, organization node 1005 is of type "department". Assuming the current approval node is configured with `t=department`, then by filtering from `S={1002,1004,1005,1006,1007}`, organization nodes of type "department" are obtained. ={1004,1005}, because both organizational nodes 1004 and 1005 are of type "Department"; if no matching organizational node is found, then... If the set is empty, it will be processed according to the preset rules. For example, the approval node can be skipped or an exception can be thrown. However, it is usually necessary to ensure that the corresponding organization node exists when configuring the approval flow.

[0040] Then, for For each organization node v, it is necessary to query the user with the approval role name r under that organization node. "Having a role under an organization node" means that the user has been granted a specific role on that organization node; this authorization relationship is pre-stored in user role data. User role data includes user identifier, organization node identifier, and role name, and is stored, for example, in a two-dimensional table, where each record represents a user having a specific role on a specific organization node. Taking {1004, 1005} and r = Department Manager as an example, query the users with the role name "Department Manager" under organization node 1004. Assume the user set { is obtained. }, then query the users with the role name "Department Manager" under organization node 1005, assuming the user set is obtained as { }; Merge these two sets to obtain the set of approvers for the current approval node: Approvers={ The merge operation uses the union of sets, i.e. Where role(u,v) represents the role name that user u has under organization node v; if user u is granted multiple roles under organization node v, only the roles that are equal to r are considered; if no user has the role under a certain organization node, then the organization node does not contribute any users, but the merged set may still be empty. In this case, it needs to be handled according to the rules defined in the process, such as allowing the specification of a default approver or rejecting the task.

[0041] After obtaining the set of approvers, an approval task needs to be generated for each user in the set. Each approval task includes fields such as task identifier, process instance identifier, approval node identifier, approver user identifier, task status, and creation time. The initial status of the approval task is "pending approval." These approval tasks are then pushed to the corresponding users, either through a to-do list or by notifying users via email, instant messaging, or other means.

[0042] When the current approval node is marked as an unapproved node, the approval process definition typically sets an identifier in the approval node's attributes, such as isEndNode=true, or determines this based on the absence of other approval nodes following it. The approval interface for an unapproved node needs to provide an additional entry point for correcting the knowledge classification path, such as an editable text box pre-filled with the current knowledge classification path. The approver can modify this knowledge classification path when making an approval decision. When the approver makes an "Approve" decision and submits, if a new knowledge classification path is provided in the correction entry point, this new knowledge classification path is sent to the backend as part of the correction instruction.

[0043] After receiving the approval request, the backend first verifies whether the current approval node is an unapproved node, and then extracts the new knowledge category path from the request (if any). If a new knowledge category path exists, an update operation is performed; based on the knowledge's unique identifier k_id, the original knowledge category path field in the knowledge metadata is replaced with the new knowledge category path; after the update is completed, the operation log is recorded for traceability.

[0044] In one embodiment of the present invention, step S5, establishing access permission rules for the knowledge based on the target organization node set, includes the following steps: For each organization node in the target organization node set, obtain all descendant organization nodes of that organization node in the organization structure tree, and use the set of all obtained descendant organization nodes as the visible organization node set of the knowledge. The set of visible organization nodes is associated with the identifier of the knowledge and stored in the permission storage; In response to a user's request to access the knowledge, the set of organizational nodes to which the user belongs is obtained, and it is determined whether there is an intersection between the set of organizational nodes to which the user belongs and the set of visible organizational nodes of the knowledge. If there is an intersection, access is allowed.

[0045] Specifically, step S5 is executed after all approval nodes in the approval process instance have been approved. At this point, the knowledge status has been updated to published. Next, access permission rules for this knowledge are established based on the target organization's node set to control which users can access the knowledge.

[0046] To determine the actual visibility scope of this knowledge based on the target set of organizational nodes S, each organizational node in S and all its subordinate organizational nodes need to be considered, since sharing with an organizational unit implies that the unit and all its subordinate sub-units should be visible. Therefore, for each organizational node v in S, we first obtain all its descendant organizational nodes (including v itself) in the organizational structure tree. We define the function Desc(v) as the set of organizational node v and all its descendant organizational nodes; this function can be implemented by recursively traversing the organizational structure tree, for example, starting from organizational node v, collecting all descendant organizational nodes using a depth-first or breadth-first approach, and adding v itself to the set. The organizational structure tree data stores the parent organizational node identifier of each organizational node, so it can be traversed upwards or downwards.

[0047] By taking the union of all Desc(v), we obtain the set T of visible organizational nodes for this knowledge. For example, suppose in the organizational tree, the descendants of organizational node 1002 (Energy Division) include itself (1002), its child nodes 1004 (Energy Technology Department) and 1005 (Energy Sales Department), and the child nodes of 1005 are 1006 (Sales Group 1) and 1007 (Sales Group 2); the descendants of organizational node 1005 include itself (1005), 1006, and 1007; the descendants of organizational node 1004 include itself (1004); and the descendants of organizational nodes 1006 and 1007 are only themselves. Then, Desc(1002) = {1002, 1004, 1005, 1006, 1007}, and Desc(100... 4) = {1004}, Desc(1005) = {1005, 1006, 1007}, Desc(1006) = {1006}, Desc(1007) = {1007}; after taking the union, we get T = {1002, 1004, 1005, 1006, 1007}; if S contains some organization nodes, such as S = {1002, 1005}, then T = Desc(1002) ∪ Desc(1005) = {1002, 1004, 1005, 1006, 1007}; if S contains only one leaf organization node, such as S = {1006}, then T = {1006}.

[0048] After obtaining the set T of visible organization nodes, this set T is associated with a unique identifier of the knowledge and stored in the permission storage. The permission storage can be a database table or a caching system, for example, using key-value pairs, with the knowledge identifier as the key and T as the value. In specific implementations, a knowledge visible node association table can be created in a relational database, with each record containing the knowledge identifier and the visible organization node identifier; alternatively, the set can be directly stored in a cache such as Redis.

[0049] When any user initiates an access request to the knowledge, an access control step is executed. First, the set of organizational nodes U to which the user belongs is obtained. Information about the organizational nodes to which the user belongs is pre-stored in the user's organizational relationship data. Each user may be associated with one or more organizational nodes (e.g., in part-time situations). The user identifier is obtained from the request context, and then the user's organizational relationship data is queried to obtain the identifiers of all organizational nodes to which the user belongs, forming the organizational node set U. For example, if user Li Si belongs to the Energy Sales Department (organizational node 1005) and Project Group 1 (organizational node 1008), then U = {1005, 1008}.

[0050] Then determine whether U and T have an intersection, that is, whether there is at least one organizational node that belongs to both U and T. If the intersection is not empty, the user is allowed to access the knowledge; if the intersection is empty, access is denied. For example, if the visible organizational node set T of knowledge K is {1002, 1004, 1005, 1006, 1007}; user Zhang San's organizational node is Energy Sales Department (organization node ID 1005), which belongs to the visible organizational node set T, therefore he has the right to access the knowledge; user Wang Wu's organizational node is Project Group 1 (organization node ID 1008), which does not belong to the visible organizational node set T, therefore he has no right to access it.

[0051] In one embodiment of the present invention, step S6 includes the following steps: In response to a deletion request for published knowledge in an operation request, retrieve the set of target organization nodes associated with the knowledge at the time of publication; Based on the preset association relationship, match the reverse approval flow definition corresponding to the knowledge; A reverse approval process instance is generated using the reverse approval flow definition as a template, and the target organization node set is bound to the reverse approval process instance as context data. During the execution of the reverse approval process instance, for the current approval node, the approver is dynamically parsed and the approval task is pushed according to the approval role configured for the node and the target organization node set; Once all approval nodes of the reverse approval process instance have been approved, the access permission for the knowledge is revoked, making the knowledge invisible to the user.

[0052] Specifically, when a user initiates a request to delete published knowledge, the system first retrieves the target organization node set associated with the knowledge at the time of its publication. The metadata of each published knowledge stores the target organization node set S calculated at the time of its publication. At the same time, the metadata of the knowledge also records the sharing scope type used when it was published, such as the second-level enterprise to which it belongs. The system then retrieves the unique identifier k_id of the knowledge from the request and queries the knowledge metadata to obtain the corresponding target organization node set S and sharing scope type.

[0053] Next, the corresponding reverse approval flow definition is matched based on the shared scope type. The association between the reverse approval flow definition and the shared scope type is pre-configured and stored in the reverse approval flow association data. This association data contains a shared scope type identifier and a reverse approval flow definition identifier. Each record represents the correspondence between a shared scope type and a reverse approval flow definition. For example, for the shared scope type "belonging to a secondary enterprise", a reverse approval flow definition can be pre-configured with the identifier flow_del_id=002. This definition contains two approval nodes. The first approval node is configured with the approval role as department manager@department, and the second approval node is configured with the approval role as secondary company director@secondary company, and the order between the approval nodes is defined. The reverse approval flow definition identifier is obtained from the association data through the shared scope type. Then, the complete reverse approval flow definition content is loaded from the reverse approval flow association data based on this identifier. It is usually stored in structured text format (such as JSON).

[0054] After obtaining the reverse approval workflow definition, the workflow engine is invoked to generate a reverse approval workflow instance using this definition as a template. The workflow engine assigns a unique reverse approval workflow instance identifier to each instance. Simultaneously, the target organization node set S is bound to the reverse approval workflow instance as a workflow variable, typically stored as key-value pairs. This allows each approval node to access S during the execution of the reverse approval workflow instance to dynamically determine the approver.

[0055] After the reverse approval process instance is generated, it begins execution according to the defined order of approval nodes. When execution reaches an approval node, the approval role configured for that node is first parsed. Approval roles are typically defined in the form of role expressions; during parsing, the target organization node type t and the approval role name r are extracted from the expression. Then, all organization nodes with the same organization node type as t are selected from the target organization node set S, forming a subset of target type organization nodes. .

[0056] for For each organization node v, it is necessary to query the users with the approval role name r under that organization node. The association between users, roles, and organization nodes is pre-stored in user role data, which includes user identifier, organization node identifier, and approval role name. All queried users are merged to obtain the set of approvers for the current approval node. , where {role}(u,v) represents the approval role name that user u has under organization node v.

[0057] After obtaining the set of approvers, an approval task is generated for each user in the set. Each approval task includes fields such as task identifier, reverse approval process instance identifier, approval node identifier, approver user identifier, task status (initially "pending approval"), and creation time. These approval tasks are then pushed to the corresponding users, for example, through a to-do list or instant messaging notification.

[0058] When approving a task, the approver can make an "Approve" or "Reject" decision. If any approval node is rejected, the reverse approval process instance terminates, the access permissions for the knowledge remain unchanged, and the deletion request is rejected. If all approval nodes are approved, the reverse approval process instance ends, triggering a permission revocation operation. The permission revocation operation specifically makes the knowledge invisible to any user; the implementation depends on the specific form of the permission storage. If the set of visible organization nodes T (i.e., the set of visible nodes calculated when the knowledge is published) is stored in a relational database's association table, all associated records for that knowledge are deleted. If it is stored in a cache (such as Redis), the corresponding key is deleted. For example, executing a database delete statement deletes all records in the knowledge visible organization node association table whose knowledge identifier is equal to that knowledge, or clears the corresponding key in the cache. Afterward, any user attempting to access the knowledge will be denied access because the knowledge record is no longer in the permission storage.

[0059] For example, knowledge K is identified as k_id=20001, its target organizational node set S={1002,1004,1005,1006,1007}, and its sharing scope type is "belonging to a second-level enterprise"; user Zhang San initiates a deletion request; the corresponding reverse approval flow definition is found in the reverse approval flow association data, identified as flow_del_id=002, and after loading the definition, a reverse approval process instance is generated, identified as p_del_id=50001, and S is bound as a process variable; the first approval node of the reverse approval process is department manager@department, which is parsed to obtain ={1004,1005}, querying the organizational node 1004, the department manager is user Li Si, the organizational node 1005 is department manager Wang Wu, and the approver set is {Li Si, Wang Wu}; both receive the approval task and both approve it; the process enters the second approval node, which is the second-level company director@second-level company, filtering out the organizational node v=1002 of type second-level company from S, querying its director as Zhao Liu, and the approver set is {Zhao Liu}; after Zhao Liu approves, the reverse approval process ends, the permission revocation operation is performed, and all visible node association records of knowledge K are deleted; after this, no user can access this knowledge anymore.

[0060] Please see Figure 2 As shown, this invention is a multi-level knowledge sharing and approval system based on organizational structure, including the following modules: Basic building blocks: A pre-built organizational structure tree, which consists of a set of organizational nodes representing organizational units and a set of edges representing the hierarchical relationships between organizational units; multiple predefined shared scope types, each associated with a parsing rule that calculates the target organizational node set from the user's organizational node; and multiple predefined approval flow definitions, each associated with at least one shared scope type, and the approval nodes in the approval flow definition are configured with approval roles related to the target organizational node set. Request parsing module: In response to a user's request to operate on knowledge, it determines the type of the operation request; if it is a knowledge publishing request, it receives the knowledge submitted by the user and obtains the target sharing scope type selected by the user from the sharing scope type, the user's position node in the organizational structure tree, and the knowledge classification path of the knowledge; according to the parsing rules corresponding to the target sharing scope type and the position node, it calculates the target organizational node set, and associates and stores the target organizational node set and the knowledge classification path with the metadata of the knowledge; Process instantiation module: Based on the approval flow definition associated with the target shared scope type, it generates an approval process instance and uses the target organization node set as the context data of the approval process instance; Dynamic Approval Module: During the execution of the approval process instance, for the current approval node, based on the approval role configured for the approval node and the target organization node set, query the user belonging to the target organization node set and having the approval role, and appoint the user as the approver for the current approval node, and push the approval task to the approver; when the approval node is the last approval node and the approver approves, if a correction instruction for the knowledge classification path of the knowledge is received, update the metadata of the knowledge according to the correction instruction; Release Authorization Module: After all approval nodes of the approval process instance have been approved, the status of the knowledge is updated to published, and access permission rules for the knowledge are established according to the target organization node set; Reverse Approval Module: If the operation request is a deletion request for published knowledge, the reverse approval process is triggered. Once the reverse approval process is completed, the access permission for the knowledge is revoked.

[0061] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A multi-level knowledge sharing and approval method based on organizational structure, characterized in that: Includes the following steps: S1: A pre-built organizational structure tree, which consists of a set of organizational nodes representing organizational units and a set of edges representing the hierarchical relationships between organizational units; multiple predefined shared scope types, each associated with a parsing rule that calculates the target organizational node set from the user's organizational node; multiple predefined approval flow definitions, each associated with at least one shared scope type, and the approval nodes in the approval flow definition are configured with approval roles related to the target organizational node set; S2: In response to a user's request to operate on knowledge, determine the type of the operation request; if it is a knowledge publishing request, receive the knowledge submitted by the user, and obtain the target sharing scope type selected by the user from the sharing scope type, the user's position node in the organizational structure tree, and the knowledge classification path of the knowledge; Based on the parsing rules and location nodes corresponding to the target sharing scope type, the target organization node set is calculated, and the target organization node set and knowledge classification path are associated and stored with the metadata of the knowledge. S3: Generate an approval process instance based on the approval flow definition associated with the target shared scope type, and use the target organization node set as the context data of the approval process instance; S4: During the execution of the approval process instance, for the current approval node, based on the approval role configured in the approval node and the target organization node set, query the user who belongs to the target organization node set and has the approval role, and use him / her as the approver of the current approval node, and push the approval task to the approver; When the approval node is the last approval node and the approver approves, if a correction instruction for the knowledge classification path of the knowledge is received, the metadata of the knowledge is updated according to the correction instruction. S5: After all approval nodes of the approval process instance have been approved, update the status of the knowledge to published, and establish access permission rules for the knowledge based on the target organization node set; S6: If the operation request is a deletion request for published knowledge, a reverse approval process is triggered. Once the reverse approval process is completed, the access permission for the knowledge is revoked.

2. The multi-level knowledge sharing and approval method based on organizational structure according to claim 1, characterized in that, S1 includes: The organizational nodes of the organizational structure tree have type attributes that represent organizational levels. These type attributes are used to identify organizational units at different levels in the parsing rules. The parsing rule corresponding to the shared scope type is as follows: starting from the organizational node where the user is located in the organizational structure tree, traverse along the hierarchical direction of the organizational structure tree according to the preset hierarchical search direction to obtain the set of organizational nodes that meet the specific type conditions as the target organizational node set; let the target organizational node set be S, and the organizational node where the user is located be S. If the shared scope type is scope, then the parsing rule can be represented as follows: ,in This is an analytical function that iterates according to a preset direction. The approval roles configured in the approval flow definition and associated with the target organization node set are defined by role expressions. The role expressions specify the user roles corresponding to specific types of organization nodes in the target organization node set, and are resolved to specific approvers at runtime based on the target organization node set.

3. The multi-level knowledge sharing and approval method based on organizational structure according to claim 1, characterized in that, In step S2, the target organization node set is calculated based on the parsing rules and location nodes corresponding to the target sharing scope type, and the target organization node set and knowledge classification path are associated and stored with the metadata of the knowledge, including the following steps: Using the user's location node in the organizational structure tree as input parameters, the parsing rule associated with the target shared scope type is invoked, the node traversal logic defined in the parsing rule is executed, and the target organizational node set consisting of several organizational node identifiers is output. Establish a many-to-many association between the identifier of each organization node in the target organization node set and the unique identifier of the knowledge, and write the knowledge classification path into the metadata record of the knowledge.

4. The multi-level knowledge sharing and approval method based on organizational structure according to claim 1, characterized in that, S3 includes the following steps: Based on the target shared scope type, query the predefined association relationship to obtain the corresponding approval flow definition; The workflow engine is invoked to generate an approval process instance using the approval flow definition as a template, and the target organization node set is bound to the approval process instance as a process variable, so that the target organization node set can be accessed by each approval node during the execution of the approval process instance. Establish and store the association between the unique identifier of the approval process instance and the unique identifier of the knowledge.

5. The multi-level knowledge sharing and approval method based on organizational structure according to claim 1, characterized in that, S4 includes the following steps: When the approval process instance reaches the current approval node, the approval role configured for that approval node is parsed to determine the target organization node type t and the approval role name r associated with the approval role; From the target organizational node set S, select organizational nodes whose organizational node type matches the target organizational node type t to form a subset of target type organizational nodes. ; For each organization node v in the subset of organization nodes of the target type, query the users with the same approval role name r under that organization node, and merge all the queried users as the approver set of the current approval node. , where role(u,v) represents the approval role that user u has under organization node v; Generate approval tasks for each user in the approver set and push the approval tasks to the corresponding users; When the current approval node is an unapproved node, an entry point for correcting the knowledge classification path of the knowledge is provided on the approval interface; in response to the new knowledge classification path submitted by the approver through the correction entry point, and after the approver makes an approval decision, the new knowledge classification path is written into the metadata record of the knowledge to replace the original knowledge classification path.

6. The multi-level knowledge sharing and approval method based on organizational structure according to claim 1, characterized in that, In step S5, establishing access permission rules for the knowledge based on the target organization node set includes the following steps: For each organization node in the target organization node set, obtain all descendant organization nodes of that organization node in the organization structure tree, and use the set of all obtained descendant organization nodes as the visible organization node set of the knowledge. The set of visible organization nodes is associated with the identifier of the knowledge and stored in the permission storage; In response to a user's request to access the knowledge, the set of organizational nodes to which the user belongs is obtained, and it is determined whether there is an intersection between the set of organizational nodes to which the user belongs and the set of visible organizational nodes of the knowledge. If there is an intersection, access is allowed.

7. The multi-level knowledge sharing and approval method based on organizational structure according to claim 1, characterized in that, S6 includes the following steps: In response to a deletion request for published knowledge in an operation request, retrieve the set of target organization nodes associated with the knowledge at the time of publication; Based on the preset association relationship, match the reverse approval flow definition corresponding to the knowledge; A reverse approval process instance is generated using the reverse approval flow definition as a template, and the target organization node set is bound to the reverse approval process instance as context data. During the execution of the reverse approval process instance, for the current approval node, the approver is dynamically parsed and the approval task is pushed according to the approval role configured for the node and the target organization node set; Once all approval nodes of the reverse approval process instance have been approved, the access permission for the knowledge is revoked, making the knowledge invisible to the user.

8. The multi-level knowledge sharing and approval system based on organizational structure according to claim 1, characterized in that, Includes the following modules: Basic building blocks: A pre-built organizational structure tree, which consists of a set of organizational nodes representing organizational units and a set of edges representing the hierarchical relationships between organizational units; multiple predefined shared scope types, each associated with a parsing rule that calculates the target organizational node set from the user's organizational node; and multiple predefined approval flow definitions, each associated with at least one shared scope type, and the approval nodes in the approval flow definition are configured with approval roles related to the target organizational node set. Request parsing module: Responds to user requests for knowledge operations and determines the type of the operation request; If it is a knowledge publishing request, the knowledge submitted by the user is received, and the target sharing scope type selected by the user from the sharing scope type, the user's location node in the organizational structure tree, and the knowledge classification path of the knowledge are obtained. Based on the parsing rules and location nodes corresponding to the target sharing scope type, the target organization node set is calculated, and the target organization node set and knowledge classification path are associated and stored with the metadata of the knowledge. Process instantiation module: Based on the approval flow definition associated with the target shared scope type, it generates an approval process instance and uses the target organization node set as the context data of the approval process instance; Dynamic approval module: During the execution of the approval process instance, for the current approval node, based on the approval role configured for the approval node and the target organization node set, query the user who belongs to the target organization node set and has the approval role, and use him / her as the approver of the current approval node, and push the approval task to the approver; When the approval node is the last approval node and the approver approves, if a correction instruction for the knowledge classification path of the knowledge is received, the metadata of the knowledge is updated according to the correction instruction. Release Authorization Module: After all approval nodes of the approval process instance have been approved, the status of the knowledge is updated to "released", and access permission rules for the knowledge are established according to the target organization node set; Reverse Approval Module: If the operation request is a deletion request for published knowledge, the reverse approval process is triggered. Once the reverse approval process is completed, the access permission for the knowledge is revoked.

Images