Collaborative table permission processing method, related device and medium

Abstract

The invention provides a collaboration table permission processing method, a related device and a medium, and the method comprises the steps: executing permission setting on a target collaboration table, and obtaining a plurality of first permission entries; generating a first permission storage table based on the plurality of first permission entries; in response to a copy creation request for the target cooperation table, creating a target cooperation table copy of the target cooperation table; generating a second permission storage table associated with the target cooperation table copy based on the first permission storage table; in response to an operation request of a target user for a target area in the target cooperation table copy, determining a matched permission entry in the plurality of second permission entries; and authorizing the operation request based on the second operation authority in the matched authority entry. According to the method, after the table copy is created, the permission setting efficiency of the table copy can be improved, and the safety of operation processing on the table copy can be improved. The method and the device can be applied to scenes such as online office and data collection.

Description

Technical Field

[0001] This disclosure relates to the field of online documents, and in particular to a method, apparatus and medium for handling permissions on collaborative forms. Background Technology

[0002] With the development of internet technology, users are increasingly inclined to use collaborative spreadsheets for collaborative work and information collection. However, as an online spreadsheet that allows multiple users to operate simultaneously, each user can view and modify the data in the spreadsheet, which can lead to risks of information leakage or tampering. Therefore, administrators often assign specific access permissions to different cells in the collaborative spreadsheet. These permissions are typically written directly into the collaborative spreadsheet as attribute data.

[0003] In practical use of collaborative spreadsheets, there is often a need to create copies of the spreadsheet. In related technologies, when creating a copy, because operation permissions are stored as attribute data in the collaborative spreadsheet, they cannot be migrated to the copy along with the metadata in the original spreadsheet. This forces the creator of the copy to reset all operation permissions in the copy, which is time-consuming and cumbersome. Furthermore, forgetting to set any permission for the copy can lead to information security issues. Summary of the Invention

[0004] This disclosure provides a collaborative form permission processing method, related apparatus, and medium, which can improve the efficiency of setting permissions for the form copy after it is created, and enhance the security of processing operations on the form copy. According to one aspect of this disclosure, a method for handling permissions in collaborative forms is proposed, comprising: Perform permission settings on the target collaboration table to obtain multiple first permission entries. Each first permission entry includes a region within the table, a first permission user corresponding to the region within the table, and a first operation permission corresponding to the first permission user. Based on the multiple first permission entries, a first permission storage table is generated; In response to a request to create a copy of the target collaboration table, a target collaboration table copy is created. Based on the first permission storage table, a second permission storage table is generated that is associated with the target collaboration table copy. The second permission storage table contains multiple second permission entries. Each second permission entry includes the table area, the second permission user corresponding to the table area, and the second operation permission corresponding to the second permission user. In response to a target user's operation request for a target area in the target collaborative table copy, a matching permission entry is determined from the plurality of second permission entries, wherein the target user matches the second permission user in the matching permission entry, and the target area matches the in-table area in the matching permission entry; The operation request is authorized based on the second operation permission in the matching permission entry.

[0005] According to one aspect of this disclosure, a collaborative form permission processing device is provided, comprising: The permission setting unit is used to perform permission settings on the target collaborative table to obtain multiple first permission entries. The first permission entries include a table area, a first permission user corresponding to the table area, and a first operation permission corresponding to the first permission user. The first generation unit is used to generate a first permission storage table based on the plurality of first permission entries; The first creation unit is configured to create a target collaboration table copy in response to a request to create a copy of the target collaboration table; The second generation unit is used to generate a second permission storage table associated with the target collaboration table copy based on the first permission storage table. The second permission storage table contains a plurality of second permission entries. The second permission entries include the table area, the second permission user corresponding to the table area, and the second operation permission corresponding to the second permission user. The first matching unit is configured to, in response to a target user's operation request for a target area in the target collaborative table copy, determine a matching permission entry among the plurality of second permission entries, wherein the target user matches a second permission user in the matching permission entry, and the target area matches the table area in the matching permission entry; The first authorization unit is used to authorize the operation request based on the second operation permission in the matching permission entry.

[0006] Optionally, the permission setting unit is used for: In response to a triggering action on a region within the target collaboration table, a list of candidate users corresponding to that region is displayed. In response to the selection of a candidate user from the candidate user list, the selected candidate user is determined as the first authorized user corresponding to the area in the table; Display a list of candidate permissions; In response to the selection of candidate permissions from the candidate permission list, the selected candidate permission is determined as the first operation permission corresponding to the first permission user; The first permission entry is obtained based on the area in the table, the first permission user, and the first operation permission.

[0007] Optionally, the first creation unit is used for: In response to the request to create a copy of the target collaboration table, obtain the metadata corresponding to the target collaboration table; Based on the acquired metadata, a metadata copy is generated; A second identifier for generating a copy of the target collaboration form; Based on the metadata copy and the second identifier, create the target collaboration form copy.

[0008] Optionally, the first creation unit is used for: Obtain the identifier of the user who created the target collaboration form; In response to the request to create a copy of the target collaboration table, obtain the identifier of the user who initiated the copy creation request; If the initiating user identifier does not match the creating user identifier, send a permission request to the creating user corresponding to the creating user identifier; If a permission response to the permission request is received from the user who created the form, a copy of the target collaboration form is created.

[0009] Optionally, the first creation unit is used for: Determine the user who initiated the copy creation request; From the first permission storage table, determine the initiating user permission entry that matches the initiating user for the first permission user; Based on the initiating user's permission entries, determine the blocked areas in the target collaboration table that the initiating user does not have permission to view; Copy the metadata of the target collaboration table to obtain a metadata copy, and remove the data of the cells corresponding to the shielded area from the metadata copy; The target collaboration table copy is generated based on the metadata copy.

[0010] Optionally, the copy creation request directs a first user group to use the target collaboration form copy, the first user group being different from a second user group using the target collaboration form; the second generation unit is configured to: Identify users who are in the second user group but not in the first user group who are experiencing reduced usage; Identify incremental users who are in the first user group but not in the second user group; The plurality of first permission entries are copied to obtain a plurality of copies of the first permission entries, and the reduced user is deleted from the first permission users in the plurality of copies of the first permission entries; In the second user group, a matching user that matches the incremental user is determined; If the first permission user in the first permission entry copy contains the matching user, the incremental user is added to the first permission user in the first permission entry copy to obtain a second permission entry, and the second permission entry is associated with the target collaboration table copy to obtain the second permission storage table.

[0011] Optionally, the second generating unit is used for: Determine the first attribute parameter of the multiple attributes of the incremental user; For each user in the second user group, determine the second attribute parameter of the multiple attributes of the user; For each attribute, determine the second attribute parameter of each user in the second user group and the attribute matching degree with the first attribute parameter of the incremental user; Based on the attribute matching degree corresponding to the multiple attributes, determine the user matching degree between each user in the second user group and the incremental user; Based on the user matching degree, the matching user is determined among each user in the second user group.

[0012] Optionally, the second generating unit is used for: Obtain the attribute weights of each of the multiple attributes; Based on the attribute weights, a weighted average of the attribute matching degrees corresponding to the multiple attributes is calculated to obtain the user matching degree.

[0013] Optionally, the second generating unit is used for: Display a permission migration list, which includes a permission migration user column and a permission receiving user column. The permission migration user column includes users in the second user group, and the permission receiving user column includes users in the first user group. In response to the permission migration operation of the initiating user in the copy creation request on the permission migration list, the permission mapping relationship between the user whose permissions are to be received in the first user group and the user whose permissions are to be migrated in the second user group is determined; Copy the plurality of first permission entries to obtain a plurality of copies of the first permission entries; If the first permission user in the first permission entry copy is the permission to be migrated user, based on the permission mapping relationship, the first permission user in the first permission entry copy is changed from the permission to be migrated user to the corresponding permission to receive user, resulting in multiple second permission entries, and the second permission entries are associated with the target collaboration table copy to obtain the second permission storage table.

[0014] Optionally, the second generating unit is used for: Identify users who are in the second user group but not in the first user group who are experiencing reduced usage; Identify incremental users who are in the first user group but not in the second user group; The reduced users are identified as users in the permission migration list, and the increased users are identified as users in the permission receiving list. Based on the permission migration list and the permission receiving list, the permission migration list is displayed.

[0015] Optionally, the second generating unit is used for: Obtain the first number of the first permission entries; The first use case for obtaining a copy of the target collaboration table; If the first number satisfies the first condition, or the first use case satisfies the second condition, a second permission storage table associated with the target collaboration table copy is generated based on the first permission storage table.

[0016] Optionally, the second generating unit is used for: Copy the first permission storage table to obtain a copy of the first permission storage table; Remove the first identifier from the copy of the first permission storage table to obtain the original copy of the first permission storage table; Obtain the second identifier of the target collaboration table copy; Based on the first permission storage table body and the second identifier, a second permission storage table associated with the target collaboration table copy is generated.

[0017] Optionally, the first matching unit is used for: Obtain the target collaboration table copy identifier from the operation request; Determine the second permission storage table that matches the second identifier with the target collaboration table copy identifier; Among the plurality of second permission entries in the second permission storage table, the matching permission entry is determined.

[0018] Optionally, the operation request includes an operation type, and the first authorization unit is used to: Obtain the operation type from the operation request; If the operation type matches the second operation permission, the operation request is authorized.

[0019] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the collaborative form permission processing method as described above.

[0020] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the collaborative table permission processing method as described above.

[0021] According to one aspect of this disclosure, a computer program product is provided, the computer program product including a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the collaborative form permission processing method as described above.

[0022] Considering that in related technologies, operation permissions are stored as attribute data in the target collaboration table and cannot be migrated to the copy of the target collaboration table along with the metadata in the target collaboration table, this embodiment sets up a separate first permission storage table for the target collaboration table. When permissions are set for the target collaboration table, the first permission storage table is updated. When a copy of the target collaboration table is created, a second permission storage table associated with the copy of the target collaboration table is automatically generated based on the first permission storage table. In this way, when an operation is performed on the copy of the target collaboration table, the second permission storage table is used to determine whether the target user has the operation permission. This eliminates the need for the creator of the copy of the target collaboration table to reset all operation permissions after the copy is created, improving the efficiency of permission setting for the table copy. At the same time, since the second permission storage table is automatically obtained based on the first permission storage table when the copy is created, automated processing reduces errors caused by manual operation compared to manually setting all permissions, thus improving the security of operating on the table copy. Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0023] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0024] Figure 1This is an architecture diagram of the system to which the collaborative form permission processing method according to an embodiment of the present disclosure is applied; Figure 2 This is a schematic diagram of the interface of an embodiment of this disclosure applied in a collaborative office scenario; Figure 3 This is a schematic diagram of the interface when an embodiment of this disclosure is applied to a problem investigation scenario; Figure 4 This is a flowchart of a collaborative table permission processing method according to an embodiment of the present disclosure; Figure 5 This is a schematic diagram of an interface for setting permissions according to an embodiment of the present disclosure; Figure 6 This is a schematic diagram illustrating the association of a permission table with a table and a user according to an embodiment of this disclosure; Figure 7 This is a schematic diagram of a process for creating a copy of a target collaboration form according to an embodiment of this disclosure; Figure 8 According to one embodiment of this disclosure, the process of saving the table structure and permissions of the target collaboration table as a table template is shown in a diagram. Figure 9 This is a schematic diagram of a process for creating a copy of a table using a table template according to an embodiment of the present disclosure; Figure 10 yes Figure 4 A flowchart of step 406; Figure 11 yes Figure 4 A flowchart of step 401; Figure 12 This is a schematic diagram of selecting a region within a table according to an embodiment of this disclosure; Figure 13 This is a schematic diagram illustrating the selection of a first-authority user according to an embodiment of this disclosure; Figure 14 This is a schematic diagram illustrating the selection of a first operation permission according to an embodiment of this disclosure; Figure 15 yes Figure 4 A sub-flowchart of step 403; Figure 16 This is a schematic diagram of the metadata of a target collaboration table according to an embodiment of the present disclosure; Figure 17 yes Figure 4 Another sub-flowchart of step 403; Figure 18 yes Figure 4 Another sub-flowchart of step 403; Figure 19 This is a schematic diagram of a process for creating a copy of a target collaboration form according to an embodiment of the present disclosure; Figure 20 yes Figure 4 A sub-flowchart of step 404; Figure 21 yes Figure 20 A sub-flowchart of step 2004; Figure 22 yes Figure 21 A sub-flowchart of step 2104; Figure 23 yes Figure 4 Another sub-flowchart for step 404; Figure 24 This is a schematic diagram illustrating the establishment of a permission mapping relationship according to an embodiment of this disclosure; Figure 25 yes Figure 23 A sub-flowchart of step 2301; Figure 26 yes Figure 4 Another sub-flowchart for step 404; Figure 27 yes Figure 4 Another sub-flowchart for step 404; Figure 28 yes Figure 4 A sub-flowchart of step 405; Figure 29 This is a process diagram illustrating a specific implementation example of the collaborative table permission processing method according to an embodiment of this disclosure; Figure 30 This is a block diagram of an apparatus for processing target collaboration form permissions according to an embodiment of the present disclosure; Figure 31 This is a terminal structure diagram according to an embodiment of the present disclosure; Figure 32 This is a server structure diagram according to an embodiment of the present disclosure. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0026] With the development of internet technology, users are increasingly inclined to use collaborative spreadsheets for collaborative work and information collection. However, as an online spreadsheet that allows multiple users to operate simultaneously, each user can view and modify the data in the spreadsheet, which can lead to risks of information leakage or tampering. Therefore, administrators often assign specific access permissions to different cells in the collaborative spreadsheet. These permissions are typically written directly into the collaborative spreadsheet as attribute data.

[0027] In practical use of collaborative spreadsheets, there is often a need to create copies of the spreadsheet. In related technologies, when creating a copy, because operation permissions are stored as attribute data in the collaborative spreadsheet, they cannot be migrated to the copy along with the metadata in the original spreadsheet. This forces the creator of the copy to reset all operation permissions in the copy, which is time-consuming and cumbersome. Furthermore, forgetting to set any permission for the copy can lead to information security issues.

[0028] Based on this, embodiments of this disclosure provide a method, related apparatus, and medium for handling permissions in collaborative forms. The method for handling permissions in collaborative forms provided by embodiments of this disclosure is capable of...

[0029] System architecture and scenario description of the embodiments disclosed herein Figure 1 This is a system architecture diagram of the collaborative form permission processing method applied according to embodiments of the present disclosure. It includes an object terminal 110, an Internet 120, a gateway 130, and a server 140, etc.

