A document permission management method and device and a storage medium

Abstract

The application discloses a kind of document authority management method, device and storage medium, comprising: in response to the access request of first user to target document, the team attribution information and role information of first user are acquired;According to team attribution information, the target team to which the first user belongs is determined, and the team authority configuration information of target team is acquired;According to role information, the role authority set corresponding to first user is determined from the team authority configuration information;The document authority label of target document is acquired, and the document authority label includes visible team list and operation authority matrix;According to the role authority set of first user and document authority label, the access authority of first user to target document is determined, and the application is matched by three levels decoupling and dynamic matching of team dimension, role dimension and document dimension, realizes fine-grained document authority management, solves the technical problems of complex authority configuration, authority spread and authority island in multi-team collaboration scenario.

Description

Technical Field

[0001] This invention relates to the field of document permission management technology, specifically to a document permission management method, apparatus, and storage medium. Background Technology

[0002] As enterprises deepen their digital transformation, team collaboration software and document management systems have become core infrastructure for daily operations. In complex organizational structures with multiple teams and roles, efficiently and securely managing document access permissions has become a key technical challenge for document management systems.

[0003] Currently, mainstream document permission management solutions are mainly based on the traditional RBAC (Role-Based Access Control) model or its variants. For example, CN117574397A discloses a resource-based user permission management method and system. This method authorizes files through user or role management, forming a data exchange format string that grants specific permissions to users or roles for a particular operation on a specific resource. Furthermore, by combining user permissions and role permissions, a union of permissions is taken. If conflicts arise, the priority of permissions is prioritized, with user permissions taking precedence over role permissions. This method decouples users and permissions through the role as an intermediate layer, simplifying permission management to some extent.

[0004] However, existing technical solutions have the following significant shortcomings when applied to multi-team collaboration scenarios: First, the complexity of permission configuration is high. In scenarios involving multiple teams accessing and managing the same batch of documents, existing solutions typically require configuring different permission sets for each team at the role level, leading to a rapid increase in the number of roles—the role explosion problem. For example, an organization with 10 teams, each with 5 roles, theoretically needs to create 50 different role entities, resulting in an exponential increase in configuration workload.

[0005] Second, the coexistence of permission spread and permission silos. Existing solutions lack effective team isolation mechanisms. On the one hand, when users switch between different teams, their permissions often cannot be automatically adapted, which can easily lead to unauthorized access, i.e., permission spread security risks. On the other hand, when users need to collaborate across teams, the rigid permission configuration creates permission silos, making it impossible to flexibly grant temporary access permissions.

[0006] Third, document-level permission control is coarse-grained. Most existing solutions remain at a binary control level of overall document visibility / invisibility, lacking fine-grained permission differentiation for different operations within the same document, such as viewing, editing, deleting, sharing, and exporting, making it difficult to meet the actual needs of enterprises for document security management.

[0007] Fourth, the permission configuration for new users joining the team is lagging behind. When a new member joins the team, the current solution requires the administrator to manually assign roles and permissions to them, which takes a long time and is prone to errors in permission configuration due to human negligence. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a document permission management method, device and storage medium, which aims to solve the technical problems of complex document permission configuration and low permission management efficiency in multi-team collaboration scenarios.

[0009] To achieve the above objectives, firstly, this application provides the following technical solution: A document permission management method, comprising: In response to the first user's access request to the target document, obtain the first user's team affiliation information and role information; The target team to which the first user belongs is determined based on the team affiliation information, and the team permission configuration information of the target team is obtained. The set of role permissions corresponding to the first user is determined from the team permission configuration information based on the role information; Obtaining the document permission tag of the target document, the document permission tag including a list of visible teams and an operation permission matrix; the document permission tag also includes the team identifier to which the document belongs; the step of matching the first user's role permission set with the document permission tag to determine the first user's access permissions to the target document includes: Determine whether the target team belongs to the list of visible teams; If the target team is not in the list of visible teams, then it is determined that the first user has no access rights to the target document; If the target team belongs to the list of visible teams, then the first user's at least one operation permission for the target document is determined by matching the role permission set with the operation permission matrix item by item.

[0010] The access permissions of the first user to the target document are determined by matching the first user's role permission set with the document permission tags.

