A server and its storage file editing permission control method, device and medium

By analyzing the client's editing request, obtaining the file ownership information and login user ID, and giving or denying editing permissions based on the comparison results, the deadlock problem in server file editing is solved, the operation process is simplified, the burden on the server and client is reduced, and the editing efficiency is improved.

CN114662070BActive Publication Date: 2025-09-05GUANGDONG MEIFANG ZHIXING TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210299363.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-03-25
Publication Date
2025-09-05
Estimated Expiration
2042-03-25

AI Technical Summary

Technical Problem

Existing servers are prone to deadlock problems during file editing, and existing solutions are complex and increase the burden on clients and servers.

Method used

By analyzing the client's editing request, obtain the file ownership information, logged-in user ID and logged-in client ID, give or deny the logged-in user's editing permissions to the file based on the comparison results, and use the current client ID and current user ID to lock the file to avoid multiple users editing the file at the same time and solve the deadlock problem.

Benefits of technology

Simplifies the operation process, reduces the burden on servers and clients, improves editing efficiency, ensures that files are always up-to-date, and avoids file confusion.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114662070B_ABST
    Figure CN114662070B_ABST
Patent Text Reader

Abstract

The present invention discloses a server and a method, device, and medium for controlling edit permissions for stored files. The method comprises: receiving an edit request from a client, parsing the edit request to obtain ownership information of the file, as well as a logged-in user ID and a logged-in client ID; the ownership information includes a current client ID and a current user ID; and assigning ownership to the file and granting or denying edit permissions to the logged-in user based on a comparison between the logged-in user ID and the current user ID, and between the logged-in client ID and the current client ID. The present invention avoids file "deadlock" issues and frees up server resources.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of file authority management, and in particular to a server and a method, device and computer-readable medium for controlling the editing authority of stored files. Background Art

[0002] Storing files on a server enables sharing among multiple people and improves the efficiency of collaborative work. In the field of robotics, maps are the basis for robots to perform their work tasks. Due to the large workload of map drawing, multiple staff members usually use different clients to download the maps stored on the server to the local computer for editing. After editing, they are uploaded to the server for storage. However, in this case, the content edited by the current client may have been edited by other clients. When the current client saves, the content edited by other clients will be overwritten. In order to avoid the above problems, it is usually restricted to only one client for editing by locking. By adding a specific mark to the storage medium to indicate that the map has been locked, no other client can edit the map. Only the locked client can edit it.

[0003] However, this approach will cause the following problems:

[0004] First, if the locked client crashes and the unlocking process cannot be started, it will cause a "deadlock" and the map will be locked forever.

[0005] Second, adding a timeout to the lock can solve the "deadlock" problem. However, in order to ensure that the lock remains locked before the map is edited, the locked client needs to periodically call the interface to extend the lock timeout. This operation is complicated and increases the burden on the client and server.

[0006] In view of this, it is necessary to improve the existing control method of server storage file editing permissions to facilitate use and improve collaborative work efficiency. Summary of the Invention

[0007] In view of the above-mentioned defects, the technical problem to be solved by the present invention is to provide a server and its storage file editing permission control method, device and computer-readable medium to solve the problem of "deadlock" easily caused when storing files on existing servers.

[0008] To this end, the present invention provides a method for managing file editing permissions, which is characterized by comprising the following steps:

[0009] Receiving an edit request from a client, parsing the edit request to obtain ownership information of the file, a logged-in user ID, and a logged-in client ID; the ownership information includes a current client ID and a current user ID; and granting or denying the logged-in user edit permission for the file based on a comparison result between the logged-in user ID and the current user ID, and between the logged-in client ID and the current client ID.

[0010] In the above method, preferably, giving the logged-in user editing authority over the file includes the following steps: returning the file to the logged-in client for the logged-in user to edit and generate an edited file on the client; responding to the logged-in user's save command for the edited file, receiving the edited file and overwriting the file.

[0011] Files on the server are downloaded to the client for local editing, which reduces the pressure on the server and improves editing efficiency.

[0012] In the above method, preferably, granting or denying the logged-in user editing permission to the file based on the comparison result between the logged-in user ID and the current user ID and the logged-in client ID and the current client ID includes the following steps:

