Organizational tree management method, apparatus, device, and readable storage medium

By introducing strategies for inheritance depth and scope, the problem of cumbersome organizational label binding processes is solved, the flexibility and security of label strategies are improved, configuration management is simplified, and it can adapt to complex business environments.

CN122243030APending Publication Date: 2026-06-19CHINA MOBILE INFORMATION TECHNOLOGY CO LTD +1

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
CHINA MOBILE INFORMATION TECHNOLOGY CO LTD
Filing Date
2026-03-03
Publication Date
2026-06-19

AI Technical Summary

Technical Problem

The existing methods for binding organizational tags are cumbersome and inefficient, resulting in complicated configuration processes, high maintenance costs, and fragmentation of tag strategies due to human error or inconsistent operations.

Method used

An inheritance strategy is introduced, including inheritance depth and inheritance scope. By determining the target organization tag and its corresponding inheritance strategy, the organization tag is flexibly bound in the organization tree, controlling the propagation level and scope of the tag in the organization tree, supporting multiple propagation methods, and introducing modification permissions and node types to improve the flexibility and security of the strategy.

Benefits of technology

It significantly improves the flexibility, accuracy, and security of tag policy deployment, avoids the overgeneralization of tag policies, simplifies configuration management, and improves the adaptability and maintainability of the system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122243030A_ABST
    Figure CN122243030A_ABST
Patent Text Reader

Abstract

This application discloses a method, apparatus, device, and readable storage medium for managing organizational trees, relating to the fields of application integration and identity access management technology, to solve the problem of cumbersome and inefficient binding processes for organizational tags. The method includes: determining a target organizational tag and its corresponding inheritance strategy, wherein the inheritance strategy includes inheritance depth and inheritance range, the inheritance depth describing the number of levels through which the target organizational tag propagates in the organizational tree, and the inheritance range describing the scope of the target organizational tag's propagation in the organizational tree; binding a first node to the target organizational tag; determining a second node corresponding to the first node from the organizational tree based on the inheritance strategy; and binding the second node to the target organizational tag. Embodiments of this application can improve the efficiency of organizational tag binding.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of application integration and identity access management technology, specifically relating to a method, apparatus, device and readable storage medium for managing an organization tree. Background Technology

[0002] System platforms often use organizational trees to provide structured descriptions of users, departments, resources, or data entities, and classify and manage these entities through organizational tags, as well as implement corresponding security policies, access controls, or compliance rules.

[0003] In existing technologies, it is usually necessary to bind a corresponding organization label to each node individually. This static and manual binding method not only makes the configuration process cumbersome and the maintenance cost high, but also makes it easy for the label policy to become fragmented due to human error or inconsistent operation. Summary of the Invention

[0004] This application provides a method, apparatus, device, and readable storage medium for managing organizational trees, solving the problem that the binding process of organizational tags in the prior art is cumbersome and inefficient.

[0005] Firstly, a method for managing organizational trees is provided, including: Determine the target organization tag and the inheritance strategy corresponding to the target organization tag. The inheritance strategy includes inheritance depth and inheritance range. The inheritance depth is used to describe the number of levels through which the target organization tag propagates in the organization tree. The inheritance range is used to describe the range through which the target organization tag propagates in the organization tree. Bind the first node to the target organization tag, where the first node is any node in the organization tree; Based on the inheritance strategy, a second node corresponding to the first node is determined from the organization tree. The second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth. Bind the second node to the target organization tag.

[0006] Optionally, the inheritance strategy also includes modification permissions, which are used to indicate whether the second node is allowed to modify the target organization label.

[0007] Optionally, the inheritance strategy further includes a node type, which is used to limit the organizational role corresponding to the node that can inherit the target organizational tag.

[0008] Optionally, the scope of inheritance includes any one of the following: The first range is used to limit the propagation range of the target organization tag in the organization tree to only the currently bound node; The second scope is used to limit the target organization tag to propagate downwards from the currently bound node to all child nodes in the organization tree; The third range is used to limit the propagation of the target organization label along a preset path type; The fourth scope is used to limit the propagation of the target organization tag among child nodes sharing the same parent node; The fifth scope is used to limit the propagation of the target organization tag from the currently bound node to all parent nodes; The sixth scope is used to limit the propagation of the target tissue label throughout the tissue tree.

[0009] Optionally, the inheritance depth includes any one of the following: The first depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as N layers downwards, where N is a positive integer; The second depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as K levels upward, where K is a positive integer; The third depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as X layers downwards and Y layers upwards, where X and Y are both positive integers; The fourth depth is used to characterize the level at which the target organization tag propagates in the organization tree, which is only the currently bound node.

[0010] Optionally, the method further includes: Obtain the target tenant pattern; Based on the predefined correspondence between tenant patterns and business behaviors, determine the target business behavior corresponding to the target tenant pattern; The predefined correspondence between tenant patterns and business behaviors includes: The single-tenant mode corresponds to the first business behavior, which includes hiding the multi-tenant management interface and the tenant view. In the authentication logic, all requests belong to a single tenant by default, and the data access layer does not allow cross-tenant queries. The multi-tenant mode corresponds to the second business behavior, which enables tenant management and tenant self-service functions, allows for tenant-level configuration and data isolation, and reserves a platform-level cross-tenant statistical view.

[0011] Optionally, the method further includes: Get the value of the application visibility configuration; When the application visibility configuration value is used to represent the first mode, the application marketplace function is enabled, supporting multi-tenant browsing and ordering. When the application visibility configuration value is used to represent the second mode, only the internal application catalog is displayed, and the application marketplace is not enabled.

[0012] Secondly, embodiments of this application also provide a tissue tree management device, comprising: The first determining module is used to determine the target organization tag and the inheritance strategy corresponding to the target organization tag. The inheritance strategy includes inheritance depth and inheritance range. The inheritance depth is used to describe the number of levels through which the target organization tag propagates in the organization tree, and the inheritance range is used to describe the propagation range of the target organization tag in the organization tree. The first binding module is used to bind a first node to the target organization tag, wherein the first node is any node in the organization tree; The second determining module is used to determine a second node corresponding to the first node from the organization tree based on the inheritance strategy. The second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth. The second binding module is used to bind the second node to the target organization tag.