[0011] Further, the step of determining at least one operation permission of the first user on the target document by matching the role permission set with the operation permission matrix item by item includes: Iterate through each permission item in the operation permission matrix; For each permission item, determine whether there is a permission identifier in the role permission set that matches the permission item; If a match is found, the first user is granted the operation permission corresponding to that permission item; If no match is found, the operation permission corresponding to that permission item for the first user is denied.

[0012] Furthermore, the team permission configuration information is generated in the following way: In response to a team administrator's role creation action, obtain the role name and at least one menu permission assigned to that role; Associate the character name with the at least one menu permission and store it to generate a character entity; In response to a team administrator's member addition operation, retrieve the member's identifier and the target role assigned to that member; The member identifier is associated with the target role and stored to generate a member-role mapping relationship.

[0013] Furthermore, the method also includes: In response to the team administrator's edit operation on the target role, obtain the updated role permission configuration; Update the set of role permissions corresponding to the target role according to the updated role permission configuration; Based on the member-role mapping relationship, the updated set of role permissions will be synchronously applied to all members bound to the target role.

[0014] Furthermore, the method also includes: In response to the second user's team switching operation, obtain the target team selected by the second user for switching; Switch the second user's current team context to the target switching team; Refresh the second user's role permission set to the role permission set corresponding to the target switching team; The updated interface displays relevant data from the target switching team.

[0015] Furthermore, the method also includes: In response to a team administrator's invitation to an unregistered user, an invitation link containing team association information is generated. In response to the unregistered user completing registration through the invitation link, the unregistered user is automatically associated with the target team, and role permissions are assigned to the unregistered user according to the preset role information in the invitation operation.

[0016] Furthermore, obtaining the team affiliation information and role information of the first user includes: Parse the user identifier from the login token of the first user; Query the user-team mapping table based on the user identifier to obtain all team identifiers associated with the first user and the currently selected team identifier; The member-role mapping table is queried based on the user identifier and the currently selected team identifier to obtain the role identifier of the first user in the target team.

[0017] Secondly, the present invention also provides a document permission management device, comprising: One or more processors; and Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the document permission management method.

[0018] Thirdly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the document permission management method described above.

[0019] The core of this invention lies in constructing a three-level decoupled permission management architecture of team-role-document, which expands the traditional two-dimensional user-role-permission model into a four-dimensional matching model of user-team-role-document permission tags.

[0020] Specifically, this invention divides permission management into three independent configuration dimensions: Team Dimension: Each team independently maintains its own role system and member relationships, and teams are isolated from each other at the permission configuration level. This design solves the role explosion problem, that is, the same role name, such as "administrator", can have completely different permission configurations in different teams, without the need to create different role entities for each team.

[0021] Role Dimension: Roles serve as permission templates within a team, defining the set of basic permissions that a particular type of member possesses within that team. Roles are bound to teams, and the permission configurations for a role only take effect within that team.

[0022] Document Dimension: Each document carries an independent permission tag, which includes a "visible team list" (i.e., which team members can see the document) and an "operation permission matrix" (i.e., the specific operations that different roles can perform on the document). Document permission tags are configured independently of teams and roles, enabling fine-grained management of document-level permissions.

[0023] When a user requests access to a document, the system performs permission determination according to a three-level matching process: team filtering → role matching → permission tag verification. Level 1 team filtering: Determines whether the user's team is in the document's visible team list; if not, access is denied directly, achieving team-level security isolation. Second-level role matching: After passing the team filter, obtain the user's set of role permissions in that team; Level 3 permission tag verification: Match the user's role permission set with the document's operation permission matrix item by item to determine the user's specific operation permissions for the document.

[0024] The three-level matching mechanism reduces the time complexity of permission determination from O(n×m), whereas in the traditional solution n is the number of users and m is the number of documents. It optimizes this to a constant-level matching of O(1), which significantly improves the efficiency of permission determination in large-scale team collaboration scenarios.

[0025] Compared with the prior art, the present invention has the following beneficial effects: 1. Significantly reduces the complexity of permission configuration. By introducing a team dimension and binding roles to teams, the same role name can be reused in different teams with different permission meanings, effectively avoiding the role explosion problem. Testing showed that in a scenario with 10 teams and 5 roles per team, the number of roles required by this invention is 10, with one role system per team, while the traditional solution requires 50 role entities, reducing configuration workload by approximately 80%.