[0030] The target terminal 110 is a device used to process target collaborative forms, and users can perform operations such as inputting strings through the target terminal 110. The target terminal 110 includes various forms such as desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, dedicated terminals, and graphics tablets. Furthermore, it can be a single device or a collection of multiple devices. For example, multiple devices can be connected via a local area network, sharing a single display device to work collaboratively, forming a single terminal. The terminal can also communicate with the Internet 120 via wired or wireless means to exchange data.

[0031] Gateway 130, also known as an internetwork connector or protocol converter, is a computer system or device that enables network interconnection at the transport layer and acts as a translator. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateway 130 also provides filtering and security functions. Messages sent from target terminal 110 to server 140 are forwarded to the corresponding server 140 via gateway 130. Messages sent from server 140 to target terminal 110 are also forwarded to the corresponding target terminal 110 via gateway 130.

[0032] Server 140 refers to a computer system capable of providing target collaboration form permission processing services to object terminal 110. Compared to object terminal 110, server 140 has higher requirements in terms of stability, security, and performance. Server 140 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines). Server 140 can also communicate with the Internet 120 via wired or wireless means to exchange data.

[0033] The embodiments disclosed herein can be applied in various scenarios, such as multi-user collaborative work and problem investigation.

[0034] (a) Multi-user collaborative office In multi-user collaborative work scenarios, a complete task is often divided into multiple sub-tasks and assigned to different users for completion. For example, refer to... Figure 2 A task is divided into multiple subtasks and assigned to users 1 through 4. During the execution of these subtasks, the data obtained by each user while processing their assigned subtasks needs to be aggregated to determine the progress of each subtask, or to determine intermediate results based on the task data corresponding to each subtask. At this point, refer to... Figure 2 This allows users to fill in the required summary task data in the corresponding areas of the collaboration table. To ensure the security of the task data, specific access permissions are often set for different areas of the collaboration table. For example, in... Figure 2In this method, columns two through five of the collaboration table can be set to be editable only by users 1 through 4. Users 1 through 4 can then summarize the task data by filling in the corresponding task data in the relevant areas of the collaboration table. When executing another task B, task B is also divided into multiple subtasks and assigned to users 1 through 4 for execution. The collaboration table is then used to summarize the task data obtained by users 1 through 4 when executing each subtask of task B. At this point, using the collaboration table permission handling method disclosed herein, a copy of the collaboration table can be created, and the operation permissions set in the original collaboration table can be migrated to the copy. This allows the copy to be used directly to summarize the task data obtained by users 1 through 4 when executing each subtask of task B, without needing to create a new collaboration table and perform cumbersome permission settings in it.

[0035] (ii) Scenarios for Problem Research In daily life, there are often needs to conduct surveys involving multiple residents. For example, community property management personnel may need to survey information about various residents in the community. In this case, property management personnel can use a collaborative survey form to create a resident survey collaborative form and send it to each resident in the community for completion. However, to ensure the security of each resident's information—that is, to ensure that the information filled in by each resident cannot be viewed by other residents who participated in filling out the collaborative survey form—it is necessary to set certain access permissions for different areas of the resident survey collaborative form. For example, refer to... Figure 3 This method allows each row in the resident survey collaboration form to be set to be editable and viewable only by a specific resident. This ensures that the information entered by each resident is only visible to that resident and not to other residents, thus guaranteeing information security. When property management personnel conduct subsequent surveys of community residents, they can directly create a copy of the resident survey collaboration form and use the permission handling method proposed in this disclosure to migrate the permission settings from the original form to the copy, forming a new copy.

[0036] It should be understood that the above description only illustrates some application scenarios of this disclosure. The business scenarios to which this disclosure can be applied may include, but are not limited to, the specific embodiments described above.

[0037] General Description of Embodiments in this Disclosure Reference Figure 4 , Figure 4 A flowchart illustrating the permission handling method for the collaborative form proposed in this disclosure is shown. The permission handling method for the collaborative form includes, but is not limited to: Step 401: Perform permission settings on the target collaboration table to obtain multiple first permission entries. The first permission entries include the table area, the first permission user corresponding to the table area, and the first operation permission corresponding to the first permission user. Step 402: Generate a first permission storage table based on multiple first permission entries; Step 403: In response to the request to create a copy of the target collaboration table, create a target collaboration table copy. Step 404: Based on the first permission storage table, generate a second permission storage table associated with the target collaborative table copy. The second permission storage table contains multiple second permission entries. Each second permission entry includes a region within the table, a second permission user corresponding to the region within the table, and a second operation permission corresponding to the second permission user. Step 405: In response to the target user's operation request on the target area in the target collaborative table copy, a matching permission entry is determined among multiple second permission entries, wherein the target user matches the second permission user in the matching permission entry, and the target area matches the table area in the matching permission entry; Step 406: Authorize the operation request based on the second operation permission in the matching permission entry.

[0038] In step 401, the target collaborative spreadsheet is a spreadsheet that allows multiple users to edit simultaneously; it can be an online spreadsheet. Users can access the interface of the target collaborative spreadsheet and edit it within the interface. Each user's edits are uploaded to the corresponding server of the target collaborative spreadsheet and synchronized from the server to the access interfaces of other users, thereby enabling multiple users to collaboratively edit the target collaborative spreadsheet.

[0039] Understandably, as a spreadsheet that can be edited simultaneously by multiple users, allowing all users to freely view and edit all cells in the target collaboration spreadsheet presents several challenges. Firstly, it makes it difficult to determine which user's data is valid, potentially leading to concurrency issues and making the spreadsheet difficult to manage. Secondly, the spreadsheet may contain user information, internal organizational information, or information that needs to be kept confidential from certain users. Allowing all users to freely view all cells could result in information leakage and security issues. Therefore, this embodiment requires permission settings for the target collaboration spreadsheet to restrict the areas each user can view or edit.

[0040] When setting permissions for a target collaboration table, multiple first permission entries are generated. Each first permission entry contains permission setting parameters related to a single permission set by the administrator user for the target collaboration table. These parameters include the table area set by the administrator user, the first permission user corresponding to the table area, and the first operation permissions of the first permission user for the table area. The first permission entry indicates the types of operations that the corresponding first permission user can perform when operating on the table area. These types of operations may include, but are not limited to, viewing data in the table area and editing data in the table area.

[0041] A table region refers to an area within a target collaborative table comprised of cells with assigned access permissions. Each cell within a table region can be selected by the administrator of the target collaborative table. As a table that allows multiple users to edit simultaneously, when using the target collaborative table, selected cells are set to be viewable or editable only by specific users. The area comprised of these selected cells is the table region. For example, if an administrator sets permissions for row n of the target collaborative table to allow only user 1 to edit, then row n is the corresponding table region. Specifically, the administrator can select cells in the target collaborative table using the mouse or other methods, and then set permissions for these selected cells. The area comprised of these selected cells is then defined as a table region.

[0042] Understandably, when several cells in a target collaboration table are selected as a table area, it's necessary to set operation permissions for each user who can access the target collaboration table for that table area, and generate multiple first-level permission entries corresponding to that table area. This determines the type of operation each user can perform on the cells within that table area. For example, if users 1 through 10 can access the target collaboration table, and during permission settings, the administrator sets row n in the target collaboration table to be editable only by user 1, preventing other users from viewing that row, then multiple first-level permission entries need to be generated for row n as the table area. One of these first-level permission entries sets user 1 as the first-level user with editable first-level operation permission; the remaining first-level permission entries set users 2 through 10 as the first-level users with inaccessible first-level operation permission.

[0043] Specifically, administrators can select specific users in the permission settings interface and individually set first-level operation permissions for these specific users within a defined table area. They can also categorize users other than the selected specific users as "other users" and assign them the same operation permissions. For example, refer to... Figure 5 Administrators can select users A and B as specific users and set their access permissions for the designated table area to "view only," while setting the access permissions for other users (excluding users A and B) to "not view" for the designated table area.

[0044] First-authority users refer to one or more users who are allowed to operate on the corresponding area within the table. For example, if a first-authority entry indicates that row n of the target collaboration table is set to be editable only by user 1, then user 1 is the first-authority user corresponding to that entry. Specifically, the first-authority user can be a user selected by the administrator user of the target collaboration table. For example, the administrator user can specify certain users from their friend list as first-authority users; or, users with a specific attribute can be specified as first-authority users, such as users in the same workgroup as the administrator user; or, users who can access the target collaboration table can be organized into a candidate user list, from which the administrator user selects the first-authority user.

[0045] It is understandable that when an administrator sets permissions for a target collaborative table, multiple users may have the same operational permissions for the same area within the table. Therefore, in this embodiment, multiple users with the same operational permissions for the same area within the table can be identified as first-permission users in the same first-permission entry; that is, a single first-permission entry can correspond to multiple first-permission users. For example, refer to... Figure 5 When setting permissions for the target collaboration table, the creator sets the nth column of the target collaboration table as a table area, specifying that only users 1 and 2 can view this table area, while other users are not allowed to view it. This generates two first permission entries, denoted as First Permission Entry 1 and First Permission Entry 2, each using the nth column as a table area. In First Permission Entry 1, users 1 and 2 are designated as first permission users, and the "view only" operation permission is defined as the corresponding first operation permission. In First Permission Entry 2, all other users besides users 1 and 2 are designated as first permission users, and the "cannot view this table area" operation permission is defined as the corresponding first operation permission.

[0046] First-level operation permissions refer to the permissions that a user with first-level permissions has when operating on a range within a table. It represents the types of operations that the user with first-level permissions can perform on that range. For example, it might represent the permission for a user with first-level permissions to view but not edit data within a range of the table, or the permission for a user with first-level permissions to view and edit data within a range of the table.

[0047] It is understandable that some operations on the target collaborative table require the user to have permission for another operation. For example, a user often needs permission to view the data in a cell of the target collaborative table before they can edit the data in that cell. Based on this, in this embodiment, multiple different permission levels can be preset as candidate operation permissions, and the executable operation types corresponding to each permission level can be preset. The higher the permission level, the more types of operations can be performed on the cells in the corresponding table area. Then, the first operation permission for the user with the first permission to operate on the table area is determined from the preset multiple permission levels. For example, in one embodiment, three permission levels, from level 1 to level 3, can be set as candidate operation permissions. Level 1 indicates that the user cannot view the data in the corresponding table area, level 2 indicates that the user can view but cannot edit the data in the corresponding table area, and level 3 indicates that the user can both view and edit the data in the corresponding table area. At this point, all users are initially set to the lowest permission level by default, so that users who are not authorized by the administrator cannot view the data in the various table areas of the target collaborative table. When the administrator sets permissions, the permission level of the selected user can be modified to set the corresponding permission level of each user as the first operation permission for each selected table area, thus completing the permission settings and obtaining multiple corresponding first permission entries.

[0048] Understandably, if a cell in the target collaboration table is not set as a table area in any first-level permission entry, then all users who can access the target collaboration table can set the operation permission for that cell to the highest permission level, so that all users who can access the target collaboration table can view and edit that cell.

[0049] Specifically, the target collaboration table interface includes an operation function area with options for setting permissions. When setting permissions for the target collaboration table, the administrator can select a subset of cells using the mouse or other methods; this selected area constitutes the table's inner area. The administrator can then click on the permission setting options to determine the first-level user and their primary operation permissions. For example, refer to... Figure 5 , Figure 5 This diagram illustrates an interface for setting permissions on a target collaboration table. The administrator user of the target collaboration table can first select the nth column as the table area using the mouse or other methods. Then, by clicking the permission settings function in the operation area, a pop-up window will appear in the target collaboration table interface, allowing the administrator to set the first user with the first permission corresponding to the selected table area, as well as the first operation permissions of that user for that table area. For example, in... Figure 5 In the process, select User 1 and User 2, and set their first operation permission for the selected table area to "view only." Simultaneously, set the operation permission for all other users within the table area to "disallow viewing." Then, click the "OK" option in the pop-up window. Upon detecting the administrator user clicking the "OK" option, the target collaborative table's front-end interface will generate a permission setting request carrying the corresponding table area, first-permission user, and first operation permission parameters, and send it to the target collaborative table's program or webpage's server backend.

[0050] Upon receiving a permission setting request, the server backend of the target collaboration table's program or webpage parses the request, obtains the corresponding permission setting parameters, and generates a corresponding first permission entry based on these parameters, thereby performing permission settings on the target collaboration table. For example, in a scenario based on... Figure 5In the first permission entry generated by the permission setting parameters shown, the table area is the nth column of the target collaboration table. The first permission user can be User 1 or User 2, and the first operation permission corresponding to User 1 and User 2 is "view only". A second permission entry is also generated, using the nth column of the target collaboration table as the table area, and another collaboration user (excluding User 1 and User 2) as the first permission user, with the permission to not view the table area as the first operation permission. It is understood that the first permission entry has pre-defined fields for filling in various permission setting parameters. The first permission entry is obtained by filling in the information representing the table area, the information representing the first permission user, and the information representing the first operation permission into the corresponding positions in the first permission entry. For example, information representing each cell in the table area (such as the cell identifier, or the row and column identifiers corresponding to the row and column of these cells in the target collaboration table), the user identity identifier corresponding to the first permission user, and the parameters representing operation permissions at different permission levels are filled into the corresponding fields in the first permission entry.

[0051] In step 402, the first permission storage table is a database table used to store each first permission entry corresponding to the target collaboration table. It can be stored in a database used to store the metadata of the target collaboration table. The first permission storage table can be associated with the target collaboration table through foreign keys, so that each first permission entry in the first permission storage table can be applied to the target collaboration table, thereby setting the corresponding permissions in the target collaboration table.

[0052] Specifically, the target collaboration table is assigned a corresponding table identity identifier (table ID). The first permission storage table can have one table identity identifier field and multiple permission fields. In this case, the table identity identifier of the target collaboration table is filled into the table identity identifier field, and each first permission entry is filled into the permission fields, resulting in the first permission storage table. In this first permission storage table, each first permission entry and the target collaboration table are linked via a foreign key. Meanwhile, refer to... Figure 6 The first-permission storage table can also be linked to the user table via foreign keys to determine the first-permission user corresponding to each first-permission entry.

[0053] In one possible implementation, the first permission entry corresponding to the target collaboration table may be organized into the same permission storage table and stored in the database along with permission entries corresponding to other collaboration tables. In this case, in addition to the pre-defined fields for filling in various permission settings parameters, each first permission entry also has a table identity field. When generating the first permission entry, the table identity of the target collaboration table is filled into the table identity field of each first permission entry, so as to directly associate each first permission entry with the target collaboration table. Then, the sub-table formed by all the first permission entries associated with the target collaboration table is used as the first permission storage table.

