Method for realizing document multi-version tracking and authority control based on document Hash

Abstract

The invention relates to the technical field of multi-version document permission management and control, in particular to a method for achieving document multi-version tracking and permission management and control based on document Hash, and the method comprises the steps that a permission application of a current user for a current document is received, and the permission application comprises a target operation type for the current document; when it is detected that the operation authority of the target operation type does not exist, a historical version change path is obtained from document header information of the current document; each node in the historical version change path corresponds to a historical version of the current document, each node comprises a historical user of the current historical version and a corresponding permission label, and the permission label represents whether the historical user has all preset operation permissions of the current historical version; and according to the historical version change path, the historical user corresponding to each node and the permission label, determining the historical user receiving the permission application, and sending the permission application to the determined historical user. The authority control reliability can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of multi-version document permission management and control, 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 whole process, and generated 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, and quickly copy, paste and modify them into their own documents for daily use such as work, publishing, and rating.

[0003] Currently, the permission control of documents is mainly achieved by setting passwords, which restricts users' related operations on documents through encryption. However, this has the following problems: once a document with permission control by password is cracked or the password is leaked, the permission control of the document will be out of control, and the creator will lose the ability to control the dissemination of the document. Therefore, the permission control by setting passwords 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 control 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 for the current document;

[0008] 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 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, the detecting whether the current user has the operation authority of the target operation type on the current document includes:

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

[0012] Obtaining 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, wherein the document header information also includes the document information corresponding to each of the historical versions stored in sequence, and the document information includes: the account information of the historical user of the current historical version, the document unique Hash identifier of the current historical version, and the operation authority of the historical user on 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 account information of the current user and the target account information.

[0014] In one embodiment, the 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 according to the historical version change path, the historical users corresponding to each of the nodes, and the permission tags, and sending the permission application to the determined historical user includes:

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

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

[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 returned by the corresponding historical user is received, the sending 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] The authorization instruction is output.