[0026] 2. Achieve team-level permission isolation and flexible switching. Through the "visible team list" mechanism, selective visibility of documents across different teams is achieved. This prevents permission creep, meaning users can only see documents visible to their own team, while the team switching function allows users to flexibly jump between different teams, with permissions automatically adapting to the team context.

[0027] 3. Achieve fine-grained document-level access control. Through the "operation permission matrix" mechanism, document permissions are expanded from the traditional binary "visible / invisible" control to independent control over multiple operations such as viewing, editing, deleting, sharing, and exporting, meeting the enterprise's refined needs for document security management.

[0028] 4. Enable automatic permission binding for new users. Through an invitation link mechanism and preset role configurations, new users can be automatically associated with a team and granted the corresponding role permissions after registration, eliminating the need for manual configuration by administrators and significantly improving the efficiency of team expansion. Attached Figure Description

[0029] Figure 1 A flowchart illustrating the overall process of the document permission management method provided in this embodiment of the invention; Figure 2 A flowchart illustrating the method for generating team permission configuration information provided in this embodiment of the invention; Figure 3 A flowchart of a document permission tag matching and determination method provided in an embodiment of the present invention; Figure 4 A flowchart of a team switching method provided in an embodiment of the present invention; Detailed Implementation

[0030] The technical solution of this application is described below with reference to the accompanying drawings. The described embodiments are only a part of the embodiments of this application, and not all of them.

[0031] Example 1: This example provides a complete implementation process for a document permission management method, such as... Figure 1 As shown, the method includes the following steps: Step S101: In response to the first user's access request to the target document, obtain the first user's team affiliation information and role information.

[0032] In this embodiment, the first user sends an access request for the target document to the document permission management server through a client such as a WeChat mini-program, web application, or mobile app. The access request carries the user's login token.

[0033] After receiving an access request, the server first parses the user identifier (UserID) from the login token. Specifically, the login token adopts the JWT (JSON Web Token) format. After verifying the token's signature, the server extracts the user identifier from the token's payload.

[0034] Then, the server queries the User-Team Mapping Table based on the user identifier to obtain a list of all team identifiers associated with the user and the currently selected team identifier. The User-Team Mapping Table is stored in a relational database (such as MySQL), and its data structure is shown in Table 1 below: Table 1

[0035] The server determines the target team based on the currently selected team identifier, and further queries the Member-Role Mapping Table based on the user identifier and the target team identifier to obtain the user's role identifier (RoleID) within the target team. The data structure of the Member-Role Mapping Table is shown in Table 2 below: Table 2

[0036] Step S102: Determine the target team to which the first user belongs based on the team affiliation information, and obtain the team permission configuration information of the target team.

[0037] The server queries the Team Permission Config Table based on the target team identifier (TeamID) determined in step S101 to obtain the complete permission configuration information for that team. The team permission configuration information includes the definitions of all roles within that team and their corresponding permission sets.

[0038] The data structure of the team permission configuration table is shown in Table 3 below: Table 3

[0039] The permissions field stores all menu permission identifiers possessed by the role in JSON array format, for example: ["menu_dashboard", "menu_document_view", "menu_document_edit"].

[0040] Step S103: Determine the set of role permissions corresponding to the first user from the team permission configuration information based on the role information.

[0041] Based on the role identifier (RoleID) obtained in step S101, the server extracts the permission set corresponding to the role from the team permission configuration information obtained in step S102, and uses it as the first user's role permission set (RolePermission Set) in the target team.

[0042] Step S104: Obtain the document permission tag of the target document.

[0043] The server queries the DocumentPermission Tag Table based on the target document's document identifier (DocID) to obtain the document's permission tags. These permission tags include a Visible Team List and an Operation Permission Matrix.

[0044] The data structure of the document permission tag table is shown in Table 4 below: Table 4

[0045] The `visible_teams` field stores a list of team IDs that are allowed to access the document, for example: ["team_001", "team_002", "team_003"], the perm_matrix field stores the operation permission matrix, whose data structure is a mapping from roles to operation permissions, for example: { "role_admin": ["view", "edit", "delete", "share", "export"], "role_editor": ["view", "edit", "share"], "role_viewer": ["view"] } Step S105: Match the first user's role permission set with the document permission tag to determine the first user's access permissions to the target document.