[0054] In step 403, the copy creation request is an operation request to create a copy of the target collaborative table. This copy creation request can be initiated by the administrator user of the target collaborative table or by other users. The target collaborative table copy is another collaborative table generated by copying the metadata of the target collaborative table. The table structure of the target collaborative table copy is consistent with that of the target collaborative table. The table structure consists of the row height, column width, background color of each cell, data type of the cells, functional relationships between the data entered in the cells, cell merging, and other information from the collaborative table. The content entered in each cell of the target collaborative table can be partially or completely copied to the target collaborative table copy. For example, data in areas that the user who initiated the copy creation request has permission to view in the target collaborative table can be copied to the target collaborative table copy.

[0055] Specifically, the front-end interface of the target collaboration table includes an operation function area, which can include an option to create a copy of the table. (See reference...) Figure 7 When a user clicks the "Create a copy of the table" option in the front-end interface, the copy creation operation is initiated. After the front-end interface passes through the interface with the server backend, the corresponding copy creation request is generated and sent to the server backend of the target collaborative table program or webpage.

[0056] Then, refer to Figure 7 In response to the replica creation request, the server backend generates a replica table in the database to determine the basic information of the target collaborative table replica. This replica table has fields for representing the replica identity, creator identity, and replica name of the target collaborative table replica. For example, the fields of the replica table are shown in Table 1 below:

[0057] Table 1 Next, the database returns the table identity of the target collaboration table copy to the server backend and retrieves the metadata of the target collaboration table from the database. This metadata contains data that determines the table structure of the target collaboration table and the content entered in multiple cells of the target collaboration table. This metadata is copied, and based on the copy identity of the target collaboration table copy, the copied metadata is linked to the target collaboration table copy via a foreign key. This results in a target collaboration table copy with the same table structure as the target collaboration table, storing some or all of the data from the target collaboration table. Then, refer to... Figure 7 Starting from the database, the creation results of the target collaboration table copy are gradually sent to the front-end page for display through the server back-end and interface, so that users can see the created target collaboration table copy on the front-end page.

[0058] In step 404, the second permission storage table is a permission storage table associated with the target collaboration table copy, which can be obtained by copying the first permission storage table and associating the copy result with the target collaboration table copy.

[0059] Specifically, the details of the second permission entry, table area, second permission user, and second operation permission in step 404 can be referred to the relevant descriptions of the first permission entry, table area, first permission user, and first operation permission in step 401. The difference is that the table area in step 404 is a region composed of cells in the target collaborative table copy, the second permission user is the user corresponding to the table area in the target collaborative table copy, and the second operation permission is the permission of the second permission user when performing operations on the table area in the target collaborative table copy. These will not be elaborated further here.

[0060] In one embodiment, each first permission entry in the first permission storage table of the database can be copied to obtain each second permission entry. Since the target collaboration table copy is also actually a collaboration table, refer to... Figure 7 When a copy of the target collaborative table is created, it is assigned a corresponding identity identifier. At this point, a database table can be created with table identity entries and permission fields. The copy identity identifier is populated into the table identity entry, and the various secondary permission entries are populated into the permission fields, thus creating a secondary permission storage table associated with the target collaborative table copy in the database.

[0061] In another embodiment, each first permission entry itself has a table identity field. When the first permission entries are copied to obtain second permission entries, the second permission entries also have corresponding table identity fields. The copy identity corresponding to the target collaborative table copy is filled into the identity field of each second permission entry, thereby associating each second permission entry with the target collaborative table copy. The database table composed of all second permission entries is the second permission storage table associated with the target collaborative table copy. For example, the fields included in the second permission entries can be as shown in Table 2 below:

[0062] Table 2 It should be noted that the role field is used to characterize the role of the second-level user in the target collaborative table copy. This role can be one of the preset candidate roles, which can include administrator users and collaborating users. The creator of the target collaborative table copy is the administrator user, while the other users are collaborating users.

[0063] In step 405, the operation request is initiated by a user who wants to perform an operation on a cell within a specific area of ​​the target collaborative table copy. The operation initiated by the target user on the target area could be viewing or editing the data entered in the cells within that area. The target user is the user who initiates the operation request. The target area is the area within the table containing the cell that the target user wants to operate on in the target collaborative table copy. For example, user 1 wants to operate on the cell in row m and column n of the target collaborative table copy. This cell is a cell within area A of the table. In this case, user 1 is the target user, and area A of the table is the target area.

[0064] The matching permission entry is a second permission entry used to represent the second operation permission of the target user to the target area, that is, the second permission entry with the target user as the second permission user and the target area as the area within the table.

[0065] Understandably, in some embodiments, when a target is used to access a copy of a target collaborative table, it can be assumed that the target user needs to view the data entered in each cell of the target collaborative table copy. Therefore, when a user accesses the target collaborative table copy, that user can be identified as the target user, each area within the table can be identified as the target area, and multiple corresponding operation requests can be generated. These operation requests are used to represent that the target user needs to view the data in the corresponding area within the table. For example, if the target collaborative table copy has areas A to J, when user 1 accesses the target collaborative table copy, 10 operation requests are generated. The target user for all 10 operation requests is user 1, and the corresponding target areas are, in order, areas A to J within the table.

[0066] When a user clicks on a cell in the target collaborative table copy, it indicates that the user needs to enter data into that cell, or modify or delete data in that cell; that is, the user wants to edit that cell. At this point, the entire table area containing that cell can be defined as the target area, the user can be identified as the target user, and an operation request can be generated to mark the target user as needing to edit the data in that target area.

[0067] It is understandable that, since the target collaboration table copy and the second permission storage table are linked via a foreign key, when operating on the target collaboration table copy, each user can only operate on each area according to the permissions set in the respective second permission entries in the second permission storage table. That is, when the target user operates on the target area, they can only execute the operations supported by the second operation permissions in the corresponding second permission entry. Based on this, in this embodiment, in response to the target user's operation request to operate on the target area in the target collaboration table copy, according to the target user's identity identifier and the area information corresponding to the target area, a second permission entry used to determine the target user's second operation permissions on the target area is searched from multiple second permission entries as a matching permission entry, so as to determine whether the operation corresponding to the operation request can be executed subsequently based on the matching permission entry.

[0068] It should be noted that, as described in the detailed description of step 401, when setting permissions, if a certain portion of cells is determined to be a range within a table, it is necessary to set the operation permissions for that range within the table for each user who can access the target collaborative table, and generate multiple permission entries corresponding to that range. Therefore, the second permission storage table will necessarily contain second permission entries with the target user as the second permission user and the target range as the range within the table.

[0069] In step 406, if a matching permission entry corresponding to the target user and the target area exists in the second permission storage table, the second operation permission in the matching permission entry is checked. The second operation permission represents the type of operation that the target user can perform in the target area. If the second operation permission in the matching permission entry supports the operation corresponding to the operation request of the target user in the target area, then the operation request is authorized. Otherwise, if the second operation permission in the matching permission entry does not support the operation corresponding to the operation request of the target user in the target area, then the operation request is not authorized, and the operation of the target user in the target area is refused. For example, in a target collaborative table copy, area A is set to be editable only by user 1, while other users only have the permission to view area A. If user 2 initiates an operation request for area A, and the second operation permission in the matching permission entry is a view-only permission level, then if the requested operation is to view the data in area A, the request is authorized, and the data in area A is displayed to user 2. However, if the requested operation is to edit the data in area A, the operation is denied because the second operation permission in the matching permission entry is view-only.

[0070] In the embodiments disclosed in steps 401 to 406, the first permission storage table is updated when setting permissions for the target collaboration table. When a copy of the target collaboration table is created, a second permission storage table associated with the copy is automatically generated based on the first permission storage table. Thus, when an operation is performed on the copy of the target collaboration table, the second permission storage table is used to determine whether the target user has the necessary permissions. This eliminates the need for the creator of the copy to reset all operation permissions after the copy is created, improving the efficiency of permission setting for the table copy. Furthermore, since the second permission storage table is automatically obtained upon copy creation based on the first permission storage table, automated processing reduces errors caused by manual operation compared to manually setting all permissions, thus improving the security of processing operations on the table copy.

[0071] Furthermore, in some embodiments of this disclosure, reference may also be made to Figure 8When using a target collaboration table, each time a user saves the table, the table structure and permission information set within it can be saved to the database as a table template and permission setting template. Specifically, when a user clicks "Save Target Collaboration Table" on the front-end interface, a pop-up window may ask the user whether to save the target collaboration table's permission information. If the user chooses not to save the permission information, the target collaboration table's structure information is saved to the database as a table template. If the user chooses to save the permission information, the permission information and table structure are saved to the database together.

[0072] Then, refer to Figure 9 When a user needs to create a new collaboration form, they can choose to create a new collaboration form using the form template obtained by the user by saving the target collaboration form. That is, create a copy of the target collaboration form. Then, retrieve the form template and permission template obtained based on the target collaboration form from the database, and use them to create a copy of the target collaboration form.

[0073] Reference Figure 10 In one embodiment, the operation request carries an operation type, and step 406 includes: Step 1001: Obtain the operation type from the operation request; Step 1002: If the operation type matches the second operation permission, authorize the operation request. In step 1001, the operation request carries the operation type corresponding to the operation that the target user needs to perform on the target area. The operation type can be viewing the data in the target area or editing the data in the target area. After receiving the operation request, the server backend can extract the corresponding operation type by parsing the operation request.

[0074] In step 1002, the second operation permission in the matching permission entry represents the executable operation types corresponding to all operations that the target user can perform on the target area. By comparing the operation type carried in the operation request with the executable operation types represented by the second operation permission, if the operation type carried in the operation request is one of the multiple executable operation types corresponding to the second operation permission, it indicates that the operation type matches the second operation permission. In this case, the operation request is authorized to execute the target user's operation on the target area; otherwise, if the operation type carried in the operation request is different from all the executable operation types corresponding to the second operation permission, the operation request is rejected.

[0075] In the embodiments disclosed in steps 1001 to 1002, the operation type corresponding to the operation that the target user needs to perform on the target area is extracted from the operation request. Then, the obtained operation type is compared with the executable operation type corresponding to the second operation permission to determine whether the target user can perform the corresponding operation on the target area. Only when the operation type carried in the operation request matches the corresponding second operation permission is the operation corresponding to the operation request authorized. This restricts each user's operation on the target collaboration table copy through the second permission storage table, preventing the target collaboration table copy from being viewed and edited arbitrarily.

[0076] The above provides an overall description of steps 401 to 406. Since steps 402 and 406 have already been described in detail above, the following will only provide a detailed description of steps 401 and steps 403 to 405.

[0077] Detailed description of step 401 In one embodiment, refer to Figure 11 Step 401 may include: Step 1101: In response to a trigger on a region within the target collaboration table, display the list of candidate users corresponding to that region. Step 1102: In response to the selection of a candidate user from the candidate user list, the selected candidate user is determined as the first authorized user corresponding to the area in the table. Step 1103: Display the candidate permission list; Step 1104: In response to the selection of candidate permissions from the candidate permission list, the selected candidate permission is determined as the first operation permission corresponding to the first permission user; Step 1105: Based on the area in the table, the first-authority user, and the first operation permission, obtain the first permission entry.

[0078] In step 1101, triggering a region within a table refers to the trigger information generated when an administrator user selects several cells requiring permission settings in the target collaborative table using a mouse or other means, and clicks the permission settings option in the target collaborative table interface.

[0079] The candidate user list is a list of collaborating users who can access the target collaborative table. These collaborating users are selected by the administrator user of the target collaborative table. It is understood that when the administrator user allows these collaborating users to access the target collaborative table, it indicates that these collaborating users are required to participate in editing certain cells within the target collaborative table. Therefore, when setting permissions, it is necessary to assign corresponding operation permissions to these collaborating users so that they can view or edit data within a specific area of ​​the target collaborative table. Based on this, in this embodiment, when a trigger message is generated upon detecting that a user has selected a specific area within the target collaborative table and clicked the permission setting option, the candidate user list, consisting of these collaborating users participating in editing the target collaborative table, is displayed on the target collaborative table's interface. This allows the administrator user to select the first user with the corresponding permission from the candidate user list and set the corresponding first operation permission. For example, refer to... Figure 12 When a user selects column n as the range in the target collaboration table interface and clicks the permission settings option, a corresponding trigger is generated. Then, refer to... Figure 13 A pop-up window will display a list of candidate users within the interface.

[0080] In step 1102, after the candidate user list is displayed in the target collaboration report interface, the administrator user of the target collaboration table can add a candidate user as the first-permission user corresponding to the area in the table using the mouse or other methods. For example, in Figure 13 The candidate user list includes multiple candidate users, from user 1 to user n. Administrators can select users from the candidate user list in a pop-up window to add them as the first-priority users corresponding to the area in the table. For example, refer to... Figure 14 The administrator user adds multiple users, such as User 2, User 4, ..., as the corresponding first-level users.

[0081] In step 1103, the candidate permission list is a list composed of multiple preset candidate permissions. It is understood that the operations a user can perform on cells in the target collaboration table include at least viewing and editing. To edit data in a cell, the user often needs to view the data in the corresponding cell. Therefore, in this embodiment, the preset candidate permissions can include at least three types: non-viewable, view-only, and editable. In this embodiment, after the administrator user selects the first permission user corresponding to the area within the table, the candidate permission list is displayed in the target collaboration table interface, allowing the administrator user to operate within the target collaboration table interface and select the first operation permission from the candidate permission list. For example, refer to... Figure 14After selecting multiple users, such as User 2 and User 4, as the first-level users, a list of candidate permissions is displayed on the interface to show the preset candidate permissions, such as the candidate permissions of "cannot view", "view only", and "editable".

[0082] In step 1104, after the candidate permission list is displayed in the interface of the target collaboration table, the administrator user can click on the candidate permission in the candidate permission list in the interface by mouse or other means, thereby selecting the clicked candidate permission as the first permission user's first operation permission for the area within the table.

[0083] In step 1105, after determining the area within the table, the corresponding first-authority user, and the first-operation permissions of the first-authority user to the area within the table, the server backend fills the corresponding fields with the user identity identifier corresponding to the first-authority user, the area information corresponding to the area within the table, and the parameters used to represent the first-operation permissions, thereby generating the corresponding first-authority entry.

