Method for document multi-version tracking and permission control based on document hash

Abstract

The present invention relates to the technical field of multi-version document permission management, and specifically to a method for implementing document multi-version tracking and permission management based on document hash, the method comprising: receiving a permission application for a current document from a current user, wherein the permission application includes a target operation type for the current document; when it is detected that there is no operation permission for the target operation type, obtaining a historical version change path from the document header information of the current document; each node in the historical version change path corresponds to a historical version of the current document, and each node includes a historical user of the current historical version and a corresponding permission label, wherein the permission label indicates whether the historical user has all preset operation permissions of the current historical version; according to the historical version change path, the historical users corresponding to each node and the permission labels, determining the historical user who receives the permission application, and sending the permission application to the determined historical user. The present invention can improve the reliability of permission control.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-version document permission management, and in particular to a method for implementing document multi-version tracking and permission management based on document hash. Background Art

[0002] With the popularization of informatization, all enterprises have realized paperless office in the entire process, generating countless original electronic files. At the same time, the use of various convenient office software allows everyone to more easily obtain other people's electronic documents, quickly copy, paste and modify them into their own documents, and use them for daily use such as work, publishing, and rating.

[0003] Currently, document permissions are primarily controlled through passwords, which restrict user access to documents through encryption. However, this approach presents a problem: if a document with password-based permissions is cracked or the password is leaked, the document's permissions become uncontrollable, and the creator loses control over the document's dissemination. Therefore, password-based permission control is less reliable. Summary of the Invention

[0004] In order to solve the technical problem of low reliability of permission control by setting passwords, the purpose of the present invention is to provide a method for document multi-version tracking and permission management based on document hash. The technical solution adopted is as follows:

[0005] In a first aspect of the present disclosure, a method for implementing document multi-version tracking and permission management based on document hash is provided, the method comprising:

[0006] Receive a permission application from a current user for a current document, wherein the permission application includes a target operation type for the current document;

[0007] Detecting whether the current user has the operation authority of the target operation type on the current document;

[0008] When it is detected that there is no operation permission for the target operation type, a historical version change path corresponding to the current document is obtained from the document header information of the current document; each node in the historical version change path corresponds to a historical version of the current document, and each node includes a historical user of the current historical version and a corresponding permission label, wherein the permission label indicates whether the historical user has all preset operation permissions for the current historical version;

[0009] According to the historical version change path, the historical users corresponding to each of the nodes and the permission tags, a historical user who receives the permission application is determined, and the permission application is sent to the determined historical user.

[0010] In one embodiment, detecting whether the current user has permission to operate the target operation type on the current document includes:

[0011] Obtaining the account information of the current user;

[0012] Obtaining target account information, target document unique hash identifier, and target operation permissions of a first target historical user corresponding to the last historical version from the document header information of the current document, wherein the document header information also includes document information corresponding to each of the historical versions stored sequentially, the document information including: the account information of the historical user of the current historical version, the unique hash identifier of the document of the current historical version, and the operation permissions of the historical user for the current historical version;

[0013] It is detected whether the current user has the operation authority of the target operation type on the current document according to the current user's account information and the target account information.

[0014] In one embodiment, detecting that there is no operation permission for the target operation type includes:

[0015] Detecting whether the current user's account information is the same as the target account information;

[0016] If they are not the same, it is determined that there is no operation permission for the target operation type;

[0017] If they are the same, determining whether the target operation type is included in the target operation permission;

[0018] If included, after the current user completes editing the current document, obtain the latest document unique Hash identifier corresponding to the edited current document, and use the latest document unique Hash identifier to replace the target document unique Hash identifier stored in the document header information;

[0019] If not, it is determined that there is no operation permission for the target operation type.

[0020] In one embodiment, determining the historical user who receives the permission application based on the historical version change path, the historical user corresponding to each node, and the permission label, and sending the permission application to the determined historical user includes:

[0021] Obtaining the permission tag sequence corresponding to each of the historical users;

[0022] Obtaining the application request level corresponding to each historical user according to the permission tag sequence corresponding to each historical user;

[0023] Arrange the application request levels corresponding to all the historical users in ascending order to obtain a permission application sending queue;

[0024] According to the order of the permission application sending queue, the permission application is sent to the corresponding historical users in sequence. After each sending, if an authorization instruction is received from the corresponding historical user, the permission application is stopped. If the authorization instruction is not received, the permission application is continued to be sent to the next historical user until the authorization instruction is received;

[0025] Output the authorization instruction.

[0026] In one embodiment, after outputting the authorization instruction, the method further includes:

[0027] receiving the current document updated by the current user using the target operation type;

[0028] Obtain the unique Hash identifier of the updated document corresponding to the updated current document;

[0029] Recording the target document's unique Hash identifier as a document parent identifier in the document header information, and replacing the target document's unique Hash identifier in the document header information with the updated document's unique Hash identifier;

[0030] Detecting whether an operation authority category change instruction is received; the operation authority category change instruction includes the operation authority type to be changed;

[0031] If not received, the updated current document inherits the target operation permission;

[0032] If received, the target operation permission is changed according to the type of the operation permission to be changed, and the changed target operation permission is used as the updated operation permission of the current document.

[0033] In one embodiment, obtaining the application request level corresponding to each historical user according to the permission tag sequence corresponding to each historical user includes:

[0034] Perform the following steps for each permission tag sequence corresponding to the historical user:

[0035] Obtain the frequency of occurrence of a first value in a permission tag sequence corresponding to the current historical user; if the current historical user has all preset operation permissions for the current historical version, the permission tag is the first value; if the current historical user does not have all preset operation permissions for the current historical version, the permission tag is the second value;

[0036] Obtaining the node order corresponding to the first value in the permission tag sequence corresponding to the current historical user in the historical version change path;

[0037] The application request level corresponding to the current historical user is obtained according to the frequency, the preset frequency weight, the node order and the node order weight.

[0038] In one embodiment, sending the permission applications to the corresponding historical users in sequence according to the order of the permission application sending queue includes:

[0039] During the sending process, check whether there are multiple second target historical users in the current ranking;

[0040] If the current ranking corresponds to multiple second target historical users;

[0041] Obtaining the sending subqueue corresponding to the second target historical user;

[0042] According to the order of the sending sub-queues, the permission applications are sent to the corresponding second target historical users in sequence.

[0043] In one embodiment, obtaining the sending subqueue corresponding to the second target historical user includes:

[0044] Obtain the permission label corresponding to each of the second target historical users in the last historical version;

[0045] From the second target historical users, obtain a first sub-target historical user whose authority tag has the first value and a second sub-target historical user whose authority tag has the second value;

[0046] Obtaining a first sending priority value corresponding to each of the first sub-target historical users and a second sending priority value corresponding to each of the second sub-target historical users;

[0047] The sending subqueue is obtained according to the first sending priority value and the second sending priority value, wherein the second sending priority value is located after the first sending priority value.

[0048] In one embodiment, obtaining the sending subqueue according to the first sending priority value and the second sending priority value, wherein the second sending priority value is located after the first sending priority value, includes:

[0049] Sort the first sending priority values ​​in descending order to obtain a first sub-sending queue;

[0050] Sort the second sending priority values ​​in ascending order to obtain a second sub-sending queue;

[0051] The sending sub-queue is acquired according to the first sending sub-queue and the second sending sub-queue, wherein the second sending sub-queue is located after the first sending sub-queue.

[0052] In one embodiment, obtaining the first sending priority value corresponding to each of the first sub-target historical users and the second sending priority value corresponding to each of the second sub-target historical users includes:

[0053] For each historical user of the first sub-target, sequentially traverse the permission tags in each of the previous historical versions until the permission tag corresponding to the historical user of the first sub-target is the second value, record the first sequence length; and obtain the first sending priority value based on the first sequence length.

[0054] For each of the second sub-target historical users, the permission tags in the previous historical versions are traversed in turn until the permission tag corresponding to the second sub-target historical user is the first value, and the second sequence length is recorded; the second sending priority value is obtained according to the second sequence length.

[0055] The present invention has the following beneficial effects:

[0056] The present disclosure can limit other users' related operations on their own documents by setting the operation permissions of the document. By setting the document permissions, the document creator can well control the dissemination of the document, solving the problem of low reliability of permission control through passwords, because any operation on the document that does not require set permissions must be authorized by the document creator, and by adding the historical version change path corresponding to the current document in the document header information, the historical versions of the document can be tracked. If the user needs to edit the document, the historical version permissions can be analyzed to determine to whom the user who currently needs to apply for permission should submit the relevant permission application. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In order to more clearly illustrate the technical solutions and advantages of the embodiments of the present invention or the prior art, the following briefly introduces the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0058] Figure 1A method for implementing document multi-version tracking and permission management based on document hashing provided by an embodiment of the present invention Figure 1 ;

[0059] Figure 2 A method for implementing document multi-version tracking and permission management based on document hashing provided by an embodiment of the present invention Figure 2 ;

[0060] Figure 3 A method for implementing document multi-version tracking and permission management based on document hashing provided by an embodiment of the present invention Figure 3 ;

[0061] Figure 4 A method for implementing document multi-version tracking and permission management based on document hashing provided by an embodiment of the present invention Figure 4 ;

[0062] Figure 5 Schematic diagram of document header information provided by one embodiment of the present invention Figure 1 ;

[0063] Figure 6 Schematic diagram of document header information provided by one embodiment of the present invention Figure 2 ;

[0064] Figure 7 A topological diagram of document header information provided by one embodiment of the present invention;

[0065] Figure 8 A schematic diagram of a historical version change path provided by one embodiment of the present invention;

[0066] Figure 9 A schematic diagram of the system structure for implementing document multi-version tracking and permission management based on document hashing, provided by one embodiment of the present invention. DETAILED DESCRIPTION

[0067] In order to further illustrate the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the following, in conjunction with the accompanying drawings and preferred embodiments, describes in detail the specific implementation method, structure, features and effects of the method for implementing document multi-version tracking and permission management based on document hash proposed by the present invention. In the following description, different "one embodiment" or "another embodiment" does not necessarily refer to the same embodiment. In addition, specific features, structures or characteristics in one or more embodiments may be combined in any suitable form.

[0068] Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

[0069] The following describes in detail the specific solution of the method for implementing document multi-version tracking and permission management based on document hash provided by the present invention in conjunction with the accompanying drawings.