[0046] This step employs a three-level matching process, specifically including: First-level matching team filtering: The server determines whether the target team belongs to the document's visible team list. Specifically, it iterates through the `visible_teams` array and checks if the target team's TeamID exists in it. If it does not exist, it is determined that the first user has no access rights to the target document, and a "no access" response is returned, ending the process.

[0047] The second level of matching involves role-based matching: If the target team is in the visible team list, the server further obtains the first user's set of role permissions within the target team. If the first user has not yet been assigned a role in the target team (i.e., the role identifier is empty), it is determined that the first user has no access rights to the target document.

[0048] The third level of permission tag verification: If the first user has been assigned a role, the server searches for the list of operation permissions corresponding to that role in the operation permission matrix (perm_matrix) based on the role's role identifier. Then, the intersection operation is performed between the found list of operation permissions and the user's role permission set to determine the actual operation permissions the user possesses.

[0049] Specifically, for each permission item defined in the operation permission matrix, such as "view", "edit", "delete", etc., the server checks one by one whether the permission item also exists in the user's role permission set. If it exists, the user is granted the operation permission; if it does not exist, the operation permission is denied.

[0050] Finally, the server returns the matching results, which is a list of the specific operation permissions that the user has for the target document, to the client. The client then uses this result to control the display of the document interface and the availability of operation buttons.

[0051] Using CN117574397A as Comparative Example 1, this embodiment is compared and verified with Comparative Example 1: To verify the technical effectiveness of this invention, the method of this embodiment is compared with Comparative Example 1 of an existing RBAC-based document permission management scheme based on CN117574397A. The test environment is as follows: 10 parallel teams, each with 50 members, each team configured with 5 roles, and a total of 1000 documents requiring permission management. The verification results are shown in Table 5 below: Table 5

[0052] Test results show that the present invention is significantly superior to existing solutions in terms of permission configuration efficiency, permission determination performance, permission security, and team expansion efficiency.

[0053] Example 2: This example provides a method for generating and dynamically updating team permission configuration information.

[0054] like Figure 2 As shown, the generation of team permission configuration information includes the following steps: Step S201: In response to the team administrator's role creation operation, obtain the role name and at least one menu permission assigned to the role.

[0055] When a team administrator accesses the role management interface through a client (e.g.) Figure 4 As shown in the image, after clicking the "Add Role" button, a role creation dialog box will pop up on the client. The administrator enters the role name, such as "Document Auditor," in the dialog box, and selects the menu permissions that the role has, such as "Document View," "Document Audit," and "Document Annotation."

[0056] The client encapsulates the role name and the selected menu permission list into a role creation request and sends it to the server.

[0057] Step S202: Associate the role name with the at least one menu permission and store it to generate a role entity.

[0058] After receiving a role creation request, the server first checks whether a role with the same name already exists under the team. If it does, an error message is returned. If no duplicate exists, the server generates a unique role identifier (RoleID) and stores the team identifier (TeamID), role identifier, role name, and permission list in the team permission configuration table (Team PermissionConfig Table), thus completing the creation of the role entity.

[0059] Step S203: In response to the team administrator's member addition operation, obtain the member identifier and the target role assigned to the member.

[0060] When a team administrator accesses the team management interface through the client and clicks the "Add Member" button, a member addition dialog box pops up in the client. The administrator enters the member's name and mobile phone number, and selects the role to assign to that member from the drop-down list.

[0061] For registered users, administrators can use the "Invite to Join" function to grant farm permissions by selecting the farm management option in the dialog box, choosing the role, and then sending an invitation link.

[0062] Step S204: Associate the member identifier with the target role and store the association to generate a member-role mapping relationship.

[0063] After receiving a member addition request, the server verifies whether the target role exists in the team's permission configuration. If it exists, the server associates and stores the user identifier, team identifier, and role identifier in the Member-RoleMapping Table, thus completing the binding between the member and the role.

[0064] This embodiment also includes a dynamic update mechanism for role permissions: When a team administrator needs to modify the permissions of an existing role, they can modify the role name or check / uncheck menu permissions through the role editing interface. After clicking save, the client will send the updated role configuration to the server.