[0013] Secondly, embodiments of this application also provide an electronic device, including: a memory, a processor, and a program stored in the memory and executable on the processor; The processor is configured to read a program from memory to implement the steps in the organizational tree management method as described in the first aspect.

[0014] Secondly, embodiments of this application also provide a readable storage medium for storing a program that, when executed by a processor, implements the steps in the organizational tree management method as described in the first aspect.

[0015] In this embodiment, introducing the inheritance scope as a control dimension into the organization tag inheritance strategy can significantly improve the flexibility, accuracy, and security of tag strategy deployment. By defining the inheritance scope, the system can precisely specify which child nodes, parent nodes, or specific types of nodes should inherit the organization tag, and which should be excluded. This fine-grained control effectively avoids the overgeneralization of the tag strategy. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the organizational tree management method provided in an embodiment of this application; Figure 2This is a schematic diagram of the structure of the tissue tree management device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specified order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, not limited in number; for example, a first object can be one or more. Furthermore, in the specification and claims, "and" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0019] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), and other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used with the systems and radio technologies mentioned above, as well as with other systems and radio technologies. However, the following description describes New Radio (NR) systems for illustrative purposes, and NR terminology is used in most of the following description. These technologies can also be applied to applications beyond NR systems, such as 6th generation (6G) radio systems. th Generation 6G communication system.

[0020] The following description, in conjunction with the accompanying drawings, further illustrates the method, apparatus, device, and readable storage medium for managing the tissue tree proposed in the embodiments of the application. Please refer to... Figure 1 , Figure 1 A flowchart illustrating a method for managing an organizational tree, as provided in this application embodiment, is shown below. Figure 1 As shown, the method includes: Step 101: Determine the target organization tag and the inheritance strategy corresponding to the target organization tag. The inheritance strategy includes inheritance depth and inheritance range. The inheritance depth is used to describe the number of levels through which the target organization tag propagates in the organization tree, and the inheritance range is used to describe the propagation range of the target organization tag in the organization tree.

[0021] It should be understood that the entire organization tree begins with the root node, which is the unique top-level node and has no parent node. Multiple levels of child nodes can be sequentially expanded from the root node, forming a tree-like hierarchical structure. In the organization tree structure, the hierarchical relationship between nodes is usually defined by concepts such as parent node, child node, and grandchild node, and can be further refined into first-level child node, second-level child node, ..., Nth-level child node, or first-level parent node, second-level parent node, ..., Nth-level parent node, to precisely describe the depth position of a node in the tree.

[0022] Specifically, taking any node as the original node as an example, the direct subordinate nodes of the original node are called its corresponding direct children, that is, the first-level children of the original node. If these first-level children contain their own subordinate nodes, then these subordinate nodes are the second-level children, or grandchildren, relative to the original node, and so on. Starting from the original node, the node reached by descending N levels of the tree is the Nth-level child node of the original node.

[0023] For example, in an organizational tree of a company, the company headquarters can be considered the root node. Its various business units (such as marketing, R&D, and finance) are the first-level child nodes, or direct child nodes, of the root node. The specific subgroups within each business unit (such as the front-end development group and back-end development group under the R&D department) constitute the second-level child nodes, or grandchild nodes, of the root node. Further subdivisions within these subgroups constitute the Nth-level child nodes of the root node, where N is a positive integer greater than 2. This hierarchical relationship not only reflects management or logical subordination but also provides a clear structural foundation for data retrieval, access control, and system module division.

[0024] In an organizational tree structure, the hierarchical relationships between nodes include not only downward child relationships but also upward ancestor relationships. An ancestor node refers to all nodes traversed from a given original node, ascending through its parent nodes, including its direct parent node, the parent node's parent's parent (i.e., the grandparent node), and all parent nodes up to the root node.

[0025] Specifically, taking any node other than the root node as the original node, its direct parent node is called its corresponding direct parent node, or the first-level parent node of the original node. If these first-level parent nodes themselves contain parent nodes, then these parent nodes are the second-level parent nodes, or grandparent nodes, relative to the original node, and so on. Starting from the original node, the node reached by ascending the tree N levels is the Nth-level parent node of the original node.

[0026] For example, in an enterprise organizational structure tree, if a junior engineer is taken as the reference node, then his / her direct supervisor is his / her direct parent node, the department director is his / her grandparent node, and the company founder may be his / her Nth-level parent node. These are all the superior nodes of the junior engineer.

[0027] In some embodiments, determining the target organization tag and its corresponding inheritance strategy specifically includes: defining the target organization tag and its corresponding inheritance strategy. In other embodiments, determining the target organization tag and its corresponding inheritance strategy specifically includes: obtaining the target organization tag and its corresponding inheritance strategy from predefined organization tag data.

[0028] It should be understood that organizational tags are structured metadata used for semantic identification and policy binding of nodes in the organizational tree (such as departments, teams, geographic locations, business units, etc.). They not only carry classification information but also associate with a series of automatically executed processing policies, such as access control rules, encryption requirements, data retention periods, outbound restrictions, audit log levels, and watermarking policies. In practice, the specific content of organizational tags can be set and adjusted according to actual needs.

[0029] In practice, by binding organizational tags to nodes in the organizational tree, unified and consistent management and protection measures can be implemented for users, devices, documents, or data resources belonging to that node based on the organizational tag.

[0030] In this embodiment, the inheritance strategy includes inheritance depth and inheritance scope, which are described below. Inheritance depth is a key control parameter in the organization tag inheritance strategy, used to limit the number of levels through which the tag propagates in the organization tree. For example, when the inheritance depth is 0, it means the organization tag is not inherited, and its scope is limited to the current node. When the inheritance depth is 1, it means the organization tag is inherited only by child nodes, and its scope is the currently bound node and its direct child nodes. When the inheritance depth is 2, it means the organization tag is inherited only by child nodes and grandchild nodes, and its scope is the currently bound node and its child and grandchild nodes. When the inheritance depth is N, it means the organization tag can be inherited N levels, and its scope is the currently bound node and its N generations of descendants. When the inheritance depth is unlimited, it means the inheritance depth of the organization tag is unlimited, and its scope propagates to all levels of the entire subtree.