[0084] In the embodiments disclosed in steps 1101 to 1105, the corresponding table area, first permission user, and first operation permission are determined by the operation of the administrator user corresponding to the target collaboration table in the front-end interface of the target collaboration table. Thus, the corresponding first permission entry can be accurately generated based on the table area defined by the user, the selected first permission user, and the first operation permission.

[0085] Detailed description of step 403 In step 403, in response to the request to create a copy of the target collaboration table, a target collaboration table copy is created. In one embodiment, refer to Figure 15 Step 403 includes: Step 1501: In response to the request to create a copy of the target collaboration table, obtain the metadata corresponding to the target collaboration table; Step 1502: Generate a copy of the metadata based on the acquired metadata; Step 1503: Generate a second identifier for the target collaboration table copy; Step 1504: Create a copy of the target collaboration table based on the metadata copy and the second identifier.

[0086] In step 1501, the metadata corresponding to the target collaboration table is data stored in a database. It includes data used to determine the table structure of the target collaboration table and the content filled in each cell of the target collaboration table. This metadata can be stored in the database in the form of multiple database tables. These database tables have table identity fields. By filling the table identity fields corresponding to the target collaboration table with the table identity fields, these database tables are linked to the target collaboration table through foreign keys, thus forming the target collaboration table.

[0087] For example, refer to Figure 16 The metadata of the target collaboration table is organized into multiple database tables, including a table information table, a row information table, a column information table, and a cell information table. The table information table stores basic information about the target collaboration table, such as its name, identifier, and creator. The column information table stores column identifiers and widths for each column. The row information table stores row identifiers and heights for each row. Each row and column in the row and column information tables is linked to the corresponding table information table via foreign keys. The cell information table stores cell identifiers, cell content (e.g., text or number), cell data format, and cell background color. Each cell in the cell information table is also linked to the corresponding table information table, row information table, and column information table via foreign keys.

[0088] In this embodiment, the database table associated with the target collaboration table can be found from the database based on the table identity identifier, i.e., the first identifier, and the data in the database table associated with the target collaboration table can be determined as the metadata of the target collaboration table. It should be noted that although the first permission storage table corresponding to the target collaboration table is also associated with the target collaboration table, in this embodiment, the first permission storage table is not used as the metadata of the target collaboration table.

[0089] In step 1502, after obtaining the metadata corresponding to the target collaboration table, this metadata is copied to obtain a metadata copy.

[0090] In one embodiment, a portion of this metadata can be copied as a metadata copy according to certain rules. For example, based on the user identity of the user who initiated the copy creation request, the cells contained in the area that the user can view in the target collaborative table are identified as the cells to be copied. Then, all metadata used to determine the table structure and the metadata corresponding to the content entered in the cells to be copied are copied as metadata copies.

[0091] Understandably, the metadata associated with the target collaboration table may also contain data describing the table name, table identity, and creator of the target collaboration table. When copying the metadata, this table information describing the target collaboration table does not need to be copied to the metadata copy.

[0092] In step 1503, the second identifier is the table identity identifier corresponding to the target collaborative table copy. It is understood that the target collaborative table copy is also a collaborative table, and when this target collaborative table copy is generated, the server also assigns a corresponding table identity identifier to it as its unique identifier. Therefore, in this embodiment, the table identity identifier corresponding to the target collaborative table copy can be obtained as the second identifier.

[0093] In step 1504, the metadata copy obtained by copying the metadata is actually a number of database tables. These database tables have table identity fields for populating table identities. Since the metadata copy is obtained by copying the metadata of the target collaborative table, each table identity field in the metadata copy is still filled with the first identity corresponding to the target collaborative table. At this time, the first identity filled in each table identity field in the metadata copy is modified to the second identity, thereby associating the metadata copy with the target collaborative table copy. In this way, a target collaborative table copy with the same table structure as the target collaborative table and whose cells are filled with the data of the corresponding cells in the target collaborative table can be obtained.

[0094] In the embodiments disclosed in steps 1501 to 1504, by searching the database for the metadata corresponding to the target collaboration table based on the first identifier corresponding to the target collaboration table, and copying the metadata used to characterize the table structure of the target collaboration table and the content filled in the cells as a metadata copy, and then associating the metadata copy with the target collaboration table copy based on the second identifier corresponding to the target collaboration table copy, a target collaboration table copy with the same table structure as the target collaboration table can be generated.

[0095] In one embodiment, refer to Figure 17 Step 403 also includes: Step 1701: Obtain the creator user identifier for the target collaboration table; Step 1702: In response to the request to create a copy of the target collaboration table, obtain the identifier of the user who initiated the copy creation request; Step 1703: If the initiating user ID and the creating user ID do not match, send a permission request to the creating user corresponding to the creating user ID. Step 1704: If a permission response to the permission request is received from the user who created the request, create a copy of the target collaboration form.

[0096] In step 1701, the creation user identifier is the user identity identifier corresponding to the user who created the target collaboration table. It is understood that the creator of the target collaboration table is often also the administrator user of the target collaboration table. Other users' operation permissions on the target collaboration table are set by the creator. To facilitate the creator's management of the target collaboration table, the creator's identity identifier is often stored in the database as part of the target collaboration table's metadata during creation, so that this identity identifier can be used later to detect whether a user is the creator of the target collaboration table. Based on this, in this embodiment, the creation user identifier corresponding to the creator of the target collaboration table can be obtained from the target collaboration table's metadata.

[0097] For example, refer to Figure 16 The user identifier corresponding to the creator of the target collaboration table can be stored in the table information table of the target collaboration table. At this time, the creator user identifier can be obtained through the table information table of the target collaboration table.

[0098] In step 1702, the initiating user identifier is the user identity identifier corresponding to the user who initiated the permission request for the target collaborative table. It is understood that the target collaborative table, as a table requiring corresponding first-level operation permissions to access and edit, will carry the identity identifier of the user initiating the request in the corresponding request whenever a user performs any operation on the target collaborative table. This allows the server of the target collaborative table to determine which user initiated the request and whether that user has the permission to perform the operation corresponding to the request. Based on this, in this embodiment, when a copy creation request for the target collaborative table is received, the copy creation request can be parsed to obtain the initiating user identifier corresponding to the user who initiated the copy creation operation.

[0099] In step 1703, the permission request refers to a request used to request permission from the creator of the target collaboration form to initiate the user's creation of a copy of the target collaboration form. The permission request carries the identity identifier of the user initiating the request, i.e., the initiating user identifier. Specifically, referring to the figure, the interface of the target collaboration form contains an option to create a copy of the form. The user can initiate a copy creation request by clicking the option to create a copy of the form on this interface.

[0100] It is understandable that users other than the creator of the target collaboration form may also need to create copies of the target form. However, if any user can freely create copies of the target collaboration form, it could easily lead to the leakage of information entered in the target collaboration form. Therefore, in this embodiment, in response to a copy creation request, the system parses the request to obtain the initiating user identifier and checks whether the initiating user identifier matches the creator user identifier of the target collaboration form. When the initiating user identifier and the creator user identifier do not match, it indicates that the user who needs to create a copy of the form is not the same user as the user who created the target collaboration form. In this case, a permission request is sent to the creator user of the target collaboration form so that the creator user can be aware that the initiating user needs to create a copy of the target collaboration form and determine whether to allow the initiating user to create the copy.

[0101] In step 1704, the permission response is the response information from the first user authorizing the second user to create a corresponding copy of the target collaborative table. It can be understood that after sending the permission request to the creating user, the system checks whether a permission response has been received from the first user. If no such response is received, it indicates that the creating user of the target collaborative table has not authorized the initiating user to create the corresponding copy, and in this case, copy creation is not performed. If a permission response is received from the creating user, the creating user authorizes the initiating user to create the corresponding copy, and then the corresponding copy is generated based on the target collaborative table. Specifically, the system first creates an empty copy of the table, then copies the metadata of the target collaborative table from the database storing its metadata, and associates the copied metadata with the created empty copy, thus obtaining the copy of the target collaborative table.

[0102] In the embodiments disclosed in steps 1701 to 1704, when a copy creation request is received, it is checked whether the initiating user identifier of the copy creation request is consistent with the creating user identifier of the target collaborative table. If they are inconsistent, a permission request needs to be sent to the creating user. After receiving the permission response returned by the creating user, the copy creation is then performed. This ensures that other users besides the creating user of the target collaborative table need to obtain permission from the creating user before generating a copy of the target collaborative table, thus avoiding information security risks caused by users arbitrarily creating copies of the target collaborative table, which could lead to the leakage of information in the target collaborative table.

[0103] In one embodiment, the user initiating the copy creation request and the administrator user of the target collaborative table may not be the same user. Furthermore, the administrator user may, for various reasons, set a region comprised of certain cells in the target collaborative table as an area that the initiating user does not have permission to view. However, the initiating user, as the creator of the target collaborative table copy, is actually the administrator user of the target collaborative table copy and has permission to view and edit any cell in the target collaborative table copy. In this case, if all the data in all cells of the target collaborative table is copied to the target collaborative table copy, the initiating user may be able to view data in areas that they cannot see in the original target collaborative table through the target collaborative table copy, potentially causing data leakage. Therefore, in one embodiment, referring to… Figure 18 Step 403 includes: Step 1801: Determine the user who initiated the replica creation request; Step 1802: Determine the initiating user permission entry that matches the initiating user from the first permission storage table; Step 1803: Based on the initiating user's permission entries, determine the blocked areas in the target collaboration table that the initiating user does not have permission to view; Step 1804: Copy the metadata of the target collaboration table to obtain a metadata copy, and remove the data corresponding to the cells in the masked area from the metadata copy; Step 1805: Generate a copy of the target collaboration table based on the metadata copy.

[0104] In step 1801, details regarding the initiating user can be found in the relevant descriptions in steps 1702 and 1703 above, and will not be repeated here.

[0105] In step 1802, the initiating user, as one of the users who can access the target collaboration table, also needs to set the initiating user as the first-permission user in the first permission entry when setting permissions for the target collaboration table's administrator user. This is to determine the initiating user's first operation permission for each area within the table. Each first permission entry is filled with the corresponding user identity identifier of the first-permission user. Based on this, in this embodiment, all first permission entries with the initiating user as the first-permission user can be found in the first permission storage table according to the user identity identifier corresponding to the initiating user, and used as the corresponding initiating user permission entries. For example, refer to... Figure 19 After parsing the copy creation request, the user identity identifier corresponding to the initiating user is obtained as UID_1100. Then, based on this user identity identifier, the first permission storage table is searched to obtain the permission entry of the initiating user.

[0106] In step 1803, referring to the description in step 401, when the administrator user of the target collaboration table sets permissions, if a certain part of the cells is designated as a table area, then all users who can access the target collaboration table need to be configured with operation permissions for that table area. Based on this, for each table area in the target collaboration table, there will be a first permission entry that includes the initiating user among the first permission users; that is, the initiating user permission entry will contain the initiating user's first operation permission for each table area in the target collaboration table. At this point, by checking the first operation permissions in each initiating user permission entry, all corresponding initiating user permission entries with "cannot be viewed" as their first operation permission are found, and based on the table areas in these initiating user permission entries, the blocked areas can be obtained.

[0107] For example, if a user's permission entry has a table area called area A, and the first permission is the inability to view the content, then area A is part of the blocked area.

[0108] It should be noted that if the initiating user is the administrator user of the target collaboration table, since the administrator user of the target collaboration table has the permission to view and edit all cells of the target collaboration table, the shielded area is an empty set.

[0109] In step 1804, the metadata of the target collaboration table is copied. For details on obtaining a copy of the metadata, please refer to the relevant descriptions in steps 1501 to 1502 above, which will not be repeated here.

[0110] After obtaining the metadata copy, it will contain metadata corresponding to the shielded area, such as the content entered in the cells within the shielded area. This data is not accessible to the initiating user in the target collaboration table. However, since the initiating user acts as the administrator of the target collaboration table copy after its creation, they have permission to view and edit all cells in the target collaboration table copy. If this metadata corresponding to the shielded area is also copied to the target collaboration table copy, the initiating user can then view the data entered in the cells within the shielded area, leading to data leakage. Therefore, in this embodiment, after obtaining the metadata copy, the data corresponding to the cells within the shielded area is removed from the metadata copy.

[0111] Specifically, the blocked area is a region consisting of several table areas that the initiating user does not have permission to view. As shown in step 401, each initiating user permission entry is filled with the corresponding area information of the table area. This area information can be the cell identifier corresponding to the cell in the table area, or the row identifier and column identifier corresponding to the row and column where these cells are located. As shown in step 1501, based on these cell identifiers, row identifiers, and column identifiers, the metadata that needs to be removed and corresponds to the blocked area can be found from the metadata of the target collaborative table.

[0112] For example, refer to Figure 19 The masked area is the nth column of the target collaboration table. In this case, the corresponding user permission entry for the initiating user is filled with the column identifier of the nth column of the target collaboration table, designated as `columns_n`. Since each cell is associated with its corresponding column information table by filling in the preset column identifier field, searching the cell information table for all cells whose column identifier field is filled with the column identifier of the nth column will yield the cells from which the corresponding data needs to be removed. Then, the content in these cells is cleared. For example, refer to... Figure 19 The two cells, cell_1011 and cell_1012, are filled with contents A and B respectively. These two cells are associated with column_n, meaning they are cells in the masked area. Based on this, the contents filled in these two cells are cleared in the cell information table copy of the element copy.

[0113] In this way, the target collaboration table copy obtained subsequently based on the masked metadata copy will not carry the data of the cells in the masked area, thereby preventing the initiating user from viewing data that they do not have permission to view in the target collaboration table through the target collaboration table copy, and ensuring that no data leakage or data security issues will occur during the creation of the target collaboration table copy.

[0114] In step 1805, the details of generating a target collaboration table copy based on the metadata copy can be found in the relevant descriptions of steps 1503 and 1504 above, and will not be repeated here.

[0115] In the embodiments disclosed in steps 1801 to 1805, when creating a copy of the target collaboration table, all first permission entries with the initiating user as the first permission user are first searched in the first permission storage table, and these first permission entries are identified as initiating user permission entries. Then, based on each initiating user permission entry, a shielded area is determined, which is the area within the table that the initiating user cannot view in the target collaboration table. Subsequently, during the process of generating a copy of the target collaboration table by copying the metadata of the target collaboration table, data corresponding to cells in the shielded area is removed from the copied metadata to avoid copying the data of cells in the shielded area to the target collaboration table copy. This prevents the initiating user from viewing data that they do not have permission to view in the target collaboration table through the target collaboration table copy, ensuring that no data leakage or data security issues occur during the creation of the target collaboration table copy.