[0065] After receiving the role update request, the server performs the following operations: Update the role name and permission set for that role in the team permission configuration table based on the role identifier (RoleID); Query the member-role mapping table to get a list of all members bound to this role; For each member in the list, update their role permission set in the current team context to the modified permission set; If the member is currently online, a permission update notification is pushed via WebSocket, causing the client to refresh the interface in real time.

[0066] This mechanism allows changes to role permissions to be instantly synchronized to all members bound to that role, eliminating the need for individual configuration for each member and significantly improving the efficiency of permission management.

[0067] Furthermore, when a team administrator needs to delete a role, the server first queries the member-role mapping table to check if a member is already bound to that role. If a bound member exists, the deletion operation is rejected and a message is returned stating "This role has associated users and cannot be deleted"; if no bound member exists, the role record is deleted from the team permission configuration table.

[0068] Example 3: This example provides a method for matching and determining document permission tags and a method for switching teams.

[0069] (I) Detailed process of document permission tag matching and determination like Figure 3 As shown, the document permission tag matching determination includes the following steps: Step S301: Obtain the document permission tag of the target document.

[0070] The server queries the document permission tag table based on the document identifier to obtain the list of visible teams (visible_teams) and the operation permission matrix (perm_matrix) for that document.

[0071] Step S302: Determine whether the target team belongs to the visible team list.

[0072] The server iterates through the visible_teams array and checks if the target team's TeamID exists in it. If it does not exist, proceed to step S303; if it does exist, proceed to step S304.

[0073] Step S303: Determine if there is no access permission.

[0074] The server returns a "no access" response to the client, and the process ends.

[0075] Step S304: Obtain the user's set of role permissions.

[0076] The server retrieves the user's role identifier from the member-role mapping table based on the user identifier and the target team identifier, and then retrieves the set of permissions corresponding to that role from the team permission configuration table.

[0077] Step S305: Determine whether the user has been assigned a role.

[0078] If the user's role identifier is empty or the role permission set is empty, proceed to step S303; otherwise, proceed to step S306.

[0079] Step S306: Traverse each permission item in the operation permission matrix.

[0080] The server retrieves a list of all permission items defined in the operation permission matrix, such as ["view", "edit", "delete", "share", "export"], and performs matching and judgment on each one.

[0081] Step S307: Determine whether a matching permission identifier exists in the role permission set.

[0082] For the currently encountered permission item, the server determines whether the permission item exists in the user's role permission set. If it exists, proceed to step S308; otherwise, proceed to step S309.

[0083] Step S308: Grant the operation permission corresponding to the permission item.

[0084] The server adds this permission to the user's list of authorized actions for that document.

[0085] Step S309: Deny the operation permission corresponding to this permission item.

[0086] The server does not add this permission item to the list of authorized operations.

[0087] Step S310: Return the matching results.

[0088] After the server has completed iterating through all permission items, it encapsulates the list of authorized operations into a response and returns it to the client. The client then uses this response to control the display and interaction of UI elements.

[0089] (II) Team Switching Methods like Figure 4 As shown, the team switching method includes the following steps: Step S401: In response to the second user's team switching operation, obtain the target switching team selected by the second user.

[0090] When a user clicks the "Switch Team" button through the client and selects the target team in the drawer-style pop-up window, the client encapsulates the user's identifier and the selected target team's identifier into a team switching request and sends it to the server.

[0091] Step S402: Switch the current team context of the second user to the target switching team.

[0092] After receiving a team switch request, the server updates the user's currently selected team identifier (is_current field) in the user-team mapping table and sets the target team identifier to the current team.

[0093] Step S403: Refresh the second user's role permission set to the role permission set corresponding to the target switching team.

[0094] Step S404: Update the data displayed on the interface to the relevant data within the target switching team.

[0095] The server returns the changed set of role permissions and relevant data for the team, such as document lists and member lists, to the client, which then refreshes the interface to display them.

[0096] Through the team switching mechanism described above, users can flexibly switch between different teams. After each switch, the permissions are automatically adapted to the new team's configuration, which not only ensures the flexibility of multi-team collaboration, but also ensures permission security through team isolation.

[0097] This embodiment is compared and verified with the prior art: To further verify the technical effectiveness of the present invention in team switching scenarios, the team switching mechanism of this embodiment was compared with existing solutions, and the results are shown in Table 6 below: Table 6