[0031] Optionally, in some embodiments, the inheritance depth includes any one of the following: The first depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as N layers downwards, where N is a positive integer; The second depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as K levels upward, where K is a positive integer; The third depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as X layers downwards and Y layers upwards, where X and Y are both positive integers; The fourth depth is used to characterize the level at which the target organization tag propagates in the organization tree, which is only the currently bound node.

[0032] When the inheritance depth is the first depth, the propagation direction of the target organization tag is downward. For example, if the target organization tag propagates two levels downward in the organization tree, the inheritance of the organization tag bound to the node only affects its direct child nodes (i.e., first-level child nodes) and grandchild nodes (i.e., second-level child nodes), and will not continue to be passed to great-grandchild nodes and deeper levels.

[0033] When the inheritance depth is the second depth, the propagation direction of the target organization tag is upward. For example, if the target organization tag propagates upward two levels in the organization tree, the inheritance of the organization tag bound to that node only affects its direct parent node (i.e., the first-level parent node) and grandparent node (i.e., the second-level parent node), and will not continue to be passed on to other ancestor nodes.

[0034] When the inheritance depth is the third depth, the target organization tag propagates both upwards and downwards simultaneously. For example, if the target organization tag propagates one level downwards and one level upwards in the organization tree, then the inheritance of the organization tag bound to that node only affects its direct parent and direct child nodes.

[0035] When the inheritance depth is the fourth depth, the target organization tag propagates in the organization tree only to the currently bound node, i.e., it is not inherited.

[0036] In this embodiment, inheritance depth is used to describe the number of levels through which a target organizational tag propagates in the organizational tree. Inheritance depth can control the level through which organizational tags are automatically passed from their bound nodes, thereby preventing the policy from spreading without limit or covering irrelevant units.

[0037] Inheritance scope is a key dimension in organizational tag inheritance strategies, used to control the propagation boundary of tags within the organizational tree. By flexibly configuring the inheritance scope, the propagation boundary of organizational tags can be precisely controlled, achieving full-scenario coverage from single-point marking to global configuration.

[0038] For example, the inheritance scope can be set to CURRENT_ONLY, indicating that the inheritance scope is limited to the current node, and the label only applies to the bound node itself, without propagating in any direction. The inheritance scope can be set to SUBTREE, indicating that the inheritance scope includes the current node and its subtrees, with the organization label propagating downwards from the bound node to all descendant nodes. The inheritance scope can be set to PATH, indicating that the inheritance scope is a path-wide scope, with the organization label propagating along a specific path type (e.g., administrative lines only). The inheritance scope can be set to SIBLINGS, indicating that the inheritance scope includes sibling nodes, with the organization label shared (horizontally) among the children of the same parent node. The inheritance scope can be set to ANCESTORS, indicating that the inheritance scope is upwards, with the organization label propagating upwards from the bound node to ancestor nodes. The inheritance scope can be set to TREE_WIDE, indicating that the inheritance scope is the entire organization tree, with the organization label globally effective throughout the entire organization tree.

[0039] Optionally, in some embodiments, the scope of inheritance includes any one of the following: The first range is used to limit the propagation range of the target organization tag in the organization tree to only the currently bound node; The second scope is used to limit the target organization tag to propagate downwards from the currently bound node to all child nodes in the organization tree; The third range is used to limit the propagation of the target organization label along a preset path type; The fourth scope is used to limit the propagation of the target organization tag among child nodes sharing the same parent node; The fifth scope is used to limit the propagation of the target organization tag from the currently bound node to all parent nodes; The sixth scope is used to limit the propagation of the target tissue label throughout the tissue tree.

[0040] Optionally, in some embodiments, the inheritance strategy further includes modification permissions, which are used to characterize whether the second node is allowed to modify the target organization tag.

[0041] In some embodiments, the modification operation refers to modifying the attributes of the target organization tag. In some embodiments, the attributes of the organization tag include at least one of the following: tag identifier, tag code, name, description, sensitivity level, retention period, access control rules, encryption policy, and scope of application.

[0042] In some embodiments, the value of the modification permission is used to indicate that the second node is not allowed to modify the target organization label. In this case, all second nodes that inherit the organization label can only use the predefined attributes of the target organization label and cannot change them without authorization, thus ensuring the consistency and compliance of the policy.

[0043] In other embodiments, the modification permission value indicates that a second node is allowed to modify the target organization label. The second node can then localize some or all attributes of the target organization label within its scope according to actual business needs. For example, a second node could temporarily elevate the "Internal" level to "Confidential" to meet specific project requirements without affecting the policy execution of other branches. This modification permission control mechanism based on inheritance strategy, while ensuring the uniformity of the overall governance framework, grants necessary autonomy to local units, effectively balancing the contradiction between centralized control and flexible adaptation, and significantly enhancing the adaptability and practicality of the organization label system in complex and dynamic business environments.

[0044] In this embodiment, the modification permission in the inheritance strategy indicates whether a node inheriting the target organization label is allowed to modify the target organization label, thereby improving the flexibility of the organization label inheritance strategy.

[0045] Optionally, in some embodiments, the inheritance strategy further includes a node type, which is used to define the organizational role corresponding to the node that can inherit the target organizational tag.

[0046] It should be understood that the organizational role corresponding to a node refers to the function or identity attribute that the node undertakes in the organizational structure, such as "R&D department", "financial center", "regional branch", "project team", "senior management team", etc. These roles reflect the specific positioning of the node in business processes, management authority or data processing activities.

[0047] In this embodiment, the inheritance strategy also includes node type. By setting the node type, it is possible to restrict only nodes corresponding to certain organizational roles to inherit the target organization tag, thereby achieving precise strategy distribution based on functional semantics.

[0048] For example, when a target organization label, such as a source code protection policy, is only applicable to technical units, the inheritance policy can restrict the inheritance to nodes of type R&D department or technical team. Even if other non-technical sub-nodes (such as marketing department or human resources department) are within the inheritance scope and depth, they will not inherit the target organization label.