[0116] Detailed description of steps 404 and 405 In step 404, a second permission storage table associated with the target collaboration table copy is generated based on the first permission storage table.

[0117] In step 405, in response to the target user's operation request for the target area in the target collaborative table copy, a matching permission entry is determined among a plurality of second permission entries.

[0118] It should be noted that step 405 has been described in detail above, but some embodiments of step 405 are related to some embodiments of step 404. Therefore, steps 404 and 405 will be described in detail together.

[0119] In one embodiment, when a user initiates a copy creation request, they are actually creating a new collaboration table (i.e., a copy of the target collaboration table) and using this copy to complete a different task than the one performed using the target collaboration table. For example, when the target collaboration table is used in a collaborative work scenario, task A corresponding to the target collaboration table might be completed collaboratively by users 1 through 8, who all have the permission to edit the target collaboration table. The copy of the target collaboration table is created for task B, which is completed by users 5 through 10, and users 5 through 10 participate in editing the copy. In this case, the users who participate in editing the copy are different from the users who edit the target collaboration table. Therefore, in one embodiment, the user initiating the copy creation request can specify the user who can access the target collaboration table copy when initiating the request. Specifically, when the initiating user clicks the "Create a copy of the table" option in the target collaboration table's interface, a pop-up window will appear displaying a list of candidate collaborators. This list includes users from the second user group using the target collaboration table. The initiating user can select users from this list to add to the first user group. Simultaneously, the pop-up window also includes an option to add collaborators. The initiating user can click this option to add users outside the second user group as collaborators who can access the target collaboration table copy. After selecting the users to add to the first user group, the initiating user can click the "OK" option to generate the corresponding copy creation request.

[0120] Therefore, in this embodiment, the copy creation request carries a first user group consisting of collaborating users who can access the target collaboration table copy, and this first user group is different from the second user group participating in editing the target collaboration table. It should be noted that this difference can mean that the users included in the second user group are partially the same as those in the first user group, and partially different. For example, the second user group includes not only all the users in the first user group, but also additionally added users; or the second user group only includes some of the users in the first user group; or the users in the first user group consist of some of the users in the second user group and several additionally added users who do not exist in the second user group.

[0121] Specifically, the first user group can be a user table temporarily stored in the database. The user table includes user identity entries corresponding to each collaborating user. The user table can also include a table identity entry, which is filled with a second identity corresponding to the target collaborative table copy, thereby associating the collaborating users in the user table with the target collaborative table copy.

[0122] At this time, refer to Figure 20Step 404 includes: Step 2001: Identify users who are in the second user group but not in the first user group who have reduced their usage. Step 2002: Identify the incremental users who are in the first user group but not in the second user group; Step 2003: Copy multiple first-permission entries to obtain multiple copies of first-permission entries, and delete the reduced users from the first-permission users in the multiple copies of first-permission entries; Step 2004: In the second user group, identify the matching user that matches the incremental user; Step 2005: If the first permission user in the first permission entry copy contains a matching user, add the incremental user to the first permission user in the first permission entry copy to obtain the second permission entry, and associate the second permission entry with the target collaboration table copy to obtain the second permission storage table.

[0123] In step 2001, the reduced user is a user who can access the target collaboration table and has corresponding first operation permissions for some areas within the target collaboration table, but cannot access the copy of the target collaboration table, and cannot view or edit any cell in the copy of the target collaboration table.

[0124] Specifically, in this embodiment, for each user in the second user group, it can be detected whether there is a user with the same user identity in the first user group. If there is no user with the same user identity in the first user group, it indicates that the user is a user whose usage has been reduced.

[0125] For example, if users 1 to 8 can access the target collaboration table, then the second user group corresponding to the target collaboration table includes users 1 to 8; while the copy of the target collaboration table is only accessible to users 5 to 10, and users 1 to 4 cannot access the copy of the target collaboration table. At this time, the first user group only includes users 5 to 10. In this case, it is impossible to detect users with the same user identity as users 1 to 4 in the first user group, so users 1 to 4 can be identified as reduced users.

[0126] In step 2002, an incremental user is a user who cannot access the target collaboration table but can access a copy of the target collaboration table. Referring to step 2001, in this embodiment, for each user in the first user group, it can be detected whether there is a user with the same user identity in the second user group. If not, the user is identified as an incremental user.

[0127] In step 2003, multiple first permission entries contained in the first permission storage table are first copied in the database to obtain multiple copies of the first permission entries. In this way, the second permission storage table can be generated by operating on the multiple copies of the first permission entries, without having to directly operate on the multiple first permission entries. This avoids modifying the first permission storage table during the generation of the second permission storage table, which would cause changes to the permissions set in the target collaboration table.

[0128] After obtaining multiple copies of the first permission entries, the reduced user is a user who does not exist in the first user group, meaning the user who initiated the copy creation request does not allow the reduced user to view or edit the target collaboration table copy. However, the reduced user is a user in the second user group, meaning there are first permission entries corresponding to the reduced user among the multiple first permission entries. When generating the second permission storage table associated with the target collaboration table copy based on the first permission entries, retaining the reduced user in each permission entry would result in the reduced user having permission to operate the target collaboration table copy, which conflicts with the first user group in the copy creation request. Therefore, in this embodiment, each reduced user is deleted from the multiple copies of the first permission entries; specifically, the user identity identifier corresponding to each reduced user is deleted from the user identity identifier field in the first permission entry copies.

[0129] In step 2004, a matching user refers to a user in the second user group whose user attributes are highly similar to those of the incremental user.

[0130] It is understandable that the incremental user does not exist in the second user group, meaning the incremental user does not have permission to operate on the target collaboration table. Among the multiple first permission entries, there is no first permission entry where the incremental user is the first permission user. However, as a user in the first user group, the incremental user needs permission to operate on certain areas of the target collaboration table copy. When generating the second permission storage table corresponding to the target collaboration table copy, the incremental user needs to be set as the second permission user corresponding to certain second permission entries. When setting the corresponding permissions for these incremental users, it is desirable to ensure that two similar users have the same permissions. Here, similarity refers to a high degree of similarity between the two users in multiple aspects of their user attributes. Specifically, in this embodiment, the similarity between the incremental user and each user in the second user group in multiple preset aspects can be calculated to determine whether there is a matching user in the second user group that matches the incremental user. The detailed process of step 2004 will be explained later and will not be repeated here.

[0131] In step 2005, since the incremental user and the corresponding matching user are users with high similarity in multiple user attributes, and users with the same user attributes often have the same operation permissions for the same area within the collaborative table, for example, in a collaborative office scenario, two users with the same job attribute are often two users with the same responsibilities. When working collaboratively, the tasks assigned to these two users are also similar, and the areas they can view and edit in the collaborative table are often interconnected. That is, in a collaborative table used for collaborative office work, they often have the same first operation permission for the same area within the table. Based on this, in this embodiment, when there is a matching user in the second user group that matches the incremental user, it is detected whether the first permission users in each first permission entry copy include the matching user that matches the incremental user. If so, the incremental user is added to the first permission users in the corresponding first permission entry copy, so that the incremental user and the corresponding matching user can have the same operation permission for the same area within the table. Thus, the incremental user is set as the second permission user corresponding to the area within the table in the target collaborative table copy, and the second operation permission corresponding to the incremental user is determined, resulting in the second permission entry. In this way, when creating a copy of the target collaboration table, the corresponding permissions can be automatically set for each incremental user, without the user who initiated the copy creation request having to manually set the permissions related to the incremental users in the target collaboration table copy, thus improving the efficiency of setting permissions for the target collaboration table copy.

[0132] The method for associating the second permission entry with the target collaboration table copy can be referred to the relevant description in step 404 above, and will not be repeated here.

[0133] In the embodiments disclosed in steps 2001 to 2005, when creating a copy of the target collaborative table, if the first user group consisting of the collaborative users selected by the user initiating the copy creation request to participate in editing the target collaborative table copy is different from the second user group consisting of the various first-permission users, the reduced users and increased users in the first user group relative to the second user group are first determined; then, multiple first-permission entries corresponding to the target collaborative table are copied, and the reduced users are removed from the copied copies of the first-permission entries, thereby avoiding setting operation permissions for the reduced users on the table areas in the target collaborative table copy. Simultaneously, matching users with a high degree of similarity to the increased users are matched from the second user group, and the increased users are added to the first-permission entry copy with the corresponding matching users as first-permission users, obtaining second-permission entries, and associating the obtained second-permission entries with the target collaborative table copy. In this way, when the increased users operate on the various table areas in the target collaborative table copy, they can have the same operation permissions as the more similar matching users. Based on this, when creating a copy of the target collaboration table, a second permission storage table can be automatically generated based on the first permission storage table corresponding to the target collaboration table, without requiring the user initiating the copy creation request to manually set permissions in the target collaboration table copy, thus improving the efficiency of setting permissions for the target collaboration table copy.

[0134] In one embodiment, refer to Figure 21 Step 2004 includes: Step 2101: Determine the first attribute parameter of multiple attributes for incremental users; Step 2102: For each user in the second user group, determine the second attribute parameters of multiple attributes of the user; Step 2103: For each attribute, determine the attribute matching degree between the second attribute parameter of each user in the second user group and the first attribute parameter of the incremental user; Step 2104: Based on the attribute matching degree corresponding to multiple attributes, determine the user matching degree between each user in the second user group and the incremental user; Step 2105: Based on user matching degree, determine the matching users among the users in the second user group.

[0135] In step 2101, the multiple attributes refer to attribute items used to characterize user information. These attributes can be preset, such as the user's education level, years of work experience, hobbies, industry, groups the user belongs to, and historical collaboration forms edited by the user. Note that user consent must be obtained before collecting these attributes. This information must not be collected from the user without their consent.

[0136] The first attribute parameters are the actual parameters of the incremental user for each preset attribute, such as the incremental user's actual education level, years of work experience, hobbies, industry, groups the incremental user belongs to, and the historical collaborative forms the incremental user has edited. The first attribute parameters corresponding to each attribute of the incremental user can be filled in by the incremental user themselves, or automatically generated based on the incremental user's actual usage during the application or webpage of the collaborative forms; for example, attributes such as education level, years of work experience, industry, and hobbies can be filled in by the user when registering an account for the collaborative forms application or webpage; attribute information such as the user's groups and the historical collaborative forms the user has edited can be generated based on the user's behavior during the use of the collaborative forms application or webpage. Note that the user's consent must be obtained before collecting this information. This information must not be collected from the user without their consent.

[0137] Each user's attribute parameters for each attribute can be stored in a user database. Based on this, in this embodiment, the first attribute parameters corresponding to each attribute of the incremental user can be retrieved from the user database according to the incremental user's user identity identifier.

[0138] In step 2102, the description of the second attribute parameter can refer to the description of the first attribute parameter in step 2101, and will not be repeated here. In this embodiment, the second attribute parameter of each corresponding attribute can be retrieved from the user database based on the user identity identifier of each user in the second user group.

[0139] In step 2103, after obtaining the first attribute parameters of the incremental user and the second attribute parameters of each user in the second user group, the attribute matching degree between the incremental user and the users in the second user group can be calculated based on the first attribute parameters and the second attribute parameters.

[0140] For different attributes, the calculation methods for attribute matching degree vary depending on the data type of the corresponding attribute parameters. In this embodiment, for each attribute, a corresponding attribute matching degree calculation method can be preset according to the data type of the corresponding attribute parameters. For example, for attributes such as historical collaboration tables edited by the user and the work group the user belongs to, the corresponding attribute parameters are a set composed of the table identity identifiers of the historical collaboration tables edited by the user or the work group identity identifiers of the user's work group. The corresponding attribute matching degree can be determined by calculating the repetition ratio of the elements in the set. For attributes such as years of work experience, the corresponding attribute parameters are numerical parameters. In this case, the corresponding attribute matching degree can be determined by directly calculating the relative size, such as calculating the standard deviation, variance, ratio, etc. For attributes such as education level, a score that is positively correlated with different education levels can be preset, and then the corresponding score ratio can be calculated as the attribute matching degree. For attributes such as the user's industry, a matching degree coefficient table between different industries can be pre-established. Then, based on the industry of the incremental user and the industry of the users in the second user group, the corresponding attribute matching degree can be found in the matching degree coefficient table. It should be noted that the range of attribute values ​​remains consistent when calculating attribute matching degree for different attributes. For example, for attributes with numerical parameters, when calculating the ratio of the first and second attribute parameters as the attribute matching degree, the larger value is used as the denominator and the smaller value as the numerator by default to ensure that the final attribute matching degree is within the range of 0 to 1. When calculating attribute matching degree by calculating standard deviation or variance, the corresponding scaling factor can be pre-set according to the actual calculation method to scale the calculation result. For example, the difference between the years of service of two users is generally no greater than 45. Therefore, if the attribute matching degree is calculated by using the standard deviation of the years of service of users, the difference between the years of service of two users needs to be divided by 45 to obtain the corresponding attribute matching degree.

[0141] In step 2104, for incremental users, after obtaining the attribute matching degree corresponding to multiple attributes of each user in the second user group, the user matching degree between the incremental user and each user in the second user group can be determined by weighted summation of the attribute matching degree or by calculating the arithmetic mean or geometric mean of multiple attribute matching degrees.

[0142] In step 2105, after obtaining the user matching degree between the incremental user and each user in the second user group, the user with the highest user matching degree with the incremental user is determined as the matching user corresponding to the incremental user.

[0143] Furthermore, in one embodiment, a matching threshold may be preset. A user in the second user group is identified as a matched user of the incremental user only if the user matching degree between the incremental user and the incremental user is greater than the matching threshold. If the maximum user matching degree between the incremental user and the users in the second user group is less than the preset matching threshold, it is considered that there are no matched users of the incremental user in the second user group.

[0144] In the embodiments disclosed in steps 2101 to 2105, the similarity between the incremental user and each user in the second user group in multiple aspects is determined by calculating the attribute matching degree of multiple attributes of each user in the incremental user and the second user group. Then, based on the attribute matching degree of multiple attributes, the user matching degree between the incremental user and each user in the second user group is determined, and the matching user of the incremental user is determined from the users of the second user group according to the user matching degree. In this way, the user with the highest similarity to the incremental user is determined as the corresponding matching user, and subsequently, the incremental user can have the same operation permissions as the most similar user.

[0145] In one embodiment, refer to Figure 22 Step 2104 includes: Step 2201: Obtain the attribute weights of each of the multiple attributes; Step 2202: Based on the attribute weights, calculate the weighted average of the attribute matching degrees corresponding to multiple attributes to obtain the user matching degree.