[0070] See also Figure 1 , which shows a flow chart of a method for implementing document multi-version tracking and permission management based on document hashing provided by an embodiment of the present invention, such as Figure 1 As shown, the method includes the following steps S101-S104:

[0071] S101: Receive a permission application from a current user for a current document, where the permission application includes a target operation type for the current document.

[0072] S102: Check whether the current user has the operation authority of the target operation type for the current document.

[0073] In one embodiment, Figure 2 As shown, detecting whether the current user has the operation permission of the target operation type on the current document includes the following sub-steps S1021-S1023:

[0074] S1021. Obtain the current user's account information.

[0075] S1022. Obtain the target account information, target document unique hash identifier and target operation authority of the first target historical user corresponding to the last historical version from the document header information of the current document. The document header information also includes the document information corresponding to each historical version saved in sequence. The document information includes: the account information of the historical user of the current historical version, the unique hash identifier of the document of the current historical version, and the operation authority of the historical user for the current historical version.

[0076] When creating a document, the user who created the document is regarded as the creator. After the creator edits the document and saves it, a unique hash identifier is generated for the document through the hash algorithm. The creator can be given all the preset operation permissions of the document, including editing, selecting, modifying, viewing, adding, deleting users, etc. Other users are only given viewing permissions to ensure the copyright of the document. After the creator creates the document, the document now belongs to the first historical version. The second user can only view the first historical version. If the second user wants to edit the first historical version, they need to apply for the corresponding permission from the creator. If the creator agrees that the second user can edit the first historical version, the second user is authorized. At this time, the second user can edit the first historical version. After the second user edits the first historical version and saves it, the result is the second historical version. At this time, the third user can only view the second historical version. If the third user wants to edit the second historical version, he can apply for the corresponding permission from the second user. If the second user agrees that the third user can edit, the third user is authorized. The third user can edit the second historical version.

[0077] In the present disclosure, a permission tag may be used to indicate whether a user has all preset operation permissions for the current document. When the user has all preset operation permissions for the current document, the permission tag is a first value, for example, the first value may be 1. When the user does not have all preset operation permissions for the current document, the permission tag is a second value, for example, the second value may be 0.

[0078] When the user completes the document-related operations and closes the document, the user will be regarded as the last editor, and the above-mentioned document unique hash identifier, permission label and account information of the current document editor will be stored in the document header information. Every time the user operates the document and then closes it, the corresponding information will be stored in the document header information, so that the historical version change path corresponding to the document can be obtained from the document header information.

[0079] S1023. Detect, based on the current user's account information and the target account information, whether the current user has the operation authority of the target operation type for the current document.

[0080] When a user performs relevant operations on the current document, the current user's account information is read, and the target account information of the first target historical user corresponding to the last historical version is read from the document header information, that is, the last editor information is read from the document header information, and then based on the current user's account information and the last editor information, it is detected whether the current user has the operation permission of the target operation type for the current document.

[0081] S103. When it is detected that there is no operation permission for the target operation type, the historical version change path corresponding to the current document is obtained from the document header information of the current document; each node in the historical version change path corresponds to a historical version of the current document, and each node includes the historical user of the current historical version and the corresponding permission label, wherein the permission label indicates whether the historical user has all preset operation permissions for the current historical version.

[0082] After obtaining the current user's account information and the target account information, you need to perform the following steps A1-A5:

[0083] A1. Check whether the current user's account information is the same as the target account information. If they are not the same, proceed to step A2. If they are the same, proceed to step A3.

[0084] A2. Make sure you do not have the permission to operate the target operation type.

[0085] A3. Determine whether the target operation type is included in the target operation permission. If yes, go to step A4; if no, go to step A5.

[0086] A4. After the current user completes editing the current document, the latest document unique hash identifier corresponding to the edited current document is obtained, and the latest document unique hash identifier is used to replace the target document unique hash identifier stored in the document header information.

[0087] A5. Make sure you do not have permission to perform the target operation.

[0088] In this step, if the current user is the last editor of the current document, it is also necessary to determine whether the current user's target operation type for the current document complies with the target operation permissions corresponding to the current document. If it complies with the target operation permissions, the latest document unique hash identifier is calculated for the updated current document, and only the target document unique hash identifier in the document header information is updated. If the operation permissions are updated, the target operation permissions can also be updated; if it does not comply with the target operation permissions, the document header information remains unchanged.

[0089] S104: Determine the historical user who receives the permission application based on the historical version change path, the historical users corresponding to each node, and the permission tags, and send the permission application to the determined historical user.

[0090] When the current user does not have the operation permission for the target operation type, it is necessary to apply to the historical user with permission to release the operation permission for the target operation type. At this time, the historical user who receives the permission application can be determined based on the historical version change path, the historical users corresponding to each node, and the permission tags, and the permission application can be sent to the determined historical user.

[0091] The present disclosure can limit other users' related operations on their own documents by setting the operation permissions of the document, and can track the historical versions of the document by adding the historical version change path corresponding to the current document in the document header information. If the user needs to edit the document, the historical version permissions can be analyzed to determine to whom the user who currently needs to apply for permission should submit the relevant permission application.

[0092] Due to the large number of template documents in actual work needs, these template documents need to be modified, created, and other forms of new documents. This results in a large number of template document branches, and the document propagation presents a tree structure. The historical information of each version of the document is a branch to the root node of this attribute structure.