[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 unique Hash identifier as a document parent identifier in the document header information, and replacing the target document unique Hash identifier in the document header information with the updated document 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, acquiring the application request level corresponding to each of the historical users according to the permission tag sequence corresponding to each of the historical users includes:

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

[0035] Obtaining 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 the preset operation permissions for the current historical version, the permission tag is the first value; if the current historical user does not have all the preset operation permissions for the current historical version, the permission tag is the second value;

[0036] 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;

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

[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, it is detected 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 a 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] Obtaining 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 a value of the first value and a second sub-target historical user whose authority tag has a value of 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, 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:

[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, the acquiring of 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 of the first sub-target historical users, sequentially traverse the permission tags in each of the previous historical versions until the permission tag corresponding to the first sub-target historical user is the second value, and record the first sequence length; obtain the first sending priority value according to the first sequence length;

[0054] 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.

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

[0056] The present invention 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 control the dissemination of the document well, which solves the problem of low reliability of permission control through passwords, because any operation on the document that does not require the 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 in the embodiments of the present invention or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. 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 creative work.

[0058] Figure 1A method flow 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 flow 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 flow 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 flow 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 an embodiment of the present invention Figure 1 ;

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

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

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

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

[0067] In order to further explain the technical means and effects adopted by the present invention to achieve the predetermined purpose of the invention, the method for realizing document multi-version tracking and permission management based on document hash proposed by the present invention, its specific implementation method, structure, features and effects are described in detail as follows in combination with the accompanying drawings and preferred embodiments. 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 specific scheme of the method for implementing document multi-version tracking and permission management based on document Hash provided by the present invention is described in detail below with reference to the accompanying drawings.

[0070] See also Figure 1 , which shows a flow chart of a method for implementing document multi-version tracking and authority 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 for a current document from a current user, where the permission application includes a target operation type for the current document.

[0072] S102: Detect 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 authority of the target operation type for the current document includes the following sub-steps S1021-S1023:

[0074] S1021. Obtain the account information of the current user.

[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 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 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 at this time 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, he needs 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 second historical version is obtained. At this time, the third user can only view the second historical version. If the third user wants to edit the second historical version, the corresponding permission can be applied to the second user. If the second user agrees that the third user can edit it, 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 document-related operations and closes the document, the user will be regarded as the last editor, and the document's unique hash identifier, permission label, and account information of the current document's editor will be stored in the document header information. Every time a user operates a document and then closes it, the corresponding information will be stored in the document header information, so that the corresponding historical version change path of 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 information of the last editor is read from the document header information, and then based on the current user's account information and the last editor's information, it is detected whether the current user has the operation authority 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 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.

[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, execute step A2. If they are the same, execute 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 so, execute step A4. If not, execute 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 the permission to operate the target operation type.

[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 according to 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] Since there are a large number of template documents in actual work needs, such template documents need to be modified, created, etc. to form new documents. This results in a large number of template document branches, and the propagation of documents presents a tree structure. The historical information of each version of the document is a branch to the root node of the attribute structure.

[0093] Due to the existence of public documents or template documents, or the reuse of previous template documents, everyone can edit them, so such documents are relatively easy to spread widely. The document tree structure of such documents is large, and the document version obtained by the user may be any version in the tree. When the user needs to apply for relevant document permissions, he submits the relevant document application to the creator of the document (that is, the root node). All permission application requests will be sent to the creator node, causing the permission application to stagnate; and the creator may create a public document when creating the document, allowing everyone to edit the document. Restrictions on document permissions will only appear in subsequent versions of the document.

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

[0095] S1041. Obtain the permission label 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 from the leaf node of the historical version change path to the root node. Each node represents the historical version corresponding to the current document. Select a node in the traversal process to obtain the operation permission labels of all users under the historical version, and verify whether 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 they are all 1, it means that in the historical version corresponding to this node, anyone has full permissions to the document, so it is a template public document. At this time, the traversal stops, or the traversal reaches the root node and stops.

[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 executing the following sub-steps S10421-S10423 for 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 label 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 application request level of each historical user, if the historical user value is 1, the more permission tags and the more nodes are in front, it means that the document tree structure formed in the multiple historical versions is closer to the root node, so the historical user has more branches of multiple historical versions of the document processed. When applying for permissions, he will face permission applications from users with more historical versions. In order to alleviate the permission applications that the historical user may face from more other users, it is necessary to postpone the permission application for the historical user. Therefore, the application request level of the historical user is higher and is later than the permission application request sent by the current user.

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

[0110]

[0111] Wherein, 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, i is the node order corresponding to the appearance of 1 in the permission label sequence of the current historical user, and 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 the node order weight can both be 1 / 2, but in actual application scenarios, they can also be adjusted according to the permission applications actually received by the user or the estimated size of the document of the historical version.

[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, so 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 necessary to obtain the sending subqueues corresponding to these second target historical users, and then send the permission application based on the sending subqueues 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 label 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, 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 need to be acquired.

[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 labels corresponding to the leaf nodes:

[0128] Case 1: For each first sub-target historical user, traverse the permission tags in the previous historical versions in turn until the permission tag corresponding to the first sub-target historical user 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 the 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 when 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 in the most recent historical version, the permission label of the second sub-target historical user is 0, 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 in case 1, the first sub-target historical user 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 who is in 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 face, and the smaller the priority of sending is. 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 who is in conflict in case 2, the longer the second sequence length of the second sub-target historical user is, the less the second sub-target historical user has the corresponding document management authority in multiple historical versions, and thus the lower the priority of sending. At the same time, in order to solve the user authority application problem as soon as possible, in this case, priority is given to applying for authority at a higher application level. The second sending priority value is obtained by 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. Obtain 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. According to the order of the sending sub-queues, the permission applications are sent to the corresponding second target historical users in sequence.

[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 to be carried out 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 unique Hash identifier as the document parent identifier in the document header information, and use the updated document unique Hash identifier to replace the target document 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 authority.

[0153] S10411. If received, change the target operation permission according to the type of 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, after obtaining authorization, when the current user uses the target operation class to update and save the current document, the document unique Hash identifier of the current document is recorded in the document header information as the document parent identifier of the updated current document, and the target document unique Hash identifier in the document header information is replaced by the updated document unique Hash identifier to form a new document header information. It is also necessary to detect whether the current user has modified the operation permissions of the current document. If the operation permissions have not been modified, the operation permissions of the parent document will be inherited while the document parent identifier is automatically recorded.

[0155] like Figure 5 As shown in the figure, when creating a document, the creator saves the original document. At this time, the original document 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 document 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 the figure. 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. The permission class of version 1 in the document header information is updated to the permission class of version 2. In this example, the permission class of version 2 inherits the permission class of version 1.

[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, the document header information after each edit can be obtained, 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 a multi-version document. The method realizes the historical version tracking of the document version by storing the historical version information in the document header information. The method 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 method obtains the priority value of the application for each user and also proposes a permission application solution when there is a conflict in the application or the response times out. The method avoids the phenomenon that the permission application for the document creator is very frequent due to the spread of multi-version files, relieves the application pressure and improves the security of the document.

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

[0160] The receiving module 11 is used 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, used to detect whether the current user has the operation authority of the target operation type for the current document;

[0162] The acquisition module 13 is used to acquire the historical version change path corresponding to the current document from the document header information of the current document when it is detected that there is no operation permission for the target operation type; 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;

[0163] The determination module 14 is used to determine the historical user who receives the permission application according to the historical version change path, the historical users corresponding to each of the nodes 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 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, wherein the document header information also includes the document information corresponding to each of the historical versions stored in sequence, and the document information includes: the account information of the historical user of the current historical version, the document unique Hash identifier of the current historical version, and the operation authority of the historical user on 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 account information of the current user and the target account information.

[0168] In one embodiment, when it is detected that there is no operation permission for the target operation type, the acquisition module 13 is specifically used 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 according to the historical version change path, the historical users corresponding to each of the nodes, and the permission tags, and sending the permission application to the determined historical user, the determination module 14 is specifically used to:

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

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

[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 returned by the corresponding historical user is received, the sending 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] The authorization instruction is output.

[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 unique Hash identifier as a document parent identifier in the document header information, and replacing the target document unique Hash identifier in the document header information with the updated document 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 of the historical users according to the permission tag sequence corresponding to each of the historical users, the determination module 14 is specifically configured to:

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

[0189] Obtaining 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 the preset operation permissions for the current historical version, the permission tag is the first value; if the current historical user does not have all the preset operation permissions for the current historical version, the permission tag is the second value;

[0190] 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;

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

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

[0193] During the sending process, it is detected 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 a 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] Obtaining 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 a value of the first value and a second sub-target historical user whose authority tag has a value of 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 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, 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 of the first sub-target historical users, sequentially traverse the permission tags in each of the previous historical versions until the permission tag corresponding to the first sub-target historical user is the second value, and record the first sequence length; obtain the first sending priority value according to the first sequence length;

[0208] 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.

[0209] It should be noted that the sequence of the above embodiments of the present invention is only for description and does not represent the advantages and disadvantages of the embodiments. The processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some 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 referenced to each other, and 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 a permission application from a current user for a current document, wherein the permission application includes a target operation type for the current document; Detecting whether the current user has the operation authority of the target operation type for the current document; 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 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; 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.

2. The method for realizing document multi-version tracking and authority management based on document hash according to claim 1 is characterized in that: The detecting whether the current user has the operation authority of the target operation type for the current document includes: Obtaining the account information of the current user; Obtaining 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, wherein the document header information also includes the document information corresponding to each of the historical versions stored in sequence, and the document information includes: the account information of the historical user of the current historical version, the document unique Hash identifier of the current historical version, and the operation authority of the historical user on the current historical version; It is detected whether the current user has the operation authority of the target operation type on the current document according to the account information of the current user and the target account information.

3. The method for realizing document multi-version tracking and authority management based on document hash according to claim 2 is characterized in that: The detecting that there is no operation permission for the target operation type includes: Detecting 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, determining 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.

4. The method for realizing document multi-version tracking and authority management based on document hash according to claim 1 is characterized in that: The determining, according to the historical version change path, the historical users corresponding to each of the nodes, and the permission tags, of a historical user who receives the permission application, and sending the permission application to the determined historical user, comprises: Obtaining a permission tag sequence corresponding to each of the historical users; Obtaining the application request level corresponding to each of the historical users according to the permission tag sequence corresponding to each of the historical users; Arrange the application request levels corresponding to all the historical users in ascending order to obtain a permission application sending queue; 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 returned by the corresponding historical user is received, the sending 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; The authorization instruction is output.

5. The method for realizing document multi-version tracking and authority management based on document hash according to claim 4 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 unique Hash identifier as a document parent identifier in the document header information, and replacing the target document unique Hash identifier in the document header information with the updated document 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.

6. The method for realizing document multi-version tracking and authority management based on document hash according to claim 5 is characterized in that: The obtaining the application request level corresponding to each of the historical users according to the permission tag sequence corresponding to each of the historical users includes: The following steps are performed for each permission tag sequence corresponding to the historical user: Obtaining 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 the preset operation permissions for the current historical version, the permission tag is the first value; if the current historical user does not have all the preset operation permissions for the current historical version, the permission tag is the second value; 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; According to the frequency, the preset frequency weight, the node order and the node order weight, the application request level corresponding to the current historical user is obtained.

7. The method for realizing document multi-version tracking and authority management based on document hash according to claim 6 is characterized in that: The sending of the permission applications to the corresponding historical users in sequence according to the order of the permission application sending queue comprises: During the sending process, it is detected whether there are multiple second target historical users in the current ranking; If the current ranking corresponds to multiple second target historical users; Obtaining a 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.

8. The method for realizing document multi-version tracking and authority management based on document hash according to claim 7 is characterized in that: The acquiring the sending subqueue corresponding to the second target historical user includes: Obtaining the permission label corresponding to each of the second target historical users in the last historical version; From the second target historical users, obtain a first sub-target historical user whose authority tag has a value of the first value and a second sub-target historical user whose authority tag has a value of the second value; 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; 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.

9. The method for realizing document multi-version tracking and authority management based on document hash according to claim 8 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, comprises: 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; 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.

10. The method for realizing document multi-version tracking and authority management based on document hash according to claim 8, characterized in that: The obtaining of 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: For each of the first sub-target historical users, sequentially traverse the permission tags in each of the previous historical versions until the permission tag corresponding to the first sub-target historical user is the second value, and record the first sequence length; obtain the first sending priority value according to the first sequence length; 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.

Images