[0146] In step 2201, the attribute weight is a weighting coefficient applied to each attribute when calculating the matching degree between users based on their various attributes. In this embodiment, the attribute weight corresponding to each attribute can be a preset value. For example, an attribute weight table can be preset, and the attribute weight corresponding to each attribute can be determined by looking up the attribute weight table.

[0147] In another embodiment, different attributes can be preset with different weights for different use cases. For example, in a collaborative office scenario, the areas that multiple users in the same role can view and edit should be relatively close, while the areas that users in different roles can view and edit are often different. For instance, data entered in some areas of the target collaborative spreadsheet can only be viewed by users in management roles, while users in non-management roles cannot view it. In this case, users with the same role attribute should have similar operation permissions for different areas within the target collaborative spreadsheet. Therefore, in a collaborative office scenario, the user's role attribute can be set with a higher attribute weight. In non-office scenarios, whether a user has the same role often does not affect the area that the user can view and edit in the spreadsheet. Therefore, in a non-collaborative office scenario, the user's role attribute can be set with a relatively lower attribute weight. Specifically, multiple attribute weight tables can be preset for common scenarios of collaborative spreadsheets, and then the corresponding attribute weight table can be selected according to the user's chosen use case to determine the corresponding attribute weight.

[0148] As described above, when actually calculating the matching degree between users, the importance of attribute matching degree to user matching degree varies for different attributes. However, the attribute matching degree corresponding to each attribute is calculated independently; that is, when calculating the matching degree of each attribute, the importance of all attribute matching degrees to user matching degree is considered to be the same. Based on this, in this embodiment, preset attribute weights for each attribute are obtained so that when calculating user matching degree based on attribute matching degree subsequently, the attribute matching degree of each attribute is weighted according to the attribute weights.

[0149] In step 2202, after determining the attribute weights corresponding to each attribute, the corresponding attribute matching degree is weighted and summed according to the attribute weights of each attribute, and the result of the weighted sum is used as the user matching degree. In this way, the user matching degree can more accurately reflect the probability that the incremental user has similar operation permissions to each user in the second user group.

[0150] In the embodiments disclosed in steps 2201 and 2202, by obtaining the attribute weights corresponding to each attribute, and when calculating the user matching degree based on the attribute matching degree of each attribute, the attribute matching degrees of each attribute are weighted using the attribute weights before summing. In this way, when calculating the user matching degree, some relatively important attributes can be highlighted, avoiding the attribute matching degrees of some less important attributes from having an excessive impact on the user matching degree.

[0151] In another possible embodiment, when the user initiating the copy creation request specifies a second user group that can view and edit the target collaborative table copy, this indicates that the division of the various table areas in the target collaborative table and the permission setting templates for each table area (i.e., the operation permissions of a single user on multiple different table areas, and the operation permissions of multiple users on a single table area) meet the needs of the initiating user. However, if the second user group is different from the first user group, it indicates that for the initiating user, the first permission user in each permission entry set for each table area of ​​the target collaborative table copy is not entirely the same as the second permission user in the corresponding permission entry for that table area in the target collaborative table; some permission entries require changes to the corresponding permission users. In this case, refer to... Figure 23 In one embodiment, step 404 includes: Step 2301: Display the permission migration list. The permission migration list includes a column for users whose permissions are to be migrated and a column for users whose permissions are to be received. The column for users whose permissions are to be migrated includes users in the second user group, and the column for users whose permissions are to be received includes users in the first user group. Step 2302: In response to the permission migration operation of the initiating user on the permission migration list in response to the copy creation request, determine the permission mapping relationship between the users in the first user group whose permissions are to be received and the users in the second user group whose permissions are to be migrated. Step 2303: Copy multiple first-permission entries to obtain multiple copies of the first-permission entries; Step 2304: If the first permission user in the first permission entry copy is a permission to be migrated user, based on the permission mapping relationship, change the first permission user in the first permission entry copy from the permission to be migrated user to the corresponding permission to receive user, obtain multiple second permission entries, and associate the second permission entries with the target collaboration table copy to obtain the second permission storage table.

[0152] In step 2301, the permission migration list is a list used to represent the permission migration relationship between users in the first user group and users in the second user group. The permission migration list includes a permission to be migrated user column and a permission to receive user column. The permission to be migrated user column is a list of users who have the corresponding first operation permissions for each area in the target collaborative table, that is, a list of users in the second user group. The permission to receive user column is a list of users who need to have the corresponding second operation permissions for each area in the target collaborative table copy, that is, a list of users in the first user group.

[0153] In step 2302, after the permission migration list is displayed on the interface, the user initiating the copy creation request can operate on the interface to establish a permission mapping relationship between users in the second user group and users in the first user group according to the actual needs of the initiating user. For example, refer to... Figure 24 The initiating user can connect users in the "Users to be Migrated for Permissions" column and users in the "Users to be Receiving Permissions" column via lines in the interface, thereby establishing the corresponding permission mapping relationship. For example, in Figure 24 In this process, permission mapping relationships were established between User 1 and User 4, User 2 and User 8, and User 3 and User 10.

[0154] The permission mapping relationship indicates that the second operation permissions that the user to be granted permissions has over each table area in the target collaborative table copy are consistent with the first operation permissions that the user to be migrated has over each table area in the target collaborative table. For example, if the user to be migrated can view and edit the data in column n of the target collaborative table, then the user to be granted permissions should also be able to view and edit the data in column n of the target collaborative table copy. Specifically, the permission mapping relationship may include the user identity identifier of the user to be migrated and the corresponding user identity identifier of the user to be granted permissions.

[0155] Furthermore, it is understandable that users in the first user group and users in the second user group may be partially the same. In this case, for partial permission mapping relationships, the user whose permissions are to be migrated and the corresponding user whose permissions are to be received may be the same user.

[0156] In step 2303, the details of generating a copy of the first permission entry can be found in the relevant description of step 2003 above, and will not be repeated here.

[0157] In step 2304, if the first permission user in the first permission entry copy is the permission to be migrated user, this indicates that in the target collaboration table, the permission to be migrated user has the operation permission specified by the first permission entry copy for the table area specified in the first permission entry copy; at this time, the corresponding permission to receive user also needs to have the operation permission specified by the first permission entry copy for the table area corresponding to the first permission entry copy in the target collaboration table copy.

[0158] Therefore, in this embodiment, if the first permission user in a copy of a first permission entry is a user whose permissions are to be migrated, the first permission user in that copy of the first permission entry is changed from the user whose permissions are to be migrated to the corresponding user whose permissions are to be received. Thus, the permissions that the user whose permissions are to be migrated has for each area in the target collaboration table can be copied to the user whose permissions are to be received and applied to the created copy of the target collaboration table. This allows for the change of the user corresponding to each permission entry while keeping the permission setting template in the target collaboration table unchanged.

[0159] Specifically, the first permission entry copy contains a user identity identifier field. In this embodiment, when a user identity identifier field in a first permission entry copy is filled with the user identity identifier corresponding to the user whose permissions are to be migrated, the content filled in the user identity identifier field of that first permission entry copy is changed from the user identity identifier corresponding to the user whose permissions are to be migrated to the user identity identifier corresponding to the user whose permissions are to be received, thus obtaining the corresponding second permission entry. Details on associating the second permission entry with the target collaboration table copy can be found in the relevant description of step 404 above, and will not be repeated here.

[0160] In the embodiments disclosed in steps 2301 to 2304, a permission migration list is displayed on the interface, and the user initiating the copy creation request determines the permission mapping relationship between users in the first user group and users in the second user group. Then, each first permission entry of the target collaboration table is copied, and the permission users in each first permission entry copy are modified according to the permission mapping relationship set by the initiating user. This ensures that the permission settings of the target collaboration table copy are consistent with the permission settings of the target collaboration table, and these permission settings are applied to the first user group specified by the initiating user. Therefore, users only need to set the permission mapping relationship to automatically apply the permission setting template from the target collaboration table to the target collaboration table copy and adapt it to the user group specified by the user to participate in editing the target collaboration table copy, without the need for cumbersome permission settings, thus improving the efficiency of setting permissions for the target collaboration table copy.

[0161] In one embodiment, refer to Figure 25 Step 2301 includes: Step 2501: Identify users who are in the second user group but not in the first user group who have reduced their usage. Step 2502: Identify the incremental users who are in the first user group but not in the second user group; Step 2503: Determine the users to be reduced as users in the permission migration column, and determine the users to be increased as users in the permission receiving column. Based on the permission migration column and the permission receiving column, display the permission migration list.

[0162] Specifically, the methods for determining the number of users to be reduced and the number of users to be increased in steps 2501 and 2502 can be referred to the relevant descriptions of steps 2001 and 2002 above, and will not be repeated here.

[0163] In step 2503, it can be understood that when a user is simultaneously in both the first user group and the second user group, it means that the user can view and edit both the target collaboration table and its copy. This user often has the same operational permissions in both the target collaboration table and its copy. Therefore, in the process of generating the second permission storage table based on the first permission storage table, for these users, the corresponding first permission entry can be directly copied to obtain the corresponding second permission entry without additional permission migration processing. However, incremental users, as users not existing in the second user group, do not have a first permission entry in the first permission storage table with the incremental user as the first permission user; correspondingly, although a first permission entry exists in the first permission storage table with the decremented user as the first permission user, Based on this, in this embodiment, users who are reduced in number are identified as users whose permissions are to be migrated, and users who are increased in number are identified as users whose permissions are to be received. A permission migration list is generated and displayed accordingly. In this way, the user who initiates the copy creation request only needs to determine the permission migration relationship between the reduced users and the increased users, without having to set the permission mapping relationship between each user in the second user group and the first user group. This reduces the cumbersome operation for the user who initiates the copy creation request and improves the efficiency of setting permissions for the target collaborative table copy.

[0164] In the embodiments disclosed in steps 2501 to 2503, by determining the decrementing users and incremental users in the first user group and the second user group, non-overlapping users in the first user group and the second user group are obtained, and the decrementing users and incremental users are respectively designated as users whose permissions are to be migrated and users whose permissions are to be received. In this way, the user initiating the subsequent copy creation request only needs to set the permission mapping relationship between these decrementing users and incremental users, without having to reset the permission mapping relationship for each user in the first user group and the second user group. This reduces the operational complexity for the user initiating the copy creation request and improves the efficiency of setting permissions for the target collaborative table copy.

[0165] In one embodiment, refer to Figure 26 Step 404 also includes: Step 2601: Obtain the first number of the first permission entries; Step 2602, the first use case for obtaining a copy of the target collaboration table; Step 2603: If the first number satisfies the first condition, or the first use case satisfies the second condition, generate a second permission storage table associated with the target collaboration table copy based on the first permission storage table.

[0166] In step 2601, the first number is the total number of first permission entries associated with the target collaboration table. It represents the number of permission setting operations required to perform permission settings consistent with those of the target collaboration table copy on the target collaboration table copy. For example, if the first number is 100, that is, if there are 100 permission entries in the target collaboration table, the administrator user needs to perform 100 permission setting operations to perform permission settings consistent with those of the target collaboration table copy on the target collaboration table copy. Similarly, if the first number is 5, then the administrator user only needs to perform 5 permission setting operations to perform permission settings consistent with those of the target collaboration table copy on the target collaboration table copy.

[0167] Specifically, in the database used to store the first permission entries, all first permission entries associated with the target collaboration table can be found based on the first identifier corresponding to the target collaboration table, thereby determining the first number.

[0168] In one implementation, all first-permission entries are organized into a separate first-permission storage table and stored in the database. This first-permission storage table includes a table identity field that links to the target collaborative table. This table identity field is filled with the table identity corresponding to the target collaborative table, i.e., the first identifier. In this case, the first-permission storage table can be located in the database based on the first identifier, and the first number can be determined based on the total number of permission entries in the first-permission storage table.

[0169] In another possible implementation, the first permission entry is stored in a permission storage table along with permission entries from other collaborative tables. Each permission entry has its own table identity field, which is used to populate the table identity of the collaborative table associated with the permission entry. It's easy to understand that the permission entry whose table identity field is filled with the first identifier of the target collaborative table is the first permission entry. In this case, the permission storage table can be searched based on the first identifier corresponding to the target collaborative table; the number of permission entries retrieved is the first number.

[0170] In step 2602, the first use case refers to the use case when using a copy of the target collaborative table. It can be one of several preset use cases, which may include: collaborative work, information aggregation, data backup, data analysis, etc.

[0171] Understandably, the probability of a user migrating table permissions when creating a copy of a table varies depending on the use case. For example, in some scenarios, the target collaboration table is used to periodically summarize data from the same group of users, such as daily or weekly reports in an office setting. In these cases, the users participating in filling out the collaboration table are relatively fixed, and the content each user needs to fill in is also relatively fixed. In these scenarios, users often create a copy of the target collaboration table for the next period's data summary, and therefore, it is often necessary for the created copy of the target collaboration table to have the same permission settings as the original target collaboration table.

[0172] In other scenarios, users may not need to ensure that the created copy of the target collaboration table has the same permission settings as the original target collaboration table. For example, after aggregating data entered by multiple users using the target collaboration table, users may need to merge or otherwise process this data. In this case, to avoid damaging the original data aggregated in the target collaboration table, the user will initiate a copy creation request to generate a corresponding copy of the target collaboration table and process the data in each cell within the copy. In this scenario, it is unnecessary to copy the permissions set in the target collaboration table to the copy. If a second permission storage table were generated based on the first permission storage table at this time, it would result in a waste of database storage resources.

[0173] Specifically, when a user initiates a copy creation request, a pop-up window can be displayed on the interface to ask the user the purpose of creating the target collaborative table copy, and several preset use cases can be displayed on the interface, allowing the user to select one of the use cases as the first use case for the target collaborative table copy.

[0174] In step 2603, the first condition is used to determine whether it is necessary to copy the permissions set in the target collaboration table to the target collaboration table copy based on the first number. The first condition may be to determine whether the first number is greater than a preset first number threshold. The second condition is used to determine whether it is necessary to copy the permissions set in the target collaboration table to the target collaboration table copy based on the first use case. The second condition may be to determine whether the first use case is the first of the preset permission copying scenarios. The permission copying scenario refers to the use case where it is necessary to keep the permissions set in the created target collaboration table copy consistent with the permissions set in the target collaboration table.