[0093] Because public documents or template documents exist, or because previous template documents are reused, anyone can edit them, making such documents relatively easy to spread widely. The document tree structure of such documents is relatively large, and the document version obtained by the user may be any version in the tree. When a user needs to apply for relevant document permissions, they submit the application to the creator of the document (i.e., the root node). All permission application requests will be sent to the creator node, causing the permission application to stagnate. In addition, the creator may create a public document when creating the document, allowing everyone to edit the document. Document permission restrictions only appear in subsequent versions of the document.

[0094] For example, if a template document is provided by the government, the enterprise will only start to restrict the permissions after obtaining the provided template document. In this case, the application request should not be sent to the document creator. The specific sending request judgment is as follows: Figure 3 As shown, the following sub-steps S1041-S1045 are included:

[0095] S1041. Obtain the permission tag sequence corresponding to each historical user.

[0096] After obtaining the historical version change path from the document header information of the current document, since the current user does not have the corresponding target operation permission, the current version of the document must not be a public document. Traverse the historical version change path from the leaf node to the root node. Each node represents the historical version corresponding to the current document. Select a node in the traversal process and obtain the operation permission labels of all users under the historical version. Verify that these permission labels are all 1.

[0097] If it is not 1, it means that the historical version of the node is not a public document, and the node traversal process continues.

[0098] If both are 1, it means that anyone has full permissions to the document in the historical version corresponding to the node, so it is a template public document. At this time, traversal stops, or traversal stops when it reaches the root node.

[0099] Thus, a local path in the historical version is obtained, and the path represents the historical version information of the document transformed from the template document to the private document.

[0100] For the version paths obtained by the above traversal, the permission label sequences of each historical user in these versions are obtained, as shown in Table 1.

[0101] Table 1

[0102] Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Node 8 User 1 1 1 1 1 1 1 1 1 User 2 0 0 0 1 1 1 1 1 User 3 0 0 0 0 0 0 0 1 User 4 1 1 1 1 1 1 1 1 User 5 0 0 0 0 0 0 0 0 User 6 0 0 0 0 0 0 1 1

[0103] S1042. Obtain the application request level corresponding to each historical user according to the permission tag sequence corresponding to each historical user.

[0104] In one embodiment, Figure 4 As shown, the application request level corresponding to each historical user is obtained according to the permission tag sequence corresponding to each historical user, including performing the following sub-steps S10421-S10423 on the permission tag sequence corresponding to each historical user:

[0105] S10421. Obtain the frequency of occurrence of the first value in the permission label sequence corresponding to the current historical user; if the current historical user has all preset operation permissions for the current historical version, the permission label is the first value; if the current historical user does not have all preset operation permissions for the current historical version, the permission label is the second value.

[0106] S10422. Obtain the node order corresponding to the first value in the permission tag sequence corresponding to the current historical user in the historical version change path.

[0107] S10423. Obtain the application request level corresponding to the current historical user according to the frequency, the preset frequency weight, the node order, and the node order weight.

[0108] When calculating the request level for each historical user, if the historical user has a value of 1 and the more permission tags the node is positioned at the front, it means that the document tree structure formed by multiple historical versions is closer to the root node. Therefore, the historical user has more branches of multiple historical versions of the document processed. When applying for permissions, the user will face permission requests from users with more historical versions. To alleviate the possibility of facing more permission requests from other users, the permission application for the historical user needs to be postponed. As a result, the historical user's request level is higher and is sent later than the current user's permission request.

[0109] Get the permission tags corresponding to different historical users from the permission tags in the document header information, obtain the permission tag sequence corresponding to each historical user, and use the following formula to get the application request level corresponding to the current historical user:

[0110]

[0111] Among them, a is the application request level of the current historical user, p is the frequency of 1 in the permission label sequence of the current historical user, and i is the node order corresponding to the appearance of 1 in the permission label sequence of the current historical user. The smaller the value, the closer to the root node; x1 is the frequency weight, and x2 is the node order weight. For example, the frequency weight and node order weight can both be 1 / 2, but in actual application scenarios, they can also be adjusted according to the actual permission applications received by the user or the estimated size of the historical version of the document.

[0112] S1043. Arrange the application request levels corresponding to all historical users in ascending order to obtain a permission application sending queue.

[0113] The higher the application request level, the later the historical user's permission application will be sent; the lower the application request level, the fewer historical versions of documents the historical user faces and the fewer permission applications he or she will apply for. Therefore, priority should be given to sending permission applications to such historical users.

[0114] Therefore, each historical user corresponds to a permission application request level, and the application request levels are arranged in ascending order as a permission application sending queue.

[0115] S1044. According to the order of the permission application sending queue, the permission application is sent to the corresponding historical users in sequence. After each sending, if an authorization instruction is received from the corresponding historical user, the sending is stopped. If no authorization instruction is received, the permission application is continued to be sent to the next historical user until an authorization instruction is received.

[0116] After obtaining the permission application sending queue corresponding to each historical user, send the permission application to the historical user at the front of the permission application sending queue, set the maximum reply time, and if there is no corresponding reply after the maximum time, send the permission application to the next historical user, and repeat the process.

[0117] When different historical users have the same application request level a, the method includes the following steps B1-B4:

[0118] B1. During the sending process, check whether there are multiple second target historical users in the current ranking.