[0049] In this embodiment, the misuse or redundant application of tag policies is effectively avoided by setting node types, which improves the targeting and security of governance, while reducing unnecessary policy conflicts and system overhead. This enables the organization's tag system to better fit the actual business logic and achieve refined, semantic-driven automated governance.

[0050] As a specific example, the predefined organization tag database includes the following organization tags: Organization Tag 1: Tag type is cost center, tag code is COST_CENTER, tag name is cost center tag, purpose is financial accounting and budget collection, inheritance strategy is full inheritance (FULL_INHERIT).

[0051] Organization Tag 2: The tag type is security level, the tag code is SEC_LEVEL, the tag name is information security level, the purpose is data access control and audit requirements, and the inheritance strategy is overriding inheritance (FULL_INHERIT_WITH_OVERRIDE).

[0052] Organization Tag 3: The tag type is project attribute, the tag code is PROJECT_ATTR, the tag name is project attribute tag, the purpose is project-based management and resource allocation, and the inheritance strategy is no inheritance (NO_INHERIT).

[0053] Organization Tag 4: Tag type is business line affiliation, tag code is BIZ_LINE, tag name is business line affiliation, purpose is business statistics and performance evaluation, inheritance strategy is role-based inheritance (ROLE_BASED_INHERIT). Organization Tag 5: The tag type is a geographic attribute, the tag code is REGION_ATTR, the tag name is a geographic attribute tag, the purpose is localization policy and data residency, and the inheritance strategy is path inheritance (PATH_INHERIT).

[0054] Tenant administrators can configure inheritance depth, inheritance scope, node type, and modification permissions for different organization tags to obtain inheritance policies. For example, `FULL_INHERIT` means that after an organization tag is bound to a parent node, all child nodes automatically inherit the same organization tag, and the child nodes cannot be modified. `FULL_INHERIT_WITH_OVERRIDE` means that child nodes inherit the parent node's organization tag by default, but allow redefining the organization tag value on specific child nodes. `NO_INHERIT` means that the organization tag is only bound to the current node and does not affect any child nodes. `ROLE_BASED_INHERIT` means that only child nodes with a specific organization role inherit the organization tag. `PATH_INHERIT` means that the organization tag is inherited along a specific path type, such as only along administrative lines and not across project lines.

[0055] Step 102: Bind the first node to the target organization tag. The first node is any node in the organization tree.

[0056] It should be understood that the first node is any node in the organization tree. After the target organization label and the inheritance strategy corresponding to the target organization label are determined, the first node is then bound to the organization label.

[0057] Step 103: Based on the inheritance strategy, determine the second node corresponding to the first node from the organization tree. The second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth.

[0058] As an optional implementation, firstly, nodes within the propagation range of the target organization tag in the organization tree are determined, and then nodes with a connection level to the first node that is less than or equal to the inheritance depth are selected from these nodes as second nodes.

[0059] As another alternative implementation, the tissue tree is first pruned based on the inheritance depth to obtain the corresponding subtrees, and the nodes in the subtrees that are within the propagation range of the target tissue tag in the tissue tree are determined as the second nodes.

[0060] As another alternative implementation, filtering conditions are constructed based on inheritance depth and inheritance strategy, and nodes in the organization tree are filtered and selected based on the filtering conditions to obtain the second node.

[0061] Optionally, in some embodiments, the inheritance strategy further includes a node type. Step 103 includes: determining a second node corresponding to the first node from the organization tree based on the inheritance strategy, wherein the second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth.

[0062] Step 104: Bind the second node to the target organization tag.

[0063] In some embodiments, the inheritance strategy includes modification permissions. After binding the second node to the target organization label, it is determined whether the second node can modify the target organization label it is bound to based on the modification permissions.

[0064] In this embodiment, introducing the inheritance scope as a control dimension into the organization tag inheritance strategy can significantly improve the flexibility, accuracy, and security of tag strategy deployment. Specifically, by defining the inheritance scope, the system can precisely specify which child nodes, parent nodes, or specific types of nodes should inherit the organization tag, and which should be excluded. This fine-grained control effectively avoids the overgeneralization of the tag strategy.

[0065] In practical implementation, the introduction of inheritance scope supports more complex business scenarios. For example, only "technical" departments can inherit the "source code protection" tag, while "marketing" departments are excluded, thus achieving differentiated governance based on functional attributes. Furthermore, in security-sensitive environments, the inheritance scope can be limited to "only directly subordinate child nodes" to prevent high-privilege tags from accidentally spreading to deeply untrusted units, reducing the risk of lateral privilege escalation. Simultaneously, inheritance scope simplifies policy management: administrators no longer need to cancel or override policies for each exception node; they only need to configure a reasonable inheritance policy on the parent node to achieve one-time definition and on-demand propagation. In summary, the addition of inheritance scope not only enhances the expressiveness and adaptability of the organizational tagging system but also improves the compliance, security, and maintainability of data governance, representing a key optimization for achieving intelligent, flexible, and scalable organizational-level policy management.

[0066] As a specific example, the data structure in the organization tree is defined as follows: An organization tree (Org_Tree) describes an independent organization tree within a single tenant, used to distinguish different types of organization trees such as administrative, project, and business line. As a specific implementation, Org_Tree includes at least one of the following fields: Organization Tree ID (Tree_ID), Tenant ID (Tenant_ID), Type (Type), Name (Name), and Status (Status). Multiple organization trees of different types (administrative, project, business line, etc.) can run concurrently within the same tenant space, distinguished by Org_Tree.Type.

[0067] A node (Org_Node) is used to describe a node in the organizational tree. As a specific example, an Org_Node has at least one of the following fields: Node ID, Tree ID, Tenant ID, Parent Node ID, Path, Level, Name, and Status. The fields in Org_Node can represent the organizational hierarchy and hierarchical relationships in the organizational tree.

[0068] Organizational labels (Org_Label) are used for label classification and inheritance control in the organizational tree. As a specific example, Org_Label includes at least one of the following fields: Label ID, Tenant ID, Code, Name, Description, and Inherit_Strategy.