[0175] Specifically, when the first number is greater than the preset first number threshold, it indicates that the total number of first permission entries is large. That is, when performing permission settings on the target collaboration table copy that are consistent with the target collaboration table, the number of permission setting operations required is more, and the permission setting operations are more cumbersome. In this case, it is considered that the first number meets the first condition, and a second permission storage table is generated based on the first permission storage table, and the permissions set in the target collaboration table are copied to the target collaboration table copy. Conversely, if the first number is not greater than the first number threshold, it is relatively simple for the user to manually set permissions on the target collaboration table copy, and there is no need to generate a second permission storage table based on the first permission storage table.

[0176] Meanwhile, in this embodiment, several permission copying scenarios can be preset, requiring the permissions set in the created target collaboration table copy to be consistent with the permissions set in the target collaboration table. At this time, it is checked whether the first usage scenario is one of the preset permission copying scenarios. If so, it is considered to meet the second condition, and a second permission storage table is generated based on the first permission storage table, copying the permissions set in the target collaboration table to the target collaboration table copy.

[0177] In the embodiments disclosed in steps 2601 to 2603, a first number of first permission entries and a first use case of the target collaboration table are obtained. Based on the first number and the first use case, it is determined whether the user needs to keep the permissions set in the target collaboration table copy consistent with the permissions set in the target collaboration table when creating a copy of the target collaboration table. If the first number is large, or the first use case belongs to a preset permission copying scenario, it indicates that the user is likely to need to keep the permissions set in the target collaboration table copy consistent with the permissions set in the target collaboration table, and the operation required by the user at this time is relatively cumbersome. Therefore, a second permission storage table is generated based on the first permission storage table, thereby copying the permissions set in the target collaboration table to the target collaboration table copy without requiring the user to perform cumbersome permission settings.

[0178] In one embodiment, the first permission storage table includes a first permission storage table body and a first identifier of the target collaboration table, referred to as Figure 27 Step 404 includes: Step 2701: Copy the first permission storage table to obtain a copy of the first permission storage table; Step 2702: Remove the first identifier from the copy of the first permission storage table to obtain the original copy of the first permission storage table; Step 2703: Obtain the second identifier of the target collaboration table copy; Step 2704: Based on the first permission storage table ontology and the second identifier, generate a second permission storage table associated with the target collaboration table copy.

[0179] The first identifier refers to the table identity of the target collaborative table. It can be understood that the metadata of the target collaborative table is stored in a database on the server backend. This database stores metadata for multiple collaborative tables simultaneously. Based on this, each time a collaborative table is generated, the server assigns a corresponding table identity to it. This table identity can consist of a string or a set of numbers. It is understood that different collaborative tables have different table identities, and each collaborative table has a unique table identity.

[0180] In step 2701, the first permission storage table can be directly copied from the database to obtain a copy of the first permission storage table.

[0181] In step 2702, referring to the relevant description in step 402, the first permission storage table may include a table identity identifier field for filling the table identity identifier of the target collaboration table and a permission field for filling each first permission entry. Based on this, in this embodiment, the table identity identifier filled in the table identity identifier field of the first permission storage table can be cleared, and each first permission entry in the table can be retained to obtain the main body of the first permission storage table.

[0182] In another embodiment, the first permission entry itself has a table identity field. The table identity field of each first permission entry is filled with the first identifier of the target collaboration table, thereby associating the first permission entry with the target collaboration table. At this time, the first identifier in the table identity field of each first permission entry can be cleared, and the first permission storage table body can be obtained based on all first permission entries after clearing the first identifier.

[0183] It is understandable that, since the first permission storage table body no longer carries the first identifier used to associate with the target collaboration table, the first permission storage table body can be regarded as the permission storage table template required to create a collaboration table with the same permission settings as the target collaboration table.

[0184] In step 2703, the details regarding the second identifier can be referred to in step 1503 above, and will not be repeated here. In this embodiment, the table identity identifier corresponding to the target collaborative table copy can be obtained as the second identifier.

[0185] In step 2704, referring to the relevant description in step 2702, the first permission storage table body serves as a permission setting template. By associating the first permission storage table body with other collaborative tables, the associated collaborative tables can have the same permission settings as the target collaborative table. Based on this, in this embodiment, the second identifier, which serves as the table identity identifier of the target collaborative table copy, is filled into the first permission storage table body, thereby obtaining the second permission storage table associated with the target collaborative table copy.

[0186] In the embodiments disclosed in steps 2701 to 2704, a corresponding copy of the first permission storage table is obtained by copying the first permission entry in the first permission storage table. Then, the first identifier used to associate with the target collaborative table is removed from the copy of the first permission storage table, resulting in a first permission storage table body that can be regarded as the permission storage table template required to create a collaborative table with the same permission settings as the target collaborative table. Then, the second identifier is filled into the table identity identifier field in the first permission storage table body, so that the first permission storage table body is associated with the target collaborative table, resulting in a second permission storage table. Based on the second permission storage table, the area and operation type that each user can operate on when operating on the copy of the target collaborative table are restricted, thereby migrating each permission set in the target collaborative table to the copy of the target collaborative table without requiring the copy creator to re-set permissions for each item in the copy of the target collaborative table, thus improving the efficiency of setting permissions for the copy of the target collaborative table.

[0187] In one embodiment, refer to Figure 28 The operation request carries a target collaboration table copy identifier. Step 405 includes: Step 2801: Obtain the target collaboration table copy identifier from the operation request; Step 2802: Determine the second permission storage table that matches the second identifier with the target collaboration table copy identifier; Step 2803: Among the multiple second permission entries in the second permission storage table, determine the matching permission entry.

[0188] In step 2801, the target collaborative table copy identifier is the table identity identifier corresponding to the table copy that the target user needs to operate on. It is understood that in some cases, there may be multiple target collaborative table copies, each with its own corresponding second permission storage table, and each target collaborative table copy is assigned a unique table identity identifier as its corresponding second identifier. When an operation request is received, it is first necessary to determine which target collaborative table copy the target user currently needs to operate on. In this embodiment, since the operation request is generated based on the target user's operation on the interface of the target collaborative table copy, the operation request carries the table identity identifier corresponding to the target collaborative table copy operated on by the target user. By parsing the operation request, the table identity identifier operated on by the target user can be extracted, thus obtaining the target collaborative table copy identifier.

[0189] In step 2802, after parsing out the target collaboration table copy identifier carried in the operation request, the target collaboration table copy identifier is compared with the second identifier corresponding to each target collaboration table copy. The second permission storage table whose second identifier matches the target collaboration table copy identifier is searched from multiple second permission storage tables. This second permission storage table is the second permission storage table corresponding to the target collaboration table copy operated by the target user.

[0190] In step 2803, after determining the second permission storage table corresponding to the target collaborative table copy operated by the target user, the corresponding second permission entry can be found in the second permission storage table based on the user identity identifier corresponding to the target user and the area information corresponding to the target area. This matching permission entry indicates the second operation permission that the target user has when operating the target area in the target collaborative table copy.

[0191] In the embodiments disclosed in steps 2801 to 2803, by parsing the operation request, the target collaboration table copy identifier corresponding to the target collaboration table copy operated by the target user is determined. Then, based on the target collaboration table copy identifier, the associated second permission storage table is searched. Then, based on the user identity representation of the target user and the area information of the target area, the corresponding second permission entry is searched from the second permission storage table as a matching permission entry. In this way, the second operation permission possessed by the target user when operating on the target area in the target collaboration table copy can be accurately determined. Thus, the operation area and operation permission of each user when operating on the target collaboration table copy can be accurately constrained through the second permission storage table.

[0192] Example of the specific usage process of the collaboration table permission handling method in this embodiment of the disclosure The following reference Figure 29This document describes in detail a specific usage process of the collaborative form permission processing method according to an embodiment of the present disclosure. The process includes, but is not limited to, the following steps 2901 to 2927. In this process, the server 140 and the object terminal 110 each undertake a part of the task of the collaborative form permission processing method. In actual use, the server 140 may also undertake all the tasks of the collaborative form permission processing method.

[0193] Step 2901. In response to a trigger on a region within the target collaboration table, display a list of candidate users corresponding to that region. Step 2902. In response to the selection of a candidate user from the candidate user list, determine the selected candidate user as the first-authority user corresponding to the area in the table; Step 2903. Display the candidate permission list; Step 2904. In response to the selection of candidate permissions from the candidate permission list, the selected candidate permission is determined as the first operation permission corresponding to the first permission user; Step 2905. Based on the table range, the first-level user, and the first-level operation permission, obtain the first-level permission entries; Step 2906. Generate a first permission storage table based on multiple first permission entries; Step 2907. Obtain the creator user identifier for the target collaboration table; Step 2908. In response to the request to create a copy of the target collaboration table, obtain the identifier of the user who initiated the copy creation request; Step 2909. If the initiating user ID does not match the creating user ID, send a permission request to the creating user corresponding to the creating user ID; Step 2910. If a license response to the license request is received from the user who created the copy, determine the user who initiated the copy creation request; Step 2911. From the first permission storage table, determine the initiating user permission entry that matches the initiating user for the first permission user; Step 2912. Based on the initiating user's permission entries, determine the blocked areas in the target collaboration table that the initiating user does not have permission to view; Step 2913. Copy the metadata of the target collaboration table to obtain a metadata copy, and remove the data of the cells corresponding to the masked area from the metadata copy; Step 2914. Generate a copy of the target collaboration table based on the metadata copy; Step 2915. Generate a second identifier for the target collaboration table copy; Step 2916. Create a copy of the target collaboration table based on the metadata copy and the second identifier; Step 2917. Obtain the first number of first permission entries; Step 2918. First use case for obtaining a copy of the target collaboration table; Step 2919. If the first number satisfies the first condition, or the first use case satisfies the second condition, copy the first permission storage table to obtain a copy of the first permission storage table; Step 2920. Remove the first identifier from the copy of the first permission storage table to obtain the original copy of the first permission storage table; Step 2921. Obtain the second identifier of the target collaboration table copy; Step 2922. Based on the first permission storage table ontology and the second identifier, generate a second permission storage table associated with the target collaboration table copy; Step 2923. Obtain the target collaboration table copy identifier from the operation request; Step 2924. Determine the second permission storage table that matches the second identifier with the target collaboration table copy identifier; Step 2925. Among the multiple second permission entries in the second permission storage table, determine the matching permission entry; Step 2926. Obtain the operation type from the operation request; Step 2927. If the operation type matches the second operation permission in the matching permission entry, authorize the operation request.

[0194] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0195] It should be noted that in various specific embodiments of this application, when processing data related to the characteristics of the target user, such as target user attribute information or attribute information sets, is required, the target user's permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target user attribute information, separate permission or consent from the target user will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target user's separate permission or consent will the necessary target user-related data for the normal operation of the embodiments of this application be obtained.

[0196] Description of apparatus and devices according to embodiments of this disclosure Figure 30 This is a schematic diagram of the structure of a target collaboration form permission processing apparatus 3000 provided in an embodiment of the present disclosure. The target collaboration form permission processing apparatus 3000 includes: The permission setting unit 3010 is used to perform permission settings on the target collaborative table and obtain multiple first permission entries. The first permission entries include the table area, the first permission user corresponding to the table area, and the first operation permission corresponding to the first permission user. The first generation unit 3020 is used to generate a first permission storage table based on multiple first permission entries; The first creation unit 3030 is used to create a copy of the target collaboration table in response to a request to create a copy of the target collaboration table; The second generation unit 3040 is used to generate a second permission storage table associated with the target collaborative table copy based on the first permission storage table. The second permission storage table contains multiple second permission entries. The second permission entries include a table area, a second permission user corresponding to the table area, and a second operation permission corresponding to the second permission user. The first matching unit 3050 is used to respond to the target user's operation request for a target area in a target collaborative table copy, and determine a matching permission entry among a plurality of second permission entries, wherein the target user is matched with the second permission user in the matching permission entry, and the target area is matched with the table area in the matching permission entry; The first authorization unit 3060 is used to authorize an operation request based on the second operation permission in the matching permission entry.

[0197] Optionally, the permission setting unit 3010 is used for: In response to a trigger on a region within the target collaboration table, display a list of candidate users corresponding to that region. In response to the selection of a candidate user from the candidate user list, the selected candidate user is determined as the first-authority user corresponding to the area in the table; Display a list of candidate permissions; In response to the selection of candidate permissions from the candidate permission list, the selected candidate permission is determined as the first operation permission corresponding to the first permission user.

[0198] Optionally, the first creation unit 3030 is used for: In response to a request to create a copy of the target collaboration table, obtain the metadata corresponding to the target collaboration table; Generate a copy of the metadata based on the acquired metadata; A second identifier for generating a copy of the target collaboration form; Create a copy of the target collaboration form based on the metadata copy and the second identifier.

[0199] Optionally, the first creation unit 3030 is used for: Obtain the identifier of the user who created the target collaboration form; In response to a request to create a copy of the target collaborative table, obtain the identifier of the user who initiated the copy creation request; If the initiating user ID and the creating user ID do not match, send a permission request to the creating user corresponding to the creating user ID. If a permission response to the permission request is received from the user who created the collaboration form, a copy of the target collaboration form is created.

[0200] Optionally, the first creation unit 3030 is used for: Determine the user who initiated the copy creation request; From the first permission storage table, determine the first permission user's permission entry that matches the initiating user; Based on the initiating user's permission entries, determine the blocked areas in the target collaboration table that the initiating user does not have permission to view; Copy the metadata of the target collaboration table to obtain a metadata copy, and remove the data of the cells corresponding to the masked area from the metadata copy; Generate a copy of the target collaboration table based on the metadata copy.

[0201] Optionally, the copy creation request directs a first user group to use a copy of the target collaboration form, the first user group being different from a second user group using the target collaboration form; the second generation unit 3040 is used for: Identify users who are in the second user group but not in the first user group and are subject to data reduction. Identify incremental users who are in the first user group but not in the second user group; Copy multiple first-permission entries to obtain multiple copies of the first-permission entries, and delete the reduced users from the first-permission users in the multiple copies of the first-permission entries; In the second user group, identify the matching users that are matched with the incremental users; If the first permission user in the first permission entry copy contains a matching user, add the incremental user to the first permission user in the first permission entry copy to obtain the second permission entry, and associate the second permission entry with the target collaboration table copy to obtain the second permission storage table.

[0202] Optionally, the second generating unit 3040 is used for: Determine the first attribute parameter of multiple attributes for incremental users; For each user in the second user group, determine the second attribute parameters of multiple attributes of the user; For each attribute, determine the attribute matching degree between the second attribute parameter of each user in the second user group and the first attribute parameter of the incremental user; Based on the attribute matching degree corresponding to multiple attributes, determine the user matching degree between each user in the second user group and the incremental user; Based on user matching degree, a matching user is determined among the users in the second user group.