[0119] B2. If the current ranking corresponds to multiple second target historical users;

[0120] B3. Obtain the sending subqueue corresponding to the second target historical user.

[0121] When it is detected that there are multiple second target historical users in the same ranking, it indicates that there will be a conflict in the order of sending permission requests. It is also necessary to obtain the sending sub-queues corresponding to these second target historical users, and then send the permission application based on the sending sub-queues corresponding to the second target historical users.

[0122] In one embodiment, obtaining the sending subqueue corresponding to the second target historical user includes the following sub-steps B31-B34:

[0123] B31. Obtain the permission tags corresponding to each second target historical user in the last historical version.

[0124] B32. From the second target historical users, obtain the first sub-target historical users whose authority tags have a first value and the second sub-target historical users whose authority tags have a second value.

[0125] Among the second target historical users, it is necessary to obtain the first sub-target historical users whose authority tags have a value of 1, and the second sub-target historical users whose authority tags have a value of 0.

[0126] B33. Obtain a first sending priority value corresponding to each first sub-target historical user and a second sending priority value corresponding to each second sub-target historical user.

[0127] Get all the second target historical users at the same level, and traverse forward step by step from the permission label corresponding to the leaf node:

[0128] Case 1: For each historical user of the first sub-target, traverse the permission tags in the previous historical versions in turn until the permission tag corresponding to the historical user of the first sub-target is the second value, and record the first sequence length; obtain the first sending priority value based on the first sequence length.

[0129] If in the most recent historical version, the permission label corresponding to the first sub-target historical user is 1, it means that the first sub-target historical user has management authority over the document in the historical version. Continue to traverse forward until the label 0 of the first sub-target historical user is encountered or the traversal of the entire permission label sequence stops, and record the first sequence length L0 at the time of stopping.

[0130] Case 2: For each historical user of the second sub-target, the permission tags in the previous historical versions are traversed in turn until the permission tag corresponding to the historical user of the second sub-target is the first value, and the second sequence length is recorded; the second sending priority value is obtained according to the second sequence length.

[0131] If the permission label of the second sub-target historical user is 0 in the most recent historical version, it means that the second sub-target historical user does not have management authority over the document in the most recent historical version. At this time, continue to traverse forward until it reaches 1 or stops after traversing the entire permission label sequence. Also record the second sequence length L1 of the traversal when stopping.

[0132] Since the first sub-target historical user in case 1 has document management authority in the historical version, if there is a conflict in the sending level, priority should be given to determining whether the historical user belongs to case 1. If so, a higher sending order should be given compared to case 2. For case 2, the second sub-target historical user does not have the corresponding document management authority in the historical version, but has the corresponding document control authority in the document of the historical version, and the corresponding application sending order is smaller overall.

[0133] For the first sub-target historical user in the conflict in Case 1, the longer the length L0 of the first sequence is, the more historical versions the first sub-target historical user needs to deal with, and the lower the priority of sending. The first sending priority value of the permission application is obtained by the following formula:

[0134] y = 1 - f(a × L0);

[0135] Among them, y is the first sending priority value of the permission application of the first sub-target historical user, L0 is the first sequence length of the first sub-target historical user, f() is the positive correlation normalization function, and a is the application request level of the first sub-target historical user.

[0136] For the second sub-target historical user that is in conflict with Case 2, the longer the second sequence length of the second sub-target historical user is, the less likely the second sub-target historical user is to have corresponding document management permissions in multiple historical versions, and thus the lower the priority of sending. At the same time, in order to resolve the user permission application issue as quickly as possible, in this case, priority is given to applying for permissions at a higher application level. The second sending priority value is obtained using the following formula:

[0137]

[0138] Among them, y is the second sending priority value of the permission application of the second sub-target historical user, f() is the positive correlation normalization function, L1 is the second sequence length of the second sub-target historical user, and a is the application request level of the second sub-target historical user.

[0139] B34. Obtain a sending subqueue according to the first sending priority value and the second sending priority value, wherein the second sending priority value is located after the first sending priority value.

[0140] In one embodiment, step B34 includes the following sub-steps B341-B343:

[0141] B341. Sort the first sending priority values ​​in descending order to obtain a first sub-sending queue;

[0142] B342. Sort the second sending priority values ​​in ascending order to obtain a second sub-sending queue;

[0143] B343. Acquire a sending subqueue according to the first sending subqueue and the second sending subqueue, wherein the second sending subqueue is located after the first sending subqueue.

[0144] B4. Send the permission application to the corresponding second target historical user in sequence according to the order of the sending sub-queue.

[0145] If there is a conflict in the sending order of historical users during the permission application process, situation 1 will be executed first, and the sending priority value of the first sub-target historical user will be obtained. The larger the value, the first one will be sent. If all the first sub-target historical users have not replied, the second sending sub-queue will be used for sending. If all the second sub-target historical users have not replied, the sending will continue according to the sending queue.

[0146] S1045: Output authorization instruction.

[0147] In one embodiment, after outputting the authorization instruction, the method further includes the following sub-steps S1046-S10411:

[0148] S1046: Receive the current document updated by the current user using the target operation type.

[0149] S1047. Obtain the unique Hash identifier of the updated document corresponding to the updated current document.