[0013] The current client ID and the current user ID are left blank, the logged-in user ID and the logged-in client ID are saved in the ownership information, and the logged-in user is given editing authority over the file;

[0014] If the comparison result of the logged-in user ID is the same as the current user ID, and the comparison result of the current client ID is the same as the logged-in client ID, the logged-in user is granted editing permission for the file;

[0015] If the comparison result between the logged-in user ID and the current user ID is different, and the comparison result between the current client ID and the logged-in client ID is different, a message asking whether to continue editing is sent to the current user ID; if no reply message to the continue editing message is received from the current user, the logged-in user is granted editing permission for the file; if a reply message to the continue editing message is received from the current user, the logged-in user is denied editing permission for the file.

[0016] By comparing the login user ID and login client ID with the current client ID and current user ID, it is ensured that the user can only use one client for editing at the same time, keeping the file always up to date.

[0017] In the above method, preferably, when a reply message from the current user to the continue editing message is received, a countdown is started according to a lock time, where the lock time is pre-configured or carried in the reply message;

[0018] Before the lock time countdown ends, the logged-in user is denied editing permission for the file.

[0019] In the above method, preferably, before the lock time countdown ends, it is determined whether a reply message is received again, and when the current client detects that the user is continuously editing the file, the reply message is sent again at a preset time interval, and the preset time is less than the lock time;

[0020] If a reply message is received, the lock time is counted down again.

[0021] In the above method, preferably, when a reply message from the current user to the continue editing message is received, the current client ID, current user ID and lock time are sent to the current user requesting login and the user previously requesting login, and the clients of the current user requesting login and the user previously requesting login can start countdown according to the lock time.

[0022] This allows the current user requesting to log in and the previous user requesting to log in to clearly understand the user currently editing the file and the waiting time, so as to arrange work reasonably and improve work efficiency.

[0023] In the above method, preferably, after the lock time countdown ends, it is determined whether a request from the logged-in user has been received; if so, the ownership information of the file is deleted and the logged-in user is granted editing permissions to the file. By the user continuously sending reply messages and the server continuously detecting whether reply messages have been received, it is determined whether the user is continuously editing the file. If no reply message is received, the file ownership is reallocated according to the request of the currently logged-in user, thereby improving efficiency.

[0024] The present invention also provides a file editing permission management device, which is set on a server and includes: a parsing module, used to receive an editing request issued by a client, parse the editing request to obtain the ownership information of the file and the login user ID and login client ID; the ownership information is spliced ​​by the current client ID and the current user ID; a comparison module, used to obtain the comparison results of the login user ID and the current user ID and the login client ID and the current client ID; a permission management module, used to grant or deny the login user the editing permission for the file based on the comparison results.

[0025] The present invention also provides a server on which files for editing by a client are stored, and the server is provided with the above-mentioned file editing authority management device.

[0026] The present invention also provides a computer-readable medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements the above-mentioned method for managing file editing permissions.

[0027] As can be seen from the above technical solutions, the present invention provides a server and its method, device, and computer-readable medium for controlling the editing permissions of stored files, which solve the problem of "deadlock" easily caused by file editing on servers in the prior art. Compared with the prior art, the present invention has the following beneficial effects:

[0028] By parsing the client's edit request, the system obtains the file's ownership information, along with the logged-in user ID and client ID. Based on the comparison of the logged-in user ID and client ID with the ownership information, the user is granted or denied edit access to the file. Using the current client ID and user ID to lock the file prevents multiple users from editing simultaneously, potentially leading to file chaos and deadlocks. It also simplifies operations and reduces server load. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces and describes the drawings required for use in the embodiments of the present invention or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0030] Figure 1 A flowchart of a method for managing file editing permissions provided in specific embodiment 1 of the present invention;

[0031] Figure 2 This is a flow chart of a method for managing file editing permissions provided in specific embodiment 2 of the present invention. DETAILED DESCRIPTION

[0032] The following will clearly and completely describe the technical solutions of the embodiments of the present invention in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0033] The terms in this application are explained as follows:

[0034] Grant file editing permission, the server returns its saved file to the client, the client edits it locally, and when the client saves it, the server responds to the client's save command, receives the edited file uploaded by the client and overwrites the original file.

[0035] Deny file editing permission. The server does not return the saved file to the client, and the client cannot edit the file.

[0036] The implementation principle of the present invention is:

[0037] By parsing the client's editing request, the ownership information of the file as well as the login user ID and login client ID are obtained; based on the comparison result of the login user ID and login client ID with the current ownership information, the login user is granted or denied the editing permission for the file.

[0038] Ownership information includes the current client ID and the current user ID;

[0039] The current client ID and the current user ID are left blank, the logged-in user ID and the logged-in client ID are saved in the ownership information, and the logged-in user is given editing authority over the file;

[0040] If the comparison result of the logged-in user ID is the same as the current user ID, and the comparison result of the current client ID is the same as the logged-in client ID, the logged-in user is granted editing permission for the file;

[0041] If the comparison result between the logged-in user ID and the current user ID is different, and the comparison result between the current client ID and the logged-in client ID is different, a message asking whether to continue editing is sent to the current user ID; if no reply message to the continue editing message is received from the current user, the logged-in user is granted editing permission for the file; if a reply message to the continue editing message is received from the current user, the logged-in user is denied editing permission for the file.

[0042] The present invention can avoid the problem of "deadlock" and release resources of the client and the server.

[0043] To more clearly explain and illustrate the technical solution and implementation of the present invention, several preferred embodiments for implementing the present invention are described below. The following embodiments use a robot map as a specific example of a file stored on a server. Clearly, the present invention can be applied to managing edit permissions for any file stored on a server, such as documents, spreadsheets, text files, images, and video files.

[0044] It should be noted that the directional words such as "inside, outside", "front, back" and "left, right" in this article are expressed based on the product usage status. Obviously, the use of the corresponding directional words does not constitute a limitation on the scope of protection of this scheme.

[0045] Specific embodiment 1.

[0046] See Figure 1 , Figure 1 This is a flow chart of a method for managing file editing permissions provided in specific embodiment 1 of the present invention.

[0047] like Figure 1 As shown, a method for managing file editing permissions provided by specific embodiment 1 of the present invention has only one client and includes the following steps:

[0048] In step 110, the user submits an edit request to the server via the client to edit the file. The file here refers to the file that the user requests to edit, and the file is stored on the server.

[0049] Different users can submit edit requests using the same client or different clients, and the same user can also submit edit requests using different clients. In this embodiment, the file is the robot's work map, such as the map of Building A. The edit request contains file information, such as the file name, so that the corresponding file can be found on the server for processing.

[0050] Step 120: After receiving the editing request from the client, the server parses the editing request to obtain the file information of the file as well as the login user ID and the login client ID, and obtains the ownership information of the file by querying the server.

[0051] File ownership information includes the current client ID, current user ID, and lockout time. The current client ID and current user ID refer to the client ID and user ID that have edit permissions for the file. The lockout time limits the time a client can edit the file and is preset by the system, such as 1 or 2 minutes. The current client ID, current user ID, and lockout time are stored on the server and associated with the corresponding file.

[0052] Step 130 , granting or denying the logged-in user the editing permission for the file based on the comparison results between the logged-in user ID and the current user ID and the logged-in client ID and the current client ID.

[0053] Granting the logged-in user editing permissions to a file includes the following steps:

[0054] Return the file to the logged-in client for the logged-in user to edit and generate the edited file on the client;

[0055] After the client completes editing and saves the file, the server responds to the logged-in user's save command for the edited file, receives the edited file uploaded by the client, and overwrites the original file on the server.

[0056] In this embodiment, when a user requests to edit a file for the first time through a client, or when the file has not been edited for a long period of time and the file's ownership information has been automatically cleared, the current client ID, current user ID, and lock time in the file's ownership information are blank. At this point, the server grants the logged-in user editing rights to the file. Specifically, a record is created on the server, along with the logged-in client ID, logged-in user ID, and lock time. Once this record is created, ownership of the file is assigned to the client and user who requested the edit. Only those who have ownership of the file can edit it, effectively locking the file. The file can only be edited if the logged-in client ID and logged-in user ID are identical to the current client ID and current user ID.