[0203] Optionally, the second generating unit 3040 is used for: Get the attribute weights of multiple attributes; Based on attribute weights, a weighted average of the attribute matching degrees corresponding to multiple attributes is calculated to obtain the user matching degree.

[0204] Optionally, the second generating unit 3040 is used for: Display the permission migration list, which includes a column for users whose permissions are to be migrated and a column for users whose permissions are to be received. The column for users whose permissions are to be migrated includes users in the second user group, and the column for users whose permissions are to be received includes users in the first user group. In response to the permission migration operation of the initiating user on the permission migration list in response to the copy creation request, determine the permission mapping relationship between the users whose permissions are to be received in the first user group and the users whose permissions are to be migrated in the second user group; Copy multiple first-level permission entries to obtain multiple copies of the first-level permission entries; If the first permission user in the first permission entry copy is a permission to be migrated user, based on the permission mapping relationship, the first permission user in the first permission entry copy is changed from the permission to be migrated user to the corresponding permission to receive user, resulting in multiple second permission entries. The second permission entries are then associated with the target collaboration table copy to obtain the second permission storage table.

[0205] Optionally, the second generating unit 3040 is used for: Identify users who are in the second user group but not in the first user group and are subject to data reduction. Identify incremental users who are in the first user group but not in the second user group; Users whose permissions are reduced are identified as users in the "Users whose permissions are to be migrated" column, and users whose permissions are increased are identified as users in the "Users whose permissions are to be received" column. Based on the "Users whose permissions are to be migrated" and "Users whose permissions are to be received" columns, the permission migration list is displayed.

[0206] Optionally, the second generating unit 3040 is used for: Obtain the first number of first-permission entries; The primary use case for obtaining a copy of the target collaboration table; If the first number meets the first condition, or the first use case meets the second condition, a second permission storage table associated with the target collaboration table copy is generated based on the first permission storage table.

[0207] Optionally, the second generating unit 3040 is used for: Copy the first permission storage table to obtain a copy of the first permission storage table; Remove the first identifier from the copy of the first permission storage table to obtain the original copy of the first permission storage table; Obtain the second identifier of the target collaboration table copy; Based on the first permission storage table ontology and the second identifier, a second permission storage table is generated that is associated with the target collaboration table copy.

[0208] Optionally, the first matching unit 3050 is used for: Obtain the target collaboration table copy identifier from the operation request; Determine the second permission storage table that matches the second identifier with the target collaboration table copy identifier; Among the multiple second permission entries in the second permission storage table, identify the matching permission entry.

[0209] Reference Figure 31 , Figure 31 The structural block diagram of the terminal portion of the collaborative form permission processing method according to the embodiments of this disclosure includes: a radio frequency (RF) circuit 3110, a memory 3115, an input unit 3130, a display unit 3140, a sensor 3150, an audio circuit 3160, a wireless fidelity (WiFi) module 3170, a processor 3180, and a power supply 3190, etc. Those skilled in the art will understand that... Figure 31 The terminal structure shown does not constitute a limitation on mobile phones or computers and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0210] The RF circuit 3110 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 3180; in addition, it transmits uplink data to the base station.

[0211] The memory 3115 can be used to store software programs and modules, and the processor 3180 executes various functional applications and data processing of the content terminal by running the software programs and modules stored in the memory 3115.

[0212] The input unit 3130 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the content terminal. Specifically, the input unit 3130 may include a touch panel 3131 and other input devices 3132.

[0213] Display unit 3140 can be used to display input or provided information, as well as various menus of the content terminal. Display unit 3140 may include display panel 3141.

[0214] Audio circuitry 3160, speaker 3161, and microphone 3162 provide an audio interface.

[0215] In this embodiment, the processor 3180 included in the terminal can execute the collaborative table permission processing method of the previous embodiment.

[0216] The terminals disclosed in this embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to data collection, data export, and data analysis.

[0217] Figure 32 This is a partial structural block diagram of a server 140 implementing the collaborative form permission processing method of this disclosure embodiment. The server 140 can vary significantly due to different configurations or performance, and may include one or more central processing units (CPUs) 3222 (e.g., one or more processors) and memory 3232, and one or more storage media 3230 (e.g., one or more mass storage devices) for storing application programs 3242 or data 3244. The memory 3232 and storage media 3230 can be temporary or persistent storage. The program stored in the storage media 3230 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the server 140. Furthermore, the CPU 3222 may be configured to communicate with the storage media 3230 and execute the series of instruction operations in the storage media 3230 on the server 140.

[0218] Server 140 may also include one or more power supplies 3226, one or more wired or wireless network interfaces 3250, one or more input / output interfaces 3258, and / or one or more operating systems 3241, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0219] The central processing unit 3222 in server 140 can be used to execute the collaborative table permission processing method of the present disclosure embodiments.

[0220] This disclosure also provides a computer-readable storage medium for storing program code for executing the collaborative table permission processing methods of the foregoing embodiments.

[0221] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the collaborative form permission processing method described above.

[0222] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar terms and are not necessarily used to describe a particular order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0223] It should be understood that in this disclosure, "at least one item" refers to one or more items, and "more than one item" refers to two or more items. "And / or" is used to describe the relationship between related content, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related content are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0224] It should be understood that in the description of the embodiments of this disclosure, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0225] In the embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods 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 couplings or direct couplings or communication connections shown or discussed may be indirect couplings or communication connections between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0226] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0227] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0228] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server 140, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. 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.

[0229] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects. The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for handling permissions in a collaborative table, characterized in that, include: Perform permission settings on the target collaboration table to obtain multiple first permission entries. Each first permission entry includes a region within the table, a first permission user corresponding to the region within the table, and a first operation permission corresponding to the first permission user. Based on the multiple first permission entries, a first permission storage table is generated; In response to a request to create a copy of the target collaboration table, a target collaboration table copy is created. Based on the first permission storage table, a second permission storage table is generated that is associated with the target collaboration table copy. The second permission storage table contains multiple second permission entries. Each second permission entry includes the table area, the second permission user corresponding to the table area, and the second operation permission corresponding to the second permission user. In response to a target user's operation request for a target area in the target collaborative table copy, a matching permission entry is determined from the plurality of second permission entries, wherein the target user matches the second permission user in the matching permission entry, and the target area matches the in-table area in the matching permission entry; The operation request is authorized based on the second operation permission in the matching permission entry.

2. The collaborative table permission processing method according to claim 1, characterized in that, The permission settings applied to the target collaboration table result in multiple first permission entries, including: In response to a triggering action on a region within the target collaboration table, a list of candidate users corresponding to that region is displayed. In response to the selection of a candidate user from the candidate user list, the selected candidate user is determined as the first authorized user corresponding to the area in the table; Display a list of candidate permissions; In response to the selection of candidate permissions from the candidate permission list, the selected candidate permission is determined as the first operation permission corresponding to the first permission user; The first permission entry is obtained based on the area in the table, the first permission user, and the first operation permission.

3. The collaborative table permission processing method according to claim 1, characterized in that, The step of creating a target collaboration table copy in response to a request to create a copy of the target collaboration table includes: In response to the request to create a copy of the target collaboration table, obtain the metadata corresponding to the target collaboration table; Based on the acquired metadata, a metadata copy is generated; A second identifier for generating a copy of the target collaboration form; Based on the metadata copy and the second identifier, create the target collaboration form copy.

4. The collaborative table permission processing method according to claim 1, characterized in that, The step of creating a target collaboration table copy in response to a request to create a copy of the target collaboration table includes: Obtain the identifier of the user who created the target collaboration form; In response to the request to create a copy of the target collaboration table, obtain the identifier of the user who initiated the copy creation request; If the initiating user identifier does not match the creating user identifier, send a permission request to the creating user corresponding to the creating user identifier; If a permission response to the permission request is received from the user who created the form, a copy of the target collaboration form is created.

5. The collaborative table permission processing method according to claim 1, characterized in that, The step of creating a target collaboration table copy in response to a request to create a copy of the target collaboration table includes: Determine the user who initiated the copy creation request; From the first permission storage table, determine the initiating user permission entry that matches the initiating user for the first permission user; Based on the initiating user's permission entries, determine the blocked areas in the target collaboration table that the initiating user does not have permission to view; Copy the metadata of the target collaboration table to obtain a metadata copy, and remove the data of the cells corresponding to the shielded area from the metadata copy; The target collaboration table copy is generated based on the metadata copy.

6. The collaborative table permission processing method according to claim 1, characterized in that, The copy creation request is directed to a first user group that uses the target collaboration form copy, and the first user group is different from the second user group that uses the target collaboration form. The step of generating a second permission storage table associated with the target collaboration table copy based on the first permission storage table includes: Identify users who are in the second user group but not in the first user group who are experiencing reduced usage; Identify incremental users who are in the first user group but not in the second user group; The plurality of first permission entries are copied to obtain a plurality of copies of the first permission entries, and the reduced user is deleted from the first permission users in the plurality of copies of the first permission entries; In the second user group, a matching user that matches the incremental user is determined; If the first permission user in the first permission entry copy contains the matching user, the incremental user is added to the first permission user in the first permission entry copy to obtain a second permission entry, and the second permission entry is associated with the target collaboration table copy to obtain the second permission storage table.

7. The collaborative table permission processing method according to claim 6, characterized in that, The step of determining the matching user in the second user group that matches the incremental user includes: Determine the first attribute parameter of the multiple attributes of the incremental user; For each user in the second user group, determine the second attribute parameter of the multiple attributes of the user; For each attribute, determine the second attribute parameter of each user in the second user group and the attribute matching degree with the first attribute parameter of the incremental user; Based on the attribute matching degree corresponding to the multiple attributes, determine the user matching degree between each user in the second user group and the incremental user; Based on the user matching degree, the matching user is determined among each user in the second user group.

8. The collaborative table permission processing method according to claim 7, characterized in that, Determining the user matching degree between each user in the second user group and the incremental user based on the attribute matching degree corresponding to the multiple attributes includes: Obtain the attribute weights of each of the multiple attributes; Based on the attribute weights, a weighted average of the attribute matching degrees corresponding to the multiple attributes is calculated to obtain the user matching degree.

9. The collaborative table permission processing method according to claim 1, characterized in that, The copy creation request is directed to a first user group that uses the target collaboration form copy, and the first user group is different from the second user group that uses the target collaboration form. The step of generating a second permission storage table associated with the target collaboration table copy based on the first permission storage table includes: Display a permission migration list, which includes a permission migration user column and a permission receiving user column. The permission migration user column includes users in the second user group, and the permission receiving user column includes users in the first user group. In response to the permission migration operation of the initiating user in the copy creation request on the permission migration list, the permission mapping relationship between the user whose permissions are to be received in the first user group and the user whose permissions are to be migrated in the second user group is determined; Copy the plurality of first permission entries to obtain a plurality of copies of the first permission entries; If the first permission user in the first permission entry copy is the permission to be migrated user, based on the permission mapping relationship, the first permission user in the first permission entry copy is changed from the permission to be migrated user to the corresponding permission to receive user, resulting in multiple second permission entries, and the second permission entries are associated with the target collaboration table copy to obtain the second permission storage table.

10. The collaborative table permission processing method according to claim 9, characterized in that, The display permission migration list includes: Identify users who are in the second user group but not in the first user group who are experiencing reduced usage; Identify incremental users who are in the first user group but not in the second user group; The reduced users are identified as users in the permission migration list, and the increased users are identified as users in the permission receiving list. Based on the permission migration list and the permission receiving list, the permission migration list is displayed.

11. The collaborative table permission processing method according to claim 1, characterized in that, The step of generating a second permission storage table associated with the target collaborative table copy based on the first permission storage table includes: Obtain the first number of the first permission entries; The first use case for obtaining a copy of the target collaboration table; If the first number satisfies the first condition, or the first use case satisfies the second condition, a second permission storage table associated with the target collaboration table copy is generated based on the first permission storage table.

12. The collaborative table permission processing method according to claim 1, characterized in that, The first permission storage table includes the first permission storage table body and the first identifier of the target collaboration table; The step of generating a second permission storage table associated with the target collaboration table copy based on the first permission storage table includes: Copy the first permission storage table to obtain a copy of the first permission storage table; Remove the first identifier from the copy of the first permission storage table to obtain the original copy of the first permission storage table; Obtain the second identifier of the target collaboration table copy; Based on the first permission storage table body and the second identifier, a second permission storage table associated with the target collaboration table copy is generated.

13. The collaborative table permission processing method according to claim 12, characterized in that, The operation request includes the identifier of the target collaboration table copy; In response to a target user's operation request for a target area in the target collaborative table copy, determining a matching permission entry from the plurality of second permission entries includes: Obtain the target collaboration table copy identifier from the operation request; Determine the second permission storage table that matches the second identifier with the target collaboration table copy identifier; Among the plurality of second permission entries in the second permission storage table, the matching permission entry is determined.

14. The collaborative table permission processing method according to claim 1, characterized in that, The operation request includes the operation type; The step of authorizing the operation request based on the second operation permission in the matched permission entry includes: Obtain the operation type from the operation request; If the operation type matches the second operation permission, the operation request is authorized.

15. A collaborative table permission processing device, characterized in that, include: The permission setting unit is used to perform permission settings on the target collaborative table to obtain multiple first permission entries. The first permission entries include a table area, a first permission user corresponding to the table area, and a first operation permission corresponding to the first permission user. The first generation unit is used to generate a first permission storage table based on the plurality of first permission entries; The first creation unit is configured to create a target collaboration table copy in response to a request to create a copy of the target collaboration table; The second generation unit is used to generate a second permission storage table associated with the target collaboration table copy based on the first permission storage table. The second permission storage table contains a plurality of second permission entries. The second permission entries include the table area, the second permission user corresponding to the table area, and the second operation permission corresponding to the second permission user. The first matching unit is configured to, in response to a target user's operation request for a target area in the target collaborative table copy, determine a matching permission entry among the plurality of second permission entries, wherein the target user matches a second permission user in the matching permission entry, and the target area matches the table area in the matching permission entry; The first authorization unit is used to authorize the operation request based on the second operation permission in the matching permission entry.

16. An electronic device comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the collaborative table permission processing method according to any one of claims 1 to 14.

17. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the collaborative table permission processing method according to any one of claims 1 to 14.

18. A computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the collaborative form permission processing method according to any one of claims 1 to 14.

Images