[0150] S1048. Record the target document's unique Hash identifier as the document's parent identifier in the document header information, and use the updated document's unique Hash identifier to replace the target document's unique Hash identifier in the document header information.

[0151] S1049: Detect whether an operation authority category change instruction is received; the operation authority category change instruction includes the operation authority type to be changed.

[0152] S10410. If not received, the updated current document inherits the target operation permission.

[0153] S10411. If received, change the target operation permission according to the type of the operation permission to be changed, and use the changed target operation permission as the updated operation permission of the current document.

[0154] If the current user is not the last editor, and after obtaining authorization, updates and saves the current document using the target operation class, the current document's unique hash identifier is recorded in the document header as the updated document's parent identifier. The updated document's unique hash identifier replaces the target document's unique hash identifier in the document header, forming a new document header. The system also checks whether the current user has modified the current document's operational permissions. If not, the document's parent identifier is automatically recorded and the document inherits the parent document's operational permissions.

[0155] like Figure 5 As shown in , when creating a document, the creator saves the original document. The original document at this time is used as version 1 of the document. By performing a hash operation on the original document of version 1, the unique hash identifier of version 1 corresponding to the original document of version 1 is obtained, and the creator's account information, permission label and target operation type are recorded in the permission class of version 1. If a user edits the original document of version 1 and saves it, the original document of version 2 is obtained, as shown in Figure 6 As shown, the document parent identifier is added to the document header information. The document parent identifier includes the version 1 document unique hash identifier and the permission class corresponding to version 1. By performing a hash operation on the version 2 document original text, the version 2 document unique hash identifier corresponding to the version 2 document original text is obtained. The version 1 document unique hash identifier in the document header information is updated to the version 2 document unique hash identifier, and the version 1 permission class in the document header information is updated to the version 2 permission class. In this example, the version 2 permission class inherits the version 1 permission class.

[0156] Through the above-mentioned document header information update scheme, multiple historical versions of the document are stored in the document header information of each document. Figure 6 You can get Figure 7 The document topology shown in the figure is Figure 6 The following information can be obtained: the unique hash identifier of the version 2 document, the unique hash identifier of the version 1 document, the unique hash identifier of the version 1 document as the parent document of the unique hash identifier of the version 2 document, and the permission classes corresponding to versions 1 and 2.

[0157] Each document obtains the historical version change path information of the document through the document header information, such as Figure 8 As shown, you can get the document header information after each edit, that is, the document header information corresponding to each version, Figure 8 The document header node in represents the document header information.

[0158] The present invention discloses a permission application method for multi-version documents, which realizes historical version tracking of document versions by storing historical version information in the document header information, and determines to whom the user who currently needs to apply for permission should apply for the relevant permission by analyzing the permissions of the user's historical version documents. The priority value of the application is obtained for each user, and a permission application solution is proposed when an application conflict or a response timeout occurs, thereby avoiding the phenomenon of very frequent permission applications for the document creator due to the spread of multi-version files, alleviating application pressure, and improving document security.

[0159] like Figure 9 As shown, the present disclosure also provides a system for document multi-version tracking and permission management based on document hash, the system comprising:

[0160] The receiving module 11 is configured to receive a permission application from a current user for a current document, wherein the permission application includes a target operation type for the current document;

[0161] A detection module 12 is used to detect whether the current user has the operation authority of the target operation type on the current document;

[0162] The acquisition module 13 is configured to, when detecting that the operation permission for the target operation type is not available, acquire a historical version change path corresponding to the current document from the document header information of the current document; each node in the historical version change path corresponds to a historical version of the current document, and each node includes a historical user of the current historical version and a corresponding permission tag, wherein the permission tag indicates whether the historical user has all preset operation permissions for the current historical version;

[0163] The determination module 14 is configured to determine a historical user who receives the permission application based on the historical version change path, the historical users corresponding to each node, and the permission tags, and send the permission application to the determined historical user.

[0164] In one embodiment, in terms of detecting whether the current user has the operation authority of the target operation type on the current document, the detection module 12 is specifically configured to:

[0165] Obtaining the account information of the current user;

[0166] Obtaining target account information, target document unique hash identifier, and target operation permissions of a first target historical user corresponding to the last historical version from the document header information of the current document, wherein the document header information also includes document information corresponding to each of the historical versions stored sequentially, the document information including: the account information of the historical user of the current historical version, the unique hash identifier of the document of the current historical version, and the operation permissions of the historical user for the current historical version;

[0167] It is detected whether the current user has the operation authority of the target operation type on the current document according to the current user's account information and the target account information.

[0168] In one embodiment, upon detecting that there is no operation permission for the target operation type, the acquisition module 13 is specifically configured to:

[0169] Detecting whether the current user's account information is the same as the target account information;

[0170] If they are not the same, it is determined that there is no operation permission for the target operation type;

[0171] If they are the same, determining whether the target operation type is included in the target operation permission;

[0172] If included, after the current user completes editing the current document, obtain the latest document unique Hash identifier corresponding to the edited current document, and use the latest document unique Hash identifier to replace the target document unique Hash identifier stored in the document header information;

[0173] If not, it is determined that there is no operation permission for the target operation type.

[0174] In one embodiment, in determining the historical user who receives the permission application based on the historical version change path, the historical user corresponding to each node, and the permission label, and sending the permission application to the determined historical user, the determination module 14 is specifically configured to:

[0175] Obtaining the permission tag sequence corresponding to each of the historical users;

[0176] Obtaining the application request level corresponding to each historical user according to the permission tag sequence corresponding to each historical user;

[0177] Arrange the application request levels corresponding to all the historical users in ascending order to obtain a permission application sending queue;

[0178] According to the order of the permission application sending queue, the permission application is sent to the corresponding historical users in sequence. After each sending, if an authorization instruction is received from the corresponding historical user, the permission application is stopped. If the authorization instruction is not received, the permission application is continued to be sent to the next historical user until the authorization instruction is received;

[0179] Output the authorization instruction.

[0180] In one embodiment, after outputting the authorization instruction, the determination module 14 is further configured to:

[0181] receiving the current document updated by the current user using the target operation type;

[0182] Obtain the unique Hash identifier of the updated document corresponding to the updated current document;

[0183] Recording the target document's unique Hash identifier as a document parent identifier in the document header information, and replacing the target document's unique Hash identifier in the document header information with the updated document's unique Hash identifier;

[0184] Detecting whether an operation authority category change instruction is received; the operation authority category change instruction includes the operation authority type to be changed;

[0185] If not received, the updated current document inherits the target operation permission;

[0186] If received, the target operation permission is changed according to the type of the operation permission to be changed, and the changed target operation permission is used as the updated operation permission of the current document.

[0187] In one embodiment, in terms of obtaining the application request level corresponding to each historical user according to the permission tag sequence corresponding to each historical user, the determination module 14 is specifically configured to:

[0188] Perform the following steps for each permission tag sequence corresponding to the historical user:

[0189] Obtain the frequency of occurrence of a first value in a permission tag sequence corresponding to the current historical user; if the current historical user has all preset operation permissions for the current historical version, the permission tag is the first value; if the current historical user does not have all preset operation permissions for the current historical version, the permission tag is the second value;

[0190] Obtaining the node order corresponding to the first value in the permission tag sequence corresponding to the current historical user in the historical version change path;

[0191] The application request level corresponding to the current historical user is obtained according to the frequency, the preset frequency weight, the node order and the node order weight.

[0192] In one embodiment, in terms of sending the permission applications to the corresponding historical users in sequence according to the order of the sending queue, the determination module 14 is specifically configured to:

[0193] During the sending process, check whether there are multiple second target historical users in the current ranking;

[0194] If the current ranking corresponds to multiple second target historical users;

[0195] Obtaining the sending subqueue corresponding to the second target historical user;

[0196] According to the order of the sending sub-queues, the permission applications are sent to the corresponding second target historical users in sequence.

[0197] In one embodiment, in terms of obtaining the sending subqueue corresponding to the second target historical user, the determination module 14 is specifically configured to:

[0198] Obtain the permission label corresponding to each of the second target historical users in the last historical version;

[0199] From the second target historical users, obtain a first sub-target historical user whose authority tag has the first value and a second sub-target historical user whose authority tag has the second value;

[0200] Obtaining a first sending priority value corresponding to each of the first sub-target historical users and a second sending priority value corresponding to each of the second sub-target historical users;

[0201] The sending subqueue is obtained according to the first sending priority value and the second sending priority value, wherein the second sending priority value is located after the first sending priority value.

[0202] In one embodiment, after obtaining the sending subqueue according to the first sending priority value and the second sending priority value, wherein the second sending priority value is located after the first sending priority value, the determining module 14 is further configured to:

[0203] Sort the first sending priority values ​​in descending order to obtain a first sub-sending queue;

[0204] Sort the second sending priority values ​​in ascending order to obtain a second sub-sending queue;

[0205] The sending sub-queue is acquired according to the first sending sub-queue and the second sending sub-queue, wherein the second sending sub-queue is located after the first sending sub-queue.

[0206] In one embodiment, in terms of obtaining the first sending priority value corresponding to each of the first sub-target historical users and the second sending priority value corresponding to each of the second sub-target historical users, the determination module 14 is specifically configured to:

[0207] For each historical user of the first sub-target, sequentially traverse the permission tags in each of the previous historical versions until the permission tag corresponding to the historical user of the first sub-target is the second value, record the first sequence length; and obtain the first sending priority value based on the first sequence length.

[0208] For each of the second sub-target historical users, the permission tags in the previous historical versions are traversed in turn until the permission tag corresponding to the second sub-target historical user is the first value, and the second sequence length is recorded; the second sending priority value is obtained according to the second sequence length.

[0209] It should be noted that the order in which the embodiments of the present invention are described above is for illustrative purposes only and does not necessarily represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0210] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

Claims