[0057] Clear the ownership of the file, that is, delete the record.

[0058] In this embodiment, if the client crashes unexpectedly and the server does not receive a command to clear the file ownership, the file ownership remains with the original client and user. In this case, if the original user logs in again using the original client, they can edit the file directly. If the same user logs in using a different client, they are considered different users because the login client ID is different, and the process remains the same as for different users.

[0059] If the user logs out of the client after not using it for a certain period of time, when logging in again, the ownership of the file on the server is not cleared and still belongs to the client and the user. At this time, the user can continue to edit on the client.

[0060] In the present invention, after the server responds to a client's instruction to save or cancel an edit on a file, it clears the file's ownership information, i.e., deletes the file's ownership record, thereby freeing up server resources and reducing the server's load. After the file's ownership information is cleared, upon receiving another edit request, the server will reassign ownership to the file.

[0061] According to the method of the present invention, only one user can edit a file using one client at the same time, thus avoiding the occurrence of a "deadlock" situation. The file is unlocked immediately after canceling or saving the edit, thereby releasing the resources of the client and the server in time and reducing the load on the server.

[0062] Specific embodiment 2.

[0063] Specific Example 1 describes the case where only one user requests to edit a file. Specific Example 2 of the present invention, building on Specific Example 1, describes how to handle edit requests made by multiple users. The client includes a first client and at least one second client, for example, a first client A, a second client B, and a third client C. First user A1 requests to edit using first client A, second user B1 requests to edit using second client B, and third user C1 requests to edit using third client C.

[0064] like Figure 2 As shown, a method for managing file editing permissions provided in Specific Example 2 includes the following steps:

[0065] In step 210 , the first user A1 submits a first editing request for editing the file F to the server through the first client A.

[0066] In step 220, after receiving the first edit request from client A, the server assigns ownership of file F to user A1 of client A, as the ownership information of file F is currently empty. Specifically, the server creates a record that associates file F with client A, user A1, and the lock time as ownership information of file F.

[0067] Step 230 : The server responds to the first editing request of the first client A and returns the file F to the first client A for the first client A to perform local editing.

[0068] Step 240 : While the first user A1 is editing a file, the second user B1 submits a second editing request for editing the file F to the server through the second client B.

[0069] In step 250 , after receiving the second editing request, the server obtains the ownership information of the file F according to the file information of the file F. At this time, the ownership information of the file F includes the first client A, the first user A1 and the locking time.

[0070] Step 260: Since the currently logged-in second client B and second user B1 are different from the first client A and first user A1 in the file ownership information, the server sends a first message to the first client A asking whether to continue editing the file.

[0071] In step 270, the server rejects the editing request of the second user B1 of the second client B or grants the second user B1 of the second client B the editing permission for the file, depending on whether the server receives a reply message from the first client A to the first message. The specific steps are as follows:

[0072] In step 271, after receiving the first message, first client A detects whether first user A1 is currently editing a file. If so, first client A automatically replies to the first message. For example, if first user A1 is currently editing a file, first client A sends a reply message to the server confirming continued editing. This reply message includes both first client A and first user A1. If first user A1 is not currently editing a file, no reply is sent to the first message.

[0073] In step 272, if the server receives a reply message from first client A, indicating that first user A1 of first client A wants to continue editing the file, the server rejects the editing request from second user B1 of second client B and begins a countdown based on the lockout time. Before the lockout time countdown expires, second client B is denied editing permission for the file. The lockout time can be pre-configured by the server or included in the reply message from first client A.

[0074] Step 273: The server sends the current client ID, the current user ID, and the lock time to the second client B, and the second client B starts counting down according to the lock time.

[0075] In step 274, client A sends a reply message to the server at a preset interval (the interval is less than the remaining lock time), for example, 40 seconds, to indicate that client A still needs to continue editing. Each time the server receives a reply message, it restarts the lock time countdown. The interval is less than the remaining lock time to prevent client A from sending a reply message before the lock time expires.