[0098] Test results show that the present invention is significantly superior to existing solutions in terms of ease of team switching, accuracy of permissions, and scalability.

[0099] The document permission management method, apparatus, and storage medium provided by this invention can be widely applied to various scenarios requiring multi-team document collaboration, including but not limited to: enterprise document management systems, document management applications on team collaboration software platforms such as WeChat Work, DingTalk, and Lark, document modules of project management systems, and document permission management functions of various SaaS (Software as a Service) platforms. The method of this invention can be implemented through software programs and deployed on existing server and client devices without additional hardware investment, possessing good industrial applicability and promotional value.

[0100] Figures 1-4 Each step in the flowchart has been described in detail in the specific embodiments above. The document permission management device includes: one or more processors, and a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any of the above embodiments. The storage medium includes, but is not limited to, computer-readable storage media such as ROM, RAM, hard disk, solid-state drive, USB flash drive, and CD-ROM.

Claims

1. A document permission management method, characterized in that, include: In response to the first user's access request to the target document, obtain the first user's team affiliation information and role information; The target team to which the first user belongs is determined based on the team affiliation information, and the team permission configuration information of the target team is obtained. The set of role permissions corresponding to the first user is determined from the team permission configuration information based on the role information; Obtain the document permission tags of the target document, wherein the document permission tags include a list of visible teams and an operation permission matrix; The access permissions of the first user to the target document are determined by matching the first user's role permission set with the document permission tags.

2. The document permission management method according to claim 1, characterized in that, The document permission tag also includes a team identifier to which the document belongs; the step of matching the first user's role permission set with the document permission tag to determine the first user's access permissions to the target document includes: Determine whether the target team belongs to the list of visible teams; If the target team is not in the list of visible teams, then it is determined that the first user has no access rights to the target document; If the target team belongs to the list of visible teams, then the first user's at least one operation permission for the target document is determined by matching the role permission set with the operation permission matrix item by item.

3. The document permission management method according to claim 2, characterized in that, The step of determining at least one operation permission of the first user for the target document by matching each item of the role permission set with the operation permission matrix includes: Iterate through each permission item in the operation permission matrix; For each permission item, determine whether there is a permission identifier in the role permission set that matches the permission item; If a match is found, the first user is granted the operation permission corresponding to that permission item; If no match is found, the operation permission corresponding to that permission item for the first user is denied.

4. The document permission management method according to claim 1, characterized in that, The team permission configuration information is generated in the following way: In response to a team administrator's role creation action, obtain the role name and at least one menu permission assigned to that role; Associate the character name with the at least one menu permission and store it to generate a character entity; In response to a team administrator's member addition operation, retrieve the member's identifier and the target role assigned to that member; The member identifier is associated with the target role and stored to generate a member-role mapping relationship.

5. The document permission management method according to claim 4, characterized in that, The method further includes: In response to the team administrator's edit operation on the target role, obtain the updated role permission configuration; Update the set of role permissions corresponding to the target role according to the updated role permission configuration; Based on the member-role mapping relationship, the updated set of role permissions will be synchronously applied to all members bound to the target role.

6. The document permission management method according to claim 1, characterized in that, The method further includes: In response to the second user's team switching operation, obtain the target team selected by the second user for switching; Switch the second user's current team context to the target switching team; Refresh the second user's role permission set to the role permission set corresponding to the target switching team; The updated interface displays relevant data from the target switching team.

7. The document permission management method according to claim 1, characterized in that, The method further includes: In response to a team administrator's invitation to an unregistered user, an invitation link containing team association information is generated. In response to the unregistered user completing registration through the invitation link, the unregistered user is automatically associated with the target team, and role permissions are assigned to the unregistered user according to the preset role information in the invitation operation.

8. The document permission management method according to claim 1, characterized in that, The step of obtaining the team affiliation information and role information of the first user includes: Parse the user identifier from the login token of the first user; Query the user-team mapping table based on the user identifier to obtain all team identifiers associated with the first user and the currently selected team identifier; The member-role mapping table is queried based on the user identifier and the currently selected team identifier to obtain the role identifier of the first user in the target team.

9. A document permission management device, characterized in that, include: One or more processors; as well as Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the document permission management method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the document permission management method as described in any one of claims 1 to 8.

Images