1. A method for document multi-version tracking and permission management based on document hash, characterized in that: The method comprises: Receive the current user's permission request for the current document, which includes the target operation type for the current document; Detecting whether the current user has the target operation type operation permission for the current document; including: obtaining the current user's account information; obtaining the target account information, target document unique Hash identifier and target operation permission of the first target historical user corresponding to the last historical version from the document header information of the current document, wherein the document header information also includes document information corresponding to each historical version saved in sequence, and the document information includes: the account information of the historical user of the current historical version, the unique Hash identifier of the document of the current historical version, and the historical user's operation permission for the current historical version; detecting whether the current user has the target operation type operation permission for the current document based on the current user's account information and the target account information; When it is detected that there is no operation permission for the target operation type, the historical version change path corresponding to the current document is obtained from the document header information of the current document; each node in the historical version change path corresponds to a historical version of the current document, and each node includes the historical user of the current historical version and the corresponding permission label, wherein the permission label indicates whether the historical user has all preset operation permissions for the current historical version; According to the historical version change path, the historical users and permission tags corresponding to each node, the historical users who receive the permission application are determined, and the permission application is sent to the determined historical users; including: obtaining the permission tag sequence corresponding to each historical user; obtaining the application request level corresponding to each historical user according to the permission tag sequence corresponding to each historical user; arranging the application request levels corresponding to all historical users in order from small to large to obtain a permission application sending queue; sending the permission application to the corresponding historical users in sequence according to the sorting of the permission application sending queue. After each sending, if an authorization instruction returned by the corresponding historical user is received, the sending is stopped. If no authorization instruction is received, the permission application is continued to be sent to the next historical user until an authorization instruction is received; and the authorization instruction is output.

2. The method for implementing document multi-version tracking and authority management based on document hash according to claim 1 is characterized in that: The detection of not having the operation permission of the target operation type includes: Check whether the current user's account information is the same as the target account information; If they are not the same, it is determined that there is no operation permission for the target operation type; If they are the same, determine whether the target operation type is included in the target operation permission; If included, after the current user completes editing the current document, obtain the latest document unique hash identifier corresponding to the edited current document, and use the latest document unique hash identifier to replace the target document unique hash identifier stored in the document header information; If not, it is determined that there is no operation permission for the target operation type.

3. The method for implementing document multi-version tracking and authority management based on document hash according to claim 1 is characterized in that: After outputting the authorization instruction, the method further includes: receiving the current document updated by the current user using the target operation type; Obtain the unique Hash identifier of the updated document corresponding to the updated current document; Recording the target document's unique Hash identifier as a document parent identifier in the document header information, and replacing the target document's unique Hash identifier in the document header information with the updated document's unique Hash identifier; Detecting whether an operation authority category change instruction is received; the operation authority category change instruction includes the operation authority type to be changed; If not received, the updated current document inherits the target operation permission; If received, the target operation permission is changed according to the type of the operation permission to be changed, and the changed target operation permission is used as the updated operation permission of the current document.

4. The method for implementing document multi-version tracking and authority management based on document hash according to claim 3 is characterized in that: The step of obtaining the application request level corresponding to each historical user according to the permission tag sequence corresponding to each historical user includes: Perform the following steps for each historical user's corresponding permission tag sequence: Get the frequency of the first value in the permission tag sequence corresponding to the current historical user; if the current historical user has all preset operation permissions for the current historical version, the permission tag is the first value; if the current historical user does not have all preset operation permissions for the current historical version, the permission tag is the second value; Get the node order corresponding to the first value in the permission tag sequence corresponding to the current historical user in the historical version change path; Obtain the application request level corresponding to the current historical user based on frequency, preset frequency weight, node order, and node order weight.

5. The method for implementing document multi-version tracking and authority management based on document hash according to claim 4 is characterized in that: The step of sending the permission application to the corresponding historical users in sequence according to the order of the permission application sending queue includes: During the sending process, check whether there are multiple second target historical users in the current ranking; If the current ranking corresponds to multiple second target historical users; Get the sending subqueue corresponding to the second target historical user; According to the order of the sending sub-queues, the permission applications are sent to the corresponding second target historical users in sequence.

6. The method for implementing document multi-version tracking and authority management based on document hash according to claim 5 is characterized in that: The obtaining of the sending subqueue corresponding to the second target historical user includes: Get the permission tags corresponding to each second target historical user in the last historical version; Among the second target historical users, obtain the first sub-target historical users whose authority tags have a first value and the second sub-target historical users whose authority tags have a second value; Obtaining a first sending priority value corresponding to each first sub-target historical user and a second sending priority value corresponding to each second sub-target historical user; A sending subqueue is acquired according to a first sending priority value and a second sending priority value, wherein the second sending priority value is located after the first sending priority value.

7. The method for implementing document multi-version tracking and authority management based on document hash according to claim 6 is characterized in that: The acquiring the sending subqueue according to the first sending priority value and the second sending priority value, wherein the second sending priority value is located after the first sending priority value, includes: Sort the first sending priority values ​​in descending order to obtain a first sub-sending queue; Sort the second sending priority values ​​in ascending order to obtain a second sub-sending queue; A sending sub-queue is acquired according to the first sending sub-queue and the second sending sub-queue, wherein the second sending sub-queue is located after the first sending sub-queue.

8. The method for implementing document multi-version tracking and authority management based on document hash according to claim 6 is characterized in that: The obtaining of the first sending priority value corresponding to each first sub-target historical user and the second sending priority value corresponding to each second sub-target historical user includes: For each historical user of the first sub-target, sequentially traverse the permission tags in each previous historical version until the permission tag corresponding to the historical user of the first sub-target is the second value, and record the first sequence length; obtain the first sending priority value based on the first sequence length; For each second sub-target historical user, the permission tags in the previous historical versions are traversed in sequence until the permission tag corresponding to the second sub-target historical user is the first value, and the second sequence length is recorded; the second sending priority value is obtained according to the second sequence length.

Images