[0069] The Org_Node_Label_Relation is used to describe the binding relationship between a node and an organization label. As a specific example, Org_Node_Label_Relation includes at least one of the following fields: Tenant_ID, Tree_ID, Node_ID, Label_ID, and Effective_Scope.

[0070] An organization role (Org_Role) describes the organization role within a tenant. As a specific example, Org_Role includes at least one of the following fields: Organization Role ID (Org_Role_ID), Tenant_ID, Name, Description, Status, etc., representing an organization-side role entity that can be mapped to organization nodes and application roles; User_Context_Role records the context role of a user under a specific tenant, organization tree, and organization node, allowing the same user to have different role sets in different organization contexts.

[0071] User Context Roles (User_Context_Role) are used to describe a user's context role relationship within a specific tenant, organization tree, and node. As a specific example, User_Context_Role includes at least one of the following fields: User ID, Tenant ID, Tree ID, Node ID, Role ID, Valid From / Valid To, and Status.

[0072] The above methods can accurately reflect multi-dimensional organizational relationships such as administration, projects, and business lines on the same platform. The organizational model is more in line with the actual management structure, reducing the difficulty of subsequent maintenance and minimizing permission errors caused by inaccurate organizational representation.

[0073] The following example, using a specific organizational tree, illustrates the implementation of the inheritance strategy. A specific organizational tree is shown in Table 1: Table 1. Example of a Tissue Tree

[0075] Create an organization label with Label_ID LBL_001, Tenant_ID TENANT_1, Code COST_CENTER, Name (Cost Center Label), and Inherit_Strategy FULL_INHERIT. Then bind this organization label to region A as the target organization label.

[0076] Taking region A as the first node, the corresponding second node is determined based on FULL_INHERIT. The specific tag binding results are shown in Table 2. Table 2 Organization Tag Binding Results

[0077] Optionally, in some embodiments, the method further includes: Obtain the target tenant pattern; Based on the predefined correspondence between tenant patterns and business behaviors, determine the target business behavior corresponding to the target tenant pattern; The predefined correspondence between tenant patterns and business behaviors includes: The single-tenant mode corresponds to the first business behavior, which includes hiding the multi-tenant management interface and the tenant view. In the authentication logic, all requests belong to a single tenant by default, and the data access layer does not allow cross-tenant queries. The multi-tenant mode corresponds to the second business behavior, which enables tenant management and tenant self-service functions, allows for tenant-level configuration and data isolation, and reserves a platform-level cross-tenant statistical view.

[0078] When the target tenant mode is single-tenant, the multi-tenant management interface and tenant view are hidden. In the authentication logic, all requests are assigned to a single tenant by default, and cross-tenant queries are not enabled in the data access layer. When the target tenant mode is multi-tenant, tenant management and tenant self-service functions are enabled, tenant-level configuration and data isolation are enabled, and a platform-level cross-tenant statistical view is reserved.

[0079] In this embodiment, by using a predefined correspondence between tenant modes and business behaviors, different functional business behaviors are implemented under different tenant modes, thereby improving the system's multi-tenant adaptability and business flexibility.

[0080] This pattern-driven business behavior configuration mechanism not only significantly reduces the operational complexity and delivery costs in multi-tenant environments, but also ensures that each tenant receives a differentiated experience tailored to their business context within a unified platform architecture. Simultaneously, this approach reduces the cost of business model switching to the configuration level, eliminating the need for large-scale data migration with downtime, and significantly mitigating technical and business interruption risks.

[0081] Optionally, in some embodiments, the method further includes: Get the value of the application visibility configuration; When the application visibility configuration value is used to represent the first mode, the application marketplace function is enabled, supporting multi-tenant browsing and ordering. When the application visibility configuration value is used to represent the second mode, only the internal application catalog is displayed, and the application marketplace is not enabled.

[0082] As a specific implementation, when the application visibility configuration value is 1, it is used to represent the first mode, and when the application visibility configuration value is 2, it is used to represent the second mode. By obtaining the value of the application visibility configuration, the current configuration status of application visibility can be determined.

[0083] In this embodiment, the system determines whether the application marketplace needs to be enabled by obtaining the value of the application visibility configuration. Through the above settings, the system can dynamically control the presentation and functional openness of the application marketplace according to preset strategies, thereby realizing an on-demand, secure, and controllable application distribution mechanism.

[0084] The following is an example of a specific implementation. After the system instance starts, the basic service module requests key configuration parameters for the current environment from the elastic configuration center, including but not limited to tenant mode (Tenant_Mode), application visibility configuration (App_Visibility), organization mode (Org_Mode), and switch parameters (Feature_Flag).

[0085] Specifically, a predefined `Tenant_Mode` value of `SINGLE` represents single-tenant mode, while a value of `MARKET` represents multi-tenant mode. A predefined `App_Visibility` value of `INTERNAL_ONLY` represents the first mode, where only internal applications are currently displayed, while a value of `App_Visibility` of `MARKET` represents the second mode, enabling the app marketplace function and supporting multi-tenant browsing and ordering.

[0086] Furthermore, in some embodiments, the predefined value of Org_Mode is SINGLE_TREE to represent a single organization tree mode, where each tenant supports only one organization tree; and the predefined value of Org_Mode is MULTI_TREE to represent a multi-organization tree mode, where each tenant supports multiple parallel organization trees. The predefined value of Feature_Flag is 1 to indicate that a specific interface is enabled, and a predefined value of Feature_Flag is 0 to indicate that a specific interface is disabled.

[0087] The Elastic Configuration Center returns a set of configuration items, which are stored in the local cache of the system. It also provides a unified configuration reading interface for each module. The system can subscribe to configuration change notifications to respond to mode switching during runtime.

[0088] In the specific implementation, the current target tenant mode (i.e., Tenant_Mode) is obtained. When Tenant_Mode is SINGLE, the system enters single-tenant mode, hiding the multi-tenant management interface and tenant view. In the authentication logic, all requests default to a single tenant, and the data access layer does not enable cross-tenant queries. When Tenant_Mode is MULTI, the system enters multi-tenant mode, enabling tenant management and tenant self-service functions, enabling tenant-level configuration and data isolation, and reserving a platform-level cross-tenant statistical view.