[0076] If the server receives the reply message from the first client A, it will also send the current client ID, current user ID and lock time to the first client A, the second client B and the third client C. All three clients can start countdown according to the lock time.

[0077] That is to say, when the server receives the current user's reply message to the continue editing message, it will send the current client ID, current user ID and lock time to the current user requesting login and the previous user requesting login, and the clients of the current user requesting login and the previous user requesting login can start countdown according to the lock time.

[0078] In step 275, if the server does not receive a reply from client A within the lock timeout period (that is, if client A has not sent a reply before the countdown ends), client A is deemed to have experienced a system failure, such as a system crash. If the server receives another edit request from another logged-in user, the server will remove the edit permission for file F and assign the edit permission to another logged-in user. Multiple logged-in users can issue edit requests on a first-come, first-served basis. This can be achieved, for example, using a "distributed lock" mechanism, where the first requester receives the lock and no longer responds to subsequent requests.

[0079] If the server receives an edit request from client B first, it deletes the ownership information for file F and assigns ownership of file F to user B1 of client B. User B1 of client B can then edit the file. The ownership information for file F is now: client B, user B1, and the second lock time.

[0080] In the above process, if the third user C1 first submits an editing request to the file F using the third client C, the processing method is the same as that of the second user B1 and the second client B, which will not be repeated here.

[0081] In the above process, if the first client A crashes, and the first user A1 changes clients and then issues an edit request later than the second user B1, the edit permission for file F will be assigned to the second user B1. For example, the first user A1 may change clients from a tablet to a PC.

[0082] Based on the above method, the present invention also provides a file editing permission management device, which is set on a server and includes:

[0083] A parsing module, configured to receive an edit request from a client, parse the edit request to obtain the ownership information of the file, as well as the login user ID and the login client ID; the ownership information includes the current client ID and the current user ID;

[0084] A comparison module, configured to obtain a comparison result between the login user ID and the current user ID and between the login client ID and the current client ID;

[0085] The rights management module is used to assign ownership to the file based on the comparison results, and to grant or deny the logged-in user the right to edit the file.

[0086] The implementation methods of the comparison module and the authority management module have been described in detail in the aforementioned method for managing file editing permissions, and will not be repeated here.

[0087] Likewise, the present invention also provides a server on which files for editing by a client are stored. The server is provided with the above-mentioned file editing authority management device to implement authority management of the files.

[0088] The file editing permission management method provided in the present invention can be implemented as a computer software program. For example, the present invention also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned file editing permission management method.

[0089] Based on the description of the above specific embodiments, the server and file editing permission management method, device, and computer-readable medium provided by the present invention have the following advantages over the prior art:

[0090] First, based on the comparison results between the logged-in user ID and the current user ID, and the logged-in client ID and the current client ID, ownership of the file is assigned, and the logged-in user is granted or denied editing permissions to the file. This solves the "deadlock" problem, reduces the burden on the client and server, simplifies the processing logic, and improves efficiency.

[0091] Second, at the same time, the client's editing permissions for the file are restricted based on the client ID and user ID in the ownership information. That is, at the same time, the same user logged in on different clients is considered a different user, so that only one client can edit at the same time, ensuring the integrity of the editing information.

[0092] Third, the processing logic is simple and easy to implement.

[0093] Fourth, the first client that is editing sends a reply message to the server at a preset interval. The server sends the client ID and user ID of the editing client and the lock time to all clients that have issued editing requests, so that all clients can not only understand the editing occupancy of the file in real time, but also know the client, user and remaining time that are editing at that time.

[0094] Finally, it should be noted that the terms "comprises," "includes," or any other variations thereof, as used herein, are intended to encompass non-exclusive inclusion, such that a process, method, article, or robot comprising a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or robot. In the absence of further limitations, an element defined by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article, or robot comprising the element.

[0095] The present invention is not limited to the above-mentioned optimal implementation mode. Anyone should be aware that any structural changes made under the inspiration of the present invention, and any technical solutions that are the same or similar to the present invention, fall within the scope of protection of the present invention.

Claims