[0089] Retrieves the current application visibility configuration (App_Visibility). When App_Visibility is set to INTERNAL_ONLY, only the internal application directory is displayed, and the app store is disabled. When App_Visibility is set to MARKET, the app store feature is enabled, supporting multi-tenant browsing and subscription.

[0090] Get the value of the current switch parameter (Feature_Flag), and control whether to open advanced capabilities such as cross-tenant application programming interface (API) based on Feature_Flag. When it is turned off, the relevant interface is blocked in the routing and authentication layer. When it is turned on, some platform-level cross-tenant management capabilities are opened under strict permission control.

[0091] In this embodiment, after a user logs in, the frontend calls the backend runtime configuration interface to obtain configuration summaries such as Tenant_Mode, Org_Mode, App_Visibility, and Feature_Flag. Based on the configuration, the frontend dynamically generates or trims the menu tree and routing table. For example, in single-tenant mode, menus such as "Tenant Management" are hidden, while in application market mode, menus such as "Application Market" and "Tenant-level Application Subscription" are added. On specific pages, the frontend determines whether to display specific components or buttons, such as cross-tenant statistical report components and application subscription buttons, based on permissions and configuration summaries. When a configuration change is detected, the frontend re-obtains the configuration and refreshes the interface state to ensure consistency between the interface performance and the backend configuration.

[0092] In this embodiment, multi-tenant and multi-application support is reserved in the data model and architecture layers. Tenant fields are uniformly introduced for core resources, and tenant-level isolation is supported in the permission model. Key parameters such as Tenant_Mode, App_Visibility, Org_Mode, and Feature_Flag are centrally managed through the Elastic Configuration Center to determine whether the platform is in single-tenant or multi-tenant mode and application directory mode during system initialization and operation. By configuring the visibility of multi-tenant management interfaces, application marketplaces, cross-tenant APIs, and other capabilities, a smooth transition between single-tenant single-application and multi-tenant multi-application business models is achieved.

[0093] In this embodiment, a highly standardized and reusable new application access process is achieved through a unified application shelf, standardized ordering process, automatic instantiation mechanism, and unified mapping from organizational roles to application roles; the human input for application information configuration and permission activation is greatly reduced, the permission configuration error rate is controlled below 1%, and the process quality and stability are significantly improved.

[0094] It should be understood that, in some embodiments, the method provided in this application can also realize integrated governance of applications from application listing to permission linkage, including application metadata registration, tenant subscription and instantiation, organizational changes and permission linkage, etc.

[0095] Optionally, in some embodiments, the method further includes: During the application deployment phase, register application metadata and define a unified set of internal application roles; After a tenant's subscription is approved, an App_Instance_ID is automatically generated and strongly bound to Tenant_ID and App_ID to form an instance-level management unit. During the instance configuration phase, the tenant administrator establishes a mapping between the organization role Org_Role_ID and App_Role_ID within the tenant. During the runtime phase, based on organizational change events and role mapping relationships, user permissions under each App_Instance_ID are automatically updated.

[0096] Specifically, the application provider registers application metadata in the lifecycle manager, including App_ID, Name, Type, and the scope of subscribing tenants (Target_Tenant_Scope), and adds the application to the unified application shelf. Among them, Target_Tenant_Scope describes the scope of subscribing tenants of the current application, and its main function is to define the scope strategy of which tenants can access and subscribe to the application.

[0097] As a specific implementation, `Target_Tenant_Scope` with a value of `ALL_TENANTS` indicates that all tenants can subscribe to the application. `Target_Tenant_Scope` with a value of `WHITELIST` indicates a whitelist mode, where only whitelisted tenants can subscribe, for targeted invitations or beta testing. `Target_Tenant_Scope` with a value of `BLACKLIST` indicates a blacklist mode, excluding specific tenants. `Target_Tenant_Scope` with a value of `TENANT_TYPE` indicates differentiation by tenant type, such as group / provincial company / subsidiary. `Target_Tenant_Scope` with a value of `DOMAIN` indicates differentiation by domain, such as management domain, development domain, etc. `Target_Tenant_Scope` with a value of `NONE` indicates that subscription is not possible.

[0098] The application provider synchronously defines the set of internal roles (such as application administrator, business configuration engineer, ordinary user, etc.) and their corresponding permission templates. The lifecycle manager records fields such as App_Role_ID, App_Role_Code, App_Role_Name, and Permission_Template.

[0099] An application instance identifier (App_Instance_ID) is generated and bound to the Tenant_ID. The tenant administrator selects an application from the application shelf and initiates a subscription request; the system records the subscription parameters and approval process. Specifically, the App_Instance_ID primarily serves to isolate applications and provide fine-grained permission management in a multi-tenant environment. After subscription approval, the lifecycle manager generates a unique App_Instance_ID and strongly binds it to both the Tenant_ID and App_ID. If the application requires an independent running environment, the application instance is automatically deployed according to the template, and the relevant information is recorded in the instance configuration. Specifically, the tenant administrator maps the organizational role Org_Role_ID and App_Role_ID within the tenant during the instance configuration process, and the lifecycle manager records the mapping between Tenant_ID, App_Instance_ID, and Org_Role_ID and App_Role_ID in the role mapping table.

[0100] The organizational departments within the information system do not understand the internal roles of the application, and the application vendors do not understand the enterprise organizational structure. In order to solve this problem, the above binding relationship was established. Its main function is to build a bridge for permission conversion from the organizational perspective to the application perspective, realize differentiated permission policies for different tenants of the same application, support independent management of multiple instances of the same application of the same tenant, and realize instance-level precise linkage for organizational changes.

[0101] The organization engine monitors changes in a user's affiliation or context role in the organization tree. When a change occurs, it generates an organization change event (Event A), which includes information such as Tenant_ID, User_ID, Org_Tree_ID, change type, and role change details, and publishes it to the event bus.

[0102] The lifecycle manager and permission engine subscribe to Event A, query all valid App_Instance_IDs under that tenant based on Tenant_ID, and query the set of valid organizational roles of the user in the latest organizational context by combining User_Context_Role.

[0103] Based on the role mapping table, the set of organizational roles is converted into the set of target application roles under each App_Instance_ID. This is then compared with the current permission allocation to calculate the set of App_Role_IDs that need to be added or revoked.

[0104] For sets of roles that need to be added, write new records to the permission allocation table and call the application-side management API or refresh the centralized authentication cache; for sets of roles that need to be revoked, delete them from the permission allocation table or mark them as invalid, and notify the application side to revoke permissions.

[0105] In this embodiment, an event-driven, automated closed-loop linkage is formed between organizational changes and application permissions, avoiding manual maintenance of permissions system by system. Through this method, this application, via an event-driven organizational change and permission linkage mechanism, automatically updates the permissions of each application instance in near real-time after organizational adjustments. In typical scenarios, the total man-hours for organizational adjustment operations are significantly reduced, the error rate of the adjustment's impact range is significantly decreased, and data synchronization latency is controlled within 0.5 hours, greatly reducing permission mismatches and security risks.

[0106] Please see Figure 2 This application also provides a management device 200 for an organization tree. Figure 2 This is a structural diagram of the tissue tree management device 200 provided in this application embodiment. Because the principle of the tissue tree management device 200 in solving the problem is similar to that in the embodiment of this application... Figure 1 The method for managing the tissue tree shown is similar; therefore, the implementation of the tissue tree management device 200 can be found in the implementation of the method, and repeated details will not be described again. Figure 2 As shown, the tissue tree management device 200 includes: The first determining module 201 is used to determine a target organization tag and the inheritance strategy corresponding to the target organization tag. The inheritance strategy includes inheritance depth and inheritance range. The inheritance depth is used to describe the number of levels through which the target organization tag propagates in the organization tree, and the inheritance range is used to describe the propagation range of the target organization tag in the organization tree. The first binding module 202 is used to bind a first node to the target organization tag, wherein the first node is any node in the organization tree; The second determining module 203 is used to determine a second node corresponding to the first node from the organization tree based on the inheritance strategy. The second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth. The second binding module 204 is used to bind the second node to the target organization tag.

[0107] Optionally, the inheritance strategy also includes modification permissions, which are used to indicate whether the second node is allowed to modify the target organization label.

[0108] Optionally, the inheritance strategy further includes a node type, which is used to limit the organizational role corresponding to the node that can inherit the target organizational tag.

[0109] Optionally, the scope of inheritance includes any one of the following: The first range is used to limit the propagation range of the target organization tag in the organization tree to only the currently bound node; The second scope is used to limit the target organization tag to propagate downwards from the currently bound node to all child nodes in the organization tree; The third range is used to limit the propagation of the target organization label along a preset path type; The fourth scope is used to limit the propagation of the target organization tag among child nodes sharing the same parent node; The fifth scope is used to limit the propagation of the target organization tag from the currently bound node to all parent nodes; The sixth scope is used to limit the propagation of the target tissue label throughout the tissue tree.

[0110] Optionally, the inheritance depth includes any one of the following: The first depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as N layers downwards, where N is a positive integer; The second depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as K levels upward, where K is a positive integer; The third depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as X layers downwards and Y layers upwards, where X and Y are both positive integers; The fourth depth is used to characterize the level at which the target organization tag propagates in the organization tree, which is only the currently bound node.

[0111] Optionally, the tissue tree management device 200 further includes: The first acquisition module is used to acquire the target tenant mode; The third determining module is used to determine the target business behavior corresponding to the target tenant mode based on the predefined correspondence between tenant modes and business behaviors. The predefined correspondence between tenant patterns and business behaviors includes: The single-tenant mode corresponds to the first business behavior, which includes hiding the multi-tenant management interface and the tenant view. In the authentication logic, all requests belong to a single tenant by default, and the data access layer does not allow cross-tenant queries. The multi-tenant mode corresponds to the second business behavior, which enables tenant management and tenant self-service functions, allows for tenant-level configuration and data isolation, and reserves a platform-level cross-tenant statistical view.

[0112] Optionally, the tissue tree management device 200 further includes: The second acquisition module is used to acquire the value of the application visibility configuration; The processing module is configured to enable the application marketplace function and support multi-tenant browsing and ordering when the application visibility configuration value is used to represent the first mode, and to only display the internal application catalog and not enable the application marketplace when the application visibility configuration value is used to represent the second mode.

[0113] The tissue tree management device 200 provided in this application embodiment can perform... Figure 1 The implementation principle and technical effect of the organization tree management method shown in this embodiment are similar, and will not be described again here.

[0114] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically included separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0116] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the transmission and reception methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0117] like Figure 3 As shown in the figure, this application embodiment also provides an electronic device 300, which includes: a processor 301, configured to read a program from a memory 302 and execute the following steps: Determine the target organization tag and the inheritance strategy corresponding to the target organization tag. The inheritance strategy includes inheritance depth and inheritance range. The inheritance depth is used to describe the number of levels through which the target organization tag propagates in the organization tree. The inheritance range is used to describe the range through which the target organization tag propagates in the organization tree. Bind the first node to the target organization tag, where the first node is any node in the organization tree; Based on the inheritance strategy, a second node corresponding to the first node is determined from the organization tree. The second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth. Bind the second node to the target organization tag.

[0118] Optionally, the inheritance strategy also includes modification permissions, which are used to indicate whether the second node is allowed to modify the target organization label.

[0119] Optionally, the inheritance strategy further includes a node type, which is used to limit the organizational role corresponding to the node that can inherit the target organizational tag.

[0120] Optionally, the scope of inheritance includes any one of the following: The first range is used to limit the propagation range of the target organization tag in the organization tree to only the currently bound node; The second scope is used to limit the target organization tag to propagate downwards from the currently bound node to all child nodes in the organization tree; The third range is used to limit the propagation of the target organization label along a preset path type; The fourth scope is used to limit the propagation of the target organization tag among child nodes sharing the same parent node; The fifth scope is used to limit the propagation of the target organization tag from the currently bound node to all parent nodes; The sixth scope is used to limit the propagation of the target tissue label throughout the tissue tree.