1. A method for managing file editing permissions, wherein the file is stored on a server, characterized in that: The method comprises the following steps: Receiving an edit request from a client, parsing the edit request to obtain ownership information of the file, a logged-in user ID, and a logged-in client ID; the ownership information includes a current client ID, a current user ID, and a lock time; Granting or denying the logged-in user editing permission for the file based on the comparison results between the logged-in user ID and the current user ID and between the logged-in client ID and the current client ID, including: if the comparison results between the logged-in user ID and the current user ID are different, and the comparison results between the current client ID and the logged-in client ID are different, sending a "continue editing" message to the current user ID; if no reply message to the "continue editing" message from the current user is received, granting the logged-in user editing permission for the file; if a reply message to the "continue editing" message from the current user is received, denying the logged-in user editing permission for the file; wherein, if the current user ID detects that the current user is editing the file when receiving the "continue editing" message, automatically sending the reply message; The method further comprises: Before the lock time countdown ends, determining whether a reply message is received again, the current client detects that the user is continuously editing the file, and resends the reply message once at a preset time interval, where the preset time is less than the lock time; If a reply message is received, the lock time is counted down again.

2. The method according to claim 1, characterized in that Giving the logged-in user editing rights to the file includes the following steps: Return the file to the logged-in client for the logged-in user to edit and generate an edited file on the client; In response to a save command of the edited file by a logged-in user, the edited file is received and overwritten.

3. The method according to claim 1, characterized in that According to the comparison result between the login user ID and the current user ID and the login client ID and the current client ID, granting the login user the editing permission for the file further comprises the following steps: The current client ID and the current user ID are left blank, the logged-in user ID and the logged-in client ID are saved in the ownership information, and the logged-in user is given editing authority over the file; If the comparison result of the logged-in user ID is the same as the current user ID, and the comparison result of the current client ID is the same as the logged-in client ID, the logged-in user is given the editing authority for the file.

4. The method according to claim 3, characterized in that When a reply message from the current user to the continue editing message is received, a countdown is started according to a lock time, where the lock time is pre-configured or carried in the reply message; Before the lock time countdown ends, the logged-in user is denied editing permission for the file.

5. The method according to claim 4, characterized in that After the lock time countdown ends, determine whether a request from the logged-in user is received; If a request is received from a logged-in user, the ownership information of the file is deleted and the logged-in user is given editing authority over the file.

6. The method according to claim 4, characterized in that When a reply message from the current user to the continue editing message is received, the current client ID, current user ID and lock time are sent to the current user requesting login and the previous user requesting login, and the clients of the current user requesting login and the previous user requesting login can start countdown according to the lock time.

7. A file editing permission management device, set on a server, characterized in that: include: A parsing module, configured to receive an edit request from a client, parse the edit request to obtain ownership information of the file, a login user ID, and a login client ID; The ownership information includes the current client ID, the current user ID and the lock time; A comparison module, configured to obtain a comparison result between the login user ID and the current user ID and between the login client ID and the current client ID; The rights management module is configured to assign ownership to the file and grant or deny the logged-in user editing rights to the file based on the comparison result, including: if the comparison result between the logged-in user ID and the current user ID is different, and the comparison result between the current client ID and the logged-in client ID is different, sending a "continue editing" message to the current user ID; if no reply message is received from the current user to the "continue editing" message, granting the logged-in user editing rights to the file; if a reply message is received from the current user to the "continue editing" message, denying the logged-in user editing rights to the file; wherein, if the current user ID detects that the current user is editing the file when receiving the "continue editing" message, the reply message is automatically sent; The permission management module is also used to determine whether a reply message is received again before the lock time countdown ends. When the current client detects that the user is continuously editing the file, the reply message is sent again at a preset time interval, and the preset time is less than the lock time; if a reply message is received, the lock time countdown is restarted.

8. A server storing files for editing by a client, characterized in that: The server is provided with a file editing authority management device as claimed in claim 7.

9. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the computer program implements the method for managing file editing permissions according to any one of claims 1 to 6.

Citation Information

Patent Citations

  • Method, device and system for realizing document lock based on WebSocket, and storage medium

    CN110324387A

  • Resource cooperation method, resource cooperation device, computer equipment and storage medium

    CN111190742A