[0121] Optionally, the inheritance depth includes any one of the following: The first depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as N layers downwards, where N is a positive integer; The second depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as K levels upward, where K is a positive integer; The third depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as X layers downwards and Y layers upwards, where X and Y are both positive integers; The fourth depth is used to characterize the level at which the target organization tag propagates in the organization tree, which is only the currently bound node.

[0122] Optionally, the processor 301 is further configured to read the program in the memory 302 and perform the following steps: Obtain the target tenant pattern; Based on the predefined correspondence between tenant patterns and business behaviors, determine the target business behavior corresponding to the target tenant pattern; The predefined correspondence between tenant patterns and business behaviors includes: The single-tenant mode corresponds to the first business behavior, which includes hiding the multi-tenant management interface and the tenant view. In the authentication logic, all requests belong to a single tenant by default, and the data access layer does not allow cross-tenant queries. The multi-tenant mode corresponds to the second business behavior, which enables tenant management and tenant self-service functions, allows for tenant-level configuration and data isolation, and reserves a platform-level cross-tenant statistical view.

[0123] Optionally, the processor 301 is further configured to read the program in the memory 302 and perform the following steps: Get the value of the application visibility configuration; When the application visibility configuration value is used to represent the first mode, the application marketplace function is enabled, supporting multi-tenant browsing and ordering. When the application visibility configuration value is used to represent the second mode, only the internal application catalog is displayed, and the application marketplace is not enabled.

[0124] The electronic device 600 provided in this application embodiment can perform... Figure 1 The implementation principle and technical effect of the organization tree management method shown in this embodiment are similar, and will not be described again here.

[0125] This application also provides a readable storage medium storing a program. When the program is executed by a processor, it implements the various processes of the above-described organizational tree management method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0126] The readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic storage (such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (such as compact disks (CD), digital video discs (DVD), Blu-ray discs (BD), high-definition universal discs (HVD), etc.), and semiconductor storage (such as read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), non-volatile memory (NAND FLASH), solid-state disks (SSD), etc.).

[0127] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0129] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for managing organizational trees, characterized in that, include: Determine the target organization tag and the inheritance strategy corresponding to the target organization tag. The inheritance strategy includes inheritance depth and inheritance range. The inheritance depth is used to describe the number of levels through which the target organization tag propagates in the organization tree. The inheritance range is used to describe the range through which the target organization tag propagates in the organization tree. Bind the first node to the target organization tag, where the first node is any node in the organization tree; Based on the inheritance strategy, a second node corresponding to the first node is determined from the organization tree. The second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth. Bind the second node to the target organization tag.

2. The method according to claim 1, characterized in that, The inheritance strategy also includes modification permissions, which are used to indicate whether the second node is allowed to modify the target organization label.

3. The method according to claim 1, characterized in that, The inheritance strategy also includes node types, which are used to limit the organizational roles corresponding to nodes that can inherit the target organization tag.

4. The method according to claim 1, characterized in that, The scope of inheritance includes any one of the following: The first range is used to limit the propagation range of the target organization tag in the organization tree to only the currently bound node; The second scope is used to limit the target organization tag to propagate downwards from the currently bound node to all child nodes in the organization tree; The third range is used to limit the propagation of the target organization label along a preset path type; The fourth scope is used to limit the propagation of the target organization tag among child nodes sharing the same parent node; The fifth scope is used to limit the propagation of the target organization tag from the currently bound node to all parent nodes; The sixth scope is used to limit the propagation of the target tissue label throughout the tissue tree.

5. The method according to claim 1, characterized in that, The inheritance depth includes any one of the following: The first depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as N layers downwards, where N is a positive integer; The second depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as K levels upward, where K is a positive integer; The third depth is used to characterize the level at which the target tissue tag propagates in the tissue tree as X layers downwards and Y layers upwards, where X and Y are both positive integers; The fourth depth is used to characterize the level at which the target organization tag propagates in the organization tree, which is only the currently bound node.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the target tenant pattern; Based on the predefined correspondence between tenant patterns and business behaviors, determine the target business behavior corresponding to the target tenant pattern; The predefined correspondence between tenant patterns and business behaviors includes: The single-tenant mode corresponds to the first business behavior, which includes hiding the multi-tenant management interface and the tenant view. In the authentication logic, all requests belong to a single tenant by default, and the data access layer does not allow cross-tenant queries. The multi-tenant mode corresponds to the second business behavior, which enables tenant management and tenant self-service functions, allows for tenant-level configuration and data isolation, and reserves a platform-level cross-tenant statistical view.

7. The method according to claim 1, characterized in that, The method further includes: Get the value of the application visibility configuration; When the application visibility configuration value is used to represent the first mode, the application marketplace function is enabled, supporting multi-tenant browsing and ordering. When the application visibility configuration value is used to represent the second mode, only the internal application catalog is displayed, and the application marketplace is not enabled.

8. A management device for a tissue tree, characterized in that, include: The first determining module is used to determine the target organization tag and the inheritance strategy corresponding to the target organization tag. The inheritance strategy includes inheritance depth and inheritance range. The inheritance depth is used to describe the number of levels through which the target organization tag propagates in the organization tree, and the inheritance range is used to describe the propagation range of the target organization tag in the organization tree. The first binding module is used to bind a first node to the target organization tag, wherein the first node is any node in the organization tree; The second determining module is used to determine a second node corresponding to the first node from the organization tree based on the inheritance strategy. The second node is located within the propagation range of the target organization tag in the organization tree, and the connection level between the second node and the first node is less than or equal to the inheritance depth. The second binding module is used to bind the second node to the target organization tag.

9. An electronic device, comprising: A memory, a processor, and a program stored in the memory and executable on the processor; characterized in that, The processor is configured to read a program from memory to implement the steps in the method for managing an organization tree as described in any one of claims 1 to 7.

10. A readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps in the method for managing an organizational tree as described in any one of claims 1 to 7.