Dynamic data rights management method for data sharing

Abstract

The present invention discloses a dynamic data authority management method for data sharing, which relates to the technical field of data authority management and specifically includes the following steps: establishing a binding relationship between a data processing stage and field access rights, forming a mapping relationship between a data processing node and a field set; judging whether the data processing stage has not yet completed the advancement based on the formed mapping relationship; in the case that the data processing stage has not yet completed the advancement, collecting process execution behavior information, and processing it after collection, converting it into three types of structured numerical values: status code, behavior completion ratio and path stability value; based on the three types of structured numerical values ​​after conversion, determining the status confirmation degree of the current node in the case that the data processing stage has not yet completed the advancement. The present invention solves the problem of expanding rights when the process status is not confirmed, and realizes real-time synchronization and dynamic adjustment of authority control and process status.

Description

Technical Field

[0001] The present invention relates to the technical field of data authority management, and in particular to a dynamic data authority management method for data sharing. Background Art

[0002] Ensuring data security, compliance, and controllability during data transmission and use during cross-departmental and cross-system data sharing is a major technical challenge facing the current data management and security landscape. Traditional data permission management approaches rely on static rule-based settings, pre-binding access rights to users, resources, or systems. This makes it difficult to cope with complex and changing usage scenarios and the high demands for data security, flexibility, and auditability. To address these issues, dynamic data permission management technology has emerged. This technology dynamically generates and adjusts data access rights by sensing the context of access requests in real time, taking into account multiple factors such as the visitor's identity, data sensitivity level, usage scenario, and time limits. During data interaction, dynamic permission management methods continuously monitor permission usage, automatically record access traces, and promptly trigger security responses when anomalies or violations are detected. This effectively prevents illegal access, unauthorized use, or leakage of data, thereby improving the flexibility, security, and auditability of data sharing.

[0003] Existing dynamic data permission management technologies are typically based on the Attribute-Based Access Control (ABAC) model. This model uses multiple factors, including user attributes (such as position, responsibility, and organizational affiliation), resource attributes (such as data type and sensitivity level), and environmental attributes (such as access time, location, and terminal type), combined with pre-set access policies and a rule engine, to conduct real-time evaluation and permission decisions for each data access request. In practical applications, upon receiving an access request, the system uses a Policy Decision Point (PDP) to determine and match permission policies in real time. It then dynamically assigns or denies access rights through a Policy Enforcement Point (PEP), achieving "on-demand granting and dynamic revocation" of permissions. Furthermore, such systems are typically equipped with an audit module that records and analyzes access behavior throughout the entire process. When abnormal behavior is detected, it can automatically issue alerts or adjust access policies, establishing a secure permission management mechanism that is real-time, adaptive, and traceable, meeting the needs of various sharing scenarios requiring high data security and flexibility.

[0004] The existing technology has the following deficiencies:

[0005] In a data flow process, when a matter is undergoing multi-stage sequential processing, the scope of data access permissions corresponding to each stage should be gradually expanded. Typically, only summary fields are accessible in the initial stage, with detailed fields gradually unlocked in subsequent stages. If the process is not advanced promptly—that is, the process control information advances to the next stage before the previous processing node has completed status confirmation—then the permission control logic mistakenly assumes that the process has entered the next stage. Because current permission assignment mechanisms often rely on the completion time of the previous node to trigger permission extension, ignoring the critical judgment that process advancement requires confirmation of processing results, detailed data that should not be released is prematurely released to the next stage's responsible person, resulting in unauthorized data access. Existing dynamic data permission management technologies for data sharing cannot determine whether to extend access permissions based on the status confirmation level of the current node when the data processing stage is not yet completed. As a result, the permission control process is out of sync with the actual process node status. This can lead to a series of problems, such as the premature exposure of sensitive information, the mishandling of unconfirmed data by responsible persons, and even data request failures and business processing interruptions due to untimely permission synchronization.

[0006] The above information disclosed in this Background section is only for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not form the prior art that is already known to a person of ordinary skill in the art. Summary of the Invention

[0007] The purpose of the present invention is to provide a dynamic data rights management method for data sharing to solve the problems in the above-mentioned background technology.

[0008] In order to achieve the above-mentioned object, the present invention provides the following technical solution: a dynamic data rights management method for data sharing, which specifically comprises the following steps:

[0009] Establish a binding relationship between the data processing stage and the field access rights, and form a mapping relationship between the data processing node and the field set;

[0010] Based on the formed mapping relationship, determine whether there is any incomplete progress in the data processing stage;

[0011] In the case of incomplete progress during the data processing phase, process execution behavior information is collected and processed after collection, and converted into three types of structured values: status code, behavior completion ratio, and path stability value;

[0012] Based on the three types of structured values ​​after conversion, the status confirmation degree of the current node is determined when the data processing stage has not yet completed the advancement;

[0013] Based on the result of the node status confirmation degree, control whether the field access rights are extended and the extended field range;

[0014] Execute the change operation of field access rights and record the node number, field set, confirmation degree and extension result during the field permission extension process. When the process rolls back, perform permission rollback based on the difference between the current node status and the recorded content.

[0015] Preferably, based on the formed mapping relationship, it is determined whether the data processing stage has not been completed, specifically:

[0016] Based on the mapping relationship between the formed data processing node and the field set, read the field set mapping entry corresponding to the current processing node, obtain the number of fields that have been actually opened for the processing node in the current process, compare the preset number of fields in the field set mapping entry with the number of fields that have been actually opened, and when the number of fields that have been actually opened does not reach the preset number of fields in the mapping entry, it is judged that the data processing stage has not been completed.

[0017] Preferably, when there is an incomplete progress in the data processing stage, the process execution behavior information is collected and processed after collection, and converted into three types of structured values: status code, behavior completion ratio and path stability value, specifically:

[0018] In the case of incomplete progress during the data processing phase, process execution behavior information is collected and preprocessed after collection;

[0019] Extract the processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes from the pre-processed process execution behavior information;

[0020] The processing status information of the current processing node specifically includes whether the processing status of the current processing node is one of the four processing states: task not accepted, processing, submission completed, or confirmed completed; the operation behavior information of the node responsible person specifically includes the number of operations performed by the node responsible person; the flow path information between nodes specifically includes whether the current node path has jumped;

[0021] The extracted processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes are converted into three types of structured values: status code, behavior completion ratio and path stability value.

[0022] Preferably, the extracted processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes are converted into three types of structured values: status code, behavior completion ratio, and path stability value, specifically:

[0023] According to the extracted processing status information of the current processing node, if the processing status of the current processing node is task not accepted, the value of the status code is determined to be 0 through the numerical mapping; if the processing status of the current processing node is processing, the value of the status code is determined to be 1 through the numerical mapping; if the processing status of the current processing node is submission completed, the value of the status code is determined to be 2 through the numerical mapping; if the processing status of the current processing node is confirmed completed, the value of the status code is determined to be 3 through the numerical mapping;

[0024] The operation behavior information of the node responsible person is extracted. The number of operations performed by the node responsible person is calculated by comparing it with the total number of preset operations corresponding to the current processing node to obtain the behavior completion ratio. The specific calculation method is: behavior completion ratio = number of operations performed by the node responsible person / total number of preset operations corresponding to the current processing node;

[0025] According to the flow path information extracted between nodes, if the current node path has jumped, the path stability value is determined to be 0.8 through numerical mapping; if the current node path has not jumped, the path stability value is determined to be 1.0 through numerical mapping.

[0026] Preferably, based on the converted three types of structured values, determining the status confirmation degree of the current node when the data processing stage is not completed, specifically includes the following steps:

[0027] The three types of structured values ​​after conversion, namely, the state code, behavior completion ratio and path stability value, are calibrated as A, B and C respectively, where A represents the state code, B represents the behavior completion ratio and C represents the path stability value.

[0028] Based on the converted state code and the behavior completion ratio, a behavior deviation index is generated; based on the converted state code and the path stability value, a path disturbance coefficient is generated;

[0029] Based on the generated behavior deviation index and path disturbance coefficient, a state confirmation index is generated;

[0030] Determine the pre-set state confirmation index threshold range, and compare it with the generated state confirmation index after determination, and determine the state confirmation degree of the current node when the data processing stage has not been completed according to the comparison result.

[0031] Preferably, the specific acquisition logic of the behavior deviation index and the path disturbance coefficient is as follows:

[0032] Normalize the status code A to obtain the normalized status value GA, which is equal to the status code A divided by the maximum value of the status code 3;

[0033] Add 1 to the behavior completion ratio B and the normalized state value GA, and denote them as B+1 and GA+1 respectively;

[0034] Perform natural logarithm operation on B+1 and GA+1 respectively to obtain their respective logarithmic values, calculate the absolute value of the difference between the obtained logarithmic values, and the result is the behavior deviation index;

[0035] Subtract the path stability value C from the value 1, and multiply the absolute value of the difference by the exponential power of the natural constant e. The result is the path disturbance coefficient, where the exponent of the exponential power is the normalized state value GA.

[0036] Preferably, based on the generated behavior deviation index and path disturbance coefficient, a state confirmation index is generated, specifically: the behavior deviation index and the path disturbance coefficient are added by 1 respectively to obtain a first adjustment value and a second adjustment value; the first adjustment value and the second adjustment value are respectively subjected to reciprocal processing to obtain a first reciprocal value and a second reciprocal value; the first reciprocal value and the second reciprocal value are weighted and summed to generate a state confirmation index, and the index is calibrated as .

[0037] Preferably, a preset state confirmation index threshold interval is determined , and after confirmation with the generated status confirmation index Perform a comparison and determine the degree of status confirmation of the current node when the data processing stage is not completed based on the comparison results. The specific comparison analysis is as follows:

[0038] like ,In the data processing stage, if the progress is not completed, the status confirmation degree of the current node is low;

[0039] like ,In the data processing stage, when the advancement is not completed, the status confirmation level of the current node is medium;

[0040] like ,In the data processing stage, when the advancement is not completed, the status confirmation degree of the current node is high.

[0041] Preferably, based on the determination result of the node status confirmation degree, whether the field access rights are extended and the extended field range are controlled, specifically:

[0042] When the node status confirmation level is low, the extension of field access rights is prohibited and the current field access rights range remains unchanged;

[0043] When the node status confirmation level is medium, the field access rights are extended. The extension scope is limited to the field subset marked as low sensitivity in the field set corresponding to the current processing node. Only read permission is granted on this field subset, and write operations are not allowed.

[0044] When the node status confirmation level is high, the field access rights are extended to include all fields in the field set corresponding to the current processing node, and read and write permissions are granted to the field set.

[0045] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0046] 1. The present invention aims to address the problem that existing dynamic data permission management technologies for data sharing cannot make effective permission judgments based on the degree of status confirmation when the data processing stage has not been completed, resulting in premature extension of permissions. A status judgment mechanism based on field set mapping is proposed. By constructing a mapping relationship between data processing nodes and field sets, the system can compare the number of fields actually opened at the current node with the number of fields that should be opened in real time to determine whether the process has been mistakenly advanced to the next stage. This mechanism avoids the drawbacks of relying solely on time or process advancement flags for judgment, and realizes the coupling and unification of the permission control logic's ability to perceive, judge, and constrain process status advancement, significantly improving the accuracy and time synchronization of data access permission distribution.

[0047] 2. The present invention proposes a credibility modeling method based on three types of structured numerical values: status code, behavior completion ratio, and path stability value. It further introduces two core parameters: behavior deviation index and path disturbance coefficient. After logarithmic operation and exponential enhancement processing, the status confirmation index is generated, and the node status credibility is graded according to the preset threshold interval. The system distinguishes control strategies according to the degree of status confirmation, and realizes full-process automatic decision-making on whether field access rights are extended, to which field ranges they are extended, and what type of access (read / write) is granted. It builds a dynamic response mechanism that drives permission actions with quantitative evaluation results. This solution can effectively avoid the permission mismatch problem caused by state ambiguity or path jumps in traditional static authorization methods in complex process scenarios, and improves the intelligence level and response accuracy of permission allocation.

[0048] 3. While executing the field permission expansion, the structured permission change data including the node number, field set, status confirmation degree and expansion result are automatically recorded. When the process rolls back or the node status is downgraded, the permission rollback logic is automatically triggered by comparing with the recorded content to restore the field permission to the access configuration status of the previous legal node. This mechanism can be implemented through the permission status version comparison and field permission remapping module to ensure that the permission status is consistent with the process advancement logic throughout the process, without lags or out of bounds. Through this technical means, the system has the complete audit capability of permission operations and the fault-tolerant recovery capability under process anomalies, which not only ensures the strictness of permission control in data sharing, but also enhances the security, stability and compliance flexibility during system operation. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction to the drawings required for use in the embodiments will be given below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0050] Figure 1 The figure is a flow chart of the dynamic data rights management method for data sharing of the present invention. DETAILED DESCRIPTION

[0051] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of this disclosure will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art.

[0052] The present invention provides Figure 1 The dynamic data rights management method for data sharing shown in the figure specifically includes the following steps:

[0053] Establish a binding relationship between the data processing stage and the field access rights, and form a mapping relationship between the data processing node and the field set;

[0054] The binding relationship between the data processing stage and the field access rights can be achieved by introducing a permission binding configuration module in the process modeling stage. The specific implementation methods include: setting a "stage identifier" for each processing stage in the business process definition file or database table, and associating one or more permission tags (such as "readable summary field", "non-writable detail field", etc.). Permission tags can be preset through field grouping templates, or specified by the administrator through field check in the configuration interface. When the process is initialized, the system binds these permission tags to the stage identifiers one by one, and stores them as structured permission control rules for call during process execution. This mechanism can be implemented by integrating the process engine with the permission control component to ensure that the access capabilities of each stage have clear boundaries.

[0055] Based on the established phase and permission binding relationship, the field permission parsing engine can be used to dynamically parse the field set mapping corresponding to each data processing node. This is achieved by reading the node identifier and calling the permission tag to which it is bound when parsing each processing node. The field set contained in the tag is then extracted to form a one-to-one mapping table of "node number → field list". This mapping table can be generated and cached in memory when the process instance starts, or persisted in a database for use by the permission module. The field set itself can be derived from a structured data dictionary (such as field name, field ID, field type, etc.) and automatically generated through methods such as label screening, field template matching, and rule filtering, thereby ensuring the integrity and automation of the mapping process.

[0056] The reason why the binding relationship between the data processing stage and the field access rights is established in the above way, and the mapping between the data processing node and the field set is formed, is because in the data flow process, the data access rights must evolve finely with the process stage, and must have field-level control granularity. If the binding mechanism is not clearly established, the system will not be able to identify which fields a certain node should be allowed to access, which may lead to problems such as untimely expansion of permissions or premature release. By presetting the binding relationship and forming a structured mapping, the software system can quickly locate the range of fields allowed to be accessed based on the current node during process execution, providing a static reference baseline for subsequent permission judgment logic. Especially when permissions need to be dynamically adjusted based on node status and behavior judgment, only under the premise of having a clear static mapping relationship can true dynamic access control based on contextual status be achieved to ensure that permission behavior is both compliant and controllable.

[0057] Based on the formed mapping relationship, determine whether there is any incomplete progress in the data processing stage;

[0058] In this embodiment, based on the formed mapping relationship, it is determined whether the data processing stage has not been completed, specifically:

[0059] Based on the mapping relationship between the formed data processing node and the field set, read the field set mapping entry corresponding to the current processing node, obtain the number of fields that have been actually opened for the processing node in the current process, compare the preset number of fields in the field set mapping entry with the number of fields that have been actually opened, and when the number of fields that have been actually opened does not reach the preset number of fields in the mapping entry, it is judged that the data processing stage has not been completed.

[0060] This determination can be achieved by integrating a "field permission comparison engine" into the process permission control module. The system first reads the mapping entry for the current processing node from the "node-field set mapping table" to obtain the list of fields that are supposed to be open at that node. This list is typically stored as a structured array and contains field identifiers (such as field IDs or field names). The system then calls the field access record in the current process execution context to extract the field entries that are actually authorized to be open at the current node and counts their number. The actual number of open fields is then compared with the preset number of fields in the mapping table. If the actual number of open fields is less than the preset number, the system generates a "threshold not reached" flag. This flag serves as a trigger for subsequent permission extension determination functions. This entire process is accomplished through software-based methods such as database queries, memory cache comparisons, and field permission access logs. It can be seamlessly integrated with the permission issuance engine to determine in real time whether permission extension operations are permitted.

[0061] The core purpose of this judgment mechanism is to solve the problem of permissions being mistakenly extended when the process status has not been completed. In the data sharing scenario, each processing node of the process often corresponds to a precisely defined data field access range. If the system cannot determine whether the field permissions actually opened by the current node have met their design standards, it is easy for the permission control time to be advanced or the scope to be exceeded. Traditional practices often only judge the advancement status based on the node status identifier or timestamp, which cannot reflect whether the field-level permissions are truly promoted synchronously. By comparing the "number of fields that should be opened" with the "actual number of fields opened", the system can more accurately identify whether the current process has completed the delivery prerequisites for the required permission scope, thereby avoiding the mistaken expansion of permissions due to the fact that the process has not been substantially advanced. This judgment method not only improves the accuracy of permission control, but also enhances the ability to perceive the state of process behavior, so that the permission logic is more closely bound to the business node, and effectively supports the compliant flow of data between multiple stages and multiple roles.

[0062] In the case of incomplete progress during the data processing phase, process execution behavior information is collected and processed after collection, and converted into three types of structured values: status code, behavior completion ratio, and path stability value;

[0063] In this embodiment, when the data processing stage shows that progress has not been completed, the process execution behavior information is collected and processed after collection, and converted into three types of structured values: status code, behavior completion ratio, and path stability value. Specifically,

[0064] In the case of incomplete progress during the data processing phase, process execution behavior information is collected and preprocessed after collection;

[0065] If the data processing stage is judged to be incomplete, the system can call multiple data source interfaces through the process operation management module to collect the process execution behavior information of the current processing node. This information mainly includes three categories: processing status, operation behavior and path behavior, which come from different structured data tables. The processing status information can be obtained by reading the status field corresponding to the current node in the process task table. The operation behavior information of the node responsible person is obtained from the user operation log by jointly filtering by user ID and node ID, extracting all the operation records that have occurred, such as "fill in", "submit", "return", etc., and archiving them in chronological order; the path behavior information is determined by parsing the execution trajectory log of the process engine to determine whether there is a jump behavior in the flow path between the current node and the upstream node. All data collection behaviors are triggered by system events or pulled periodically by the permission evaluation engine when the node status is "unconfirmed", and output as a behavior data set in a unified format to provide the original input for subsequent preprocessing and numerical calculation links.

[0066] The purpose of preprocessing is to transform the collected, multi-source, multi-format, and heterogeneous raw behavioral data into a standardized structure that can be uniformly analyzed, calculated, and compared. This prevents the accuracy of subsequent judgment logic from being affected by label discrepancies, inconsistent formats, or noise. Preprocessing primarily involves three operations: field cleansing, which eliminates historical data irrelevant to the current node, such as erroneous operations or duplicate events; semantic normalization, which maps labels with similar meanings but different expressions (such as "processing," "handling," and "in progress") to a standard value of "processing"; and data standardization, such as converting textual status labels into numeric status codes, mapping operation events to operation type IDs, and verifying Boolean jump flag fields. This preprocessing process can be automated using a rules engine. A mapping dictionary and rule templates are pre-set for each data type. When the data processing service is called, the system automatically identifies, maps, and cleans the data, outputting structured results for use by the parameter calculation module. This ensures consistent, complete, and comparable input data for subsequent permission evaluation.

[0067] Extract the processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes from the pre-processed process execution behavior information;

[0068] After preprocessing the process execution behavior information, three types of target information can be extracted by calling the structured data tables and runtime interfaces in the process management system. Specifically, the processing status information of the current processing node can be obtained by accessing the task status table of the process instance, where the standardized status field is read according to the current node number. This field is usually uniformly mapped to one of the following during the preprocessing phase: "Task Not Accepted," "Processing," "Submission Completed," or "Confirmed Completed." The operation behavior information of the node responsible can be obtained by analyzing the operation log record table generated after preprocessing, filtering all operation events at the current node by the responsible ID, and counting the number of executed instructions as the behavior quantity item. The flow path information between nodes is determined by comparing the order relationship between the current node and the previous node in the process definition diagram, combining the jump mark field in the flow record table, and determining whether the current node is the direct successor node in the expected order in the process definition path, thereby extracting the Boolean judgment result of "whether the path jumps." The above extraction operation is automatically completed through the data call, field mapping, and logical judgment process in the software system, ensuring that the extraction results are standardized and can be used for structured numerical calculations.

[0069] The processing status information of the current processing node specifically includes whether the processing status of the current processing node is one of the four processing statuses: task not accepted, processing, submission completed, or confirmed completed; the operation behavior information of the node responsible person specifically includes the number of operations performed by the node responsible person; the flow path information between nodes specifically includes whether the current node path has jumped.

[0070] In the software system, the processing status information of the current processing node, the operational behavior information of the node responsible person, and the flow path information such as whether the current node path has jumped can be accurately obtained by integrating the process engine, the operation log module and the process tracking record table. For processing status information, the system can access the node status table in the process instance database and read its status field based on the current process instance ID and node number. This field is usually standardized in the preprocessing stage to one of "task not accepted", "processing", "submission completed" or "confirmed completed"; these states are usually automatically written to the state machine when the node processing event is triggered. For example, the state is "not accepted" after the node is activated, and it changes to "processing" when the user opens the task interface. The submission operation generates a "submission completed" state, which changes to "confirmed completed" after confirmation by the superior or the system. Each state has a clear corresponding system event. For the operational behavior information of the node responsible person, the system calls the user behavior log table to filter out the operational events triggered by the responsible person during the current node (such as clicking "fill in", "submit", "return", etc.), and based on this, counts the number of valid events as the "number of operations executed"; this information comes from the user interface behavior binding event log and has stable trigger logic and operation identification. As for whether the current node path has undergone a jump, it reads the flow path record between the previous execution node and the current node in the process operation trajectory table, combined with the standard flow sequence preset in the process definition diagram. If the path between the two nodes is not directly connected in sequence or skips the intermediate node, it is judged as "a jump has occurred". The system uses this result as a Boolean field mark (true for jump, false for no jump), making the path behavior identifiable, collectible, and mappable. The above three types of information are automatically extracted and judged by the software system without manual intervention, and can serve as the core input data source for the subsequent generation of structured parameters.

[0071] The extracted processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes are converted into three types of structured values: status code, behavior completion ratio and path stability value.

[0072] In this embodiment, the extracted processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes are converted into three types of structured values: status code, behavior completion ratio, and path stability value. Specifically,

[0073] According to the extracted processing status information of the current processing node, if the processing status of the current processing node is task not accepted, the value of the status code is determined to be 0 through the numerical mapping; if the processing status of the current processing node is processing, the value of the status code is determined to be 1 through the numerical mapping; if the processing status of the current processing node is submission completed, the value of the status code is determined to be 2 through the numerical mapping; if the processing status of the current processing node is confirmed completed, the value of the status code is determined to be 3 through the numerical mapping;

[0074] In the software system, the numerical conversion of the current processing node's processing status can be achieved by accessing the standardized node status fields in the process engine or task management module and combining them with status code mapping rules. The system first extracts the node's operation status field based on the current node's unique identifier through a process instance interface or database query. This field is typically a string type, such as "Unaccepted," "Processing," "Submission Completed," or "Confirmed Completed." After collecting the status field, the system calls a pre-defined status mapping dictionary or state conversion logic function to convert it to the corresponding integer status code. The mapping rules are pre-defined, for example: "Unaccepted" corresponds to status code 0, "Processing" corresponds to 1, "Submission Completed" corresponds to 2, and "Confirmed Completed" corresponds to 3. The converted status code is stored as a standardized numerical variable in the structured behavior information dataset for subsequent parameter calculation and permission assessment model input. This mapping operation can be implemented in the data processing engine through conditional judgment, label replacement, or configuration-based mapping tables, achieving low computational cost and high operational efficiency. It can also be performed dynamically during real-time process execution or scheduled scans.

[0075] The core purpose of converting processing status from string representation to integer status codes is to enable structured modeling of process status, improve decision-making efficiency, and provide foundational support for numerical algorithms. While human-friendly and easy to understand, original status labels are inconvenient for rapid logical decision-making, branch control, or parameter calculation within programs. This is particularly true in dynamic assessment scenarios for permission control, where multiple node states must be evaluated and numerically combined in parallel. Retaining these strings would complicate the processing flow, consume significant computational resources, and hinder unified modeling with structured metrics such as subsequent behavior completion rates and path stability values. Mapping processing status to integer status codes significantly improves the simplicity of decision-making logic and computational efficiency, enabling status codes to be directly incorporated into processes such as weighting, segmented decision-making, and risk scoring. They can also be used as historical status identifiers for permission decisions in auditing and rollback scenarios. Through numerical processing, the computability, controllability, and traceability of the entire data permission control process are enhanced, enabling a deep connection and refined linkage between data permission control and process status.

[0076] The operation behavior information of the node responsible person is extracted. The number of operations performed by the node responsible person is calculated by comparing it with the total number of preset operations corresponding to the current processing node to obtain the behavior completion ratio. The specific calculation method is: behavior completion ratio = number of operations performed by the node responsible person / total number of preset operations corresponding to the current processing node;

[0077] In the software system, the calculation of the action completion ratio is accomplished through the linkage between the operation log collection module and the node configuration management module. First, the system automatically records the action events performed by the node responsible for each node during the processing process, such as clicking "Fill in data," "Upload attachments," "Submit for approval," and "Confirm receipt." These action events are stored in the system as structured logs. Each log record contains fields such as the responsible person ID, node ID, action type, and timestamp. The system filters the logs of the current processing node and counts the action entries attributed to the node responsible for that node to obtain the "number of actions performed." Simultaneously, the system extracts the list of preset action requirements from the node's process definition configuration. This list specifies the types and total number of actions that must be completed before the node is completed. This list is typically configured in the process model or rule template. The system then calculates the ratio of the two to generate the action completion ratio: action completion ratio = actual number of actions / total number of preset actions. The result is typically a decimal value between 0 and 1, with one to two decimal places, and serves as structured input for subsequent risk assessments and permission decisions. The entire process is automatically triggered by system events, independent of human intervention, and offers real-time and stability.

[0078] The use of "action completion ratio" as a structured input parameter is designed to assess the actual progress and reliability of node processing from a quantitative perspective on user action completion. In process- or permission-sensitive data sharing processes, processing a particular node isn't always completed in one go; instead, it comprises multiple steps, such as filling out documents, uploading attachments, verifying information, and signing confirmations. Relying solely on a single status indicator (such as "Processing" or "Submitted") cannot accurately reflect whether the responsible individual has fulfilled all responsibilities. By comparing the actual number of actions performed against the system's pre-defined complete action list, not only can the current processing be accurately determined, but it can also reflect the "processing depth" and "execution compliance," providing significant value in identifying behaviors such as unclear responsibilities, oversights, or unusual redirections. Furthermore, as a continuous structured indicator, the action completion ratio can be directly incorporated into the evaluation model, weighted with other parameters, to determine whether permissions should be extended or frozen. Its introduction significantly enhances the dynamic, refined, and personalized decision-making capabilities of permission judgments, shifting permission control from static status judgments to quantitative assessments of the behavior process, thereby improving overall security and compliance.

[0079] According to the flow path information extracted between nodes, if the current node path has jumped, the path stability value is determined to be 0.8 through numerical mapping; if the current node path has not jumped, the path stability value is determined to be 1.0 through numerical mapping.

[0080] In the software system, the generation of path stability values ​​relies on analyzing the flow path between the current processing node and the previous node. This determination is made by comparing the process trajectory with the process definition diagram. The system first reads the upstream node number of the current node from the process instance trajectory table. It then extracts the canonical sequence of predecessor nodes for that node from the process definition structure (typically modeled in BPMN or a directed graph). If the two match, the process is progressing along the preset path and no jumps have occurred. If the two do not match, and the trajectory table contains path deviation flags (such as jump events, conditional jumps, forced jumps, or special approval path records), the path is considered to have undergone a jump. The system automatically converts the Boolean logic flag "jump or not" into a path stability value. If the jump is true, the stability value is 0.8, and if the jump is not true, the stability value is 1.0. The path stability value, as a structured value, is written into the permission evaluation context of the current node and subsequently used in conjunction with other parameters to calculate the evaluation coefficient. The entire process is driven by a judgment function and mapping table, requiring no user intervention and completed in real time before process node activation or permission evaluation.

[0081] The core purpose of introducing a path stability value is to factor in the stability of process behavior paths during data permission evaluation, determining whether the current process is progressing along the established, standardized path. In data sharing processes involving multiple departments and roles, jumping between nodes often indicates process deviations, exception handling, or authority violations. For example, responsible individuals bypassing intermediate approval nodes or directly transferring data. In permission control, this non-standard path forwarding can blur permission boundaries, disrupt the audit chain, and lead to data leaks and unclear accountability. By setting a path stability value, the behavioral characteristic of "whether to jump" is structured and quantified, making it part of the evaluation coefficient in the decision-making model. When the path stability value is below the standard value (e.g., 1.0), the system can adopt a more cautious or restrictive policy for permission extension, ensuring that permissions are not unconditionally granted when anomalies occur in the process path. Furthermore, the path stability value provides fundamental support for subsequent traceability analysis, rollback control, and identification of abnormal flow, enhancing process controllability and data security boundary awareness, thereby building a dynamic, behavior-driven data permission control system.

[0082] Based on the three types of structured values ​​after conversion, the status confirmation degree of the current node is determined when the data processing stage has not yet completed the advancement;

[0083] In this embodiment, based on the converted three types of structured values, determining the status confirmation degree of the current node when the data processing stage is not completed, specifically includes the following steps:

[0084] The three types of structured values ​​after conversion, namely, the state code, behavior completion ratio and path stability value, are calibrated as A, B and C respectively, where A represents the state code, B represents the behavior completion ratio and C represents the path stability value.

[0085] Based on the converted state code and the behavior completion ratio, a behavior deviation index is generated; based on the converted state code and the path stability value, a path disturbance coefficient is generated;

[0086] Based on the generated behavior deviation index and path disturbance coefficient, a state confirmation index is generated;

[0087] Determine the pre-set state confirmation index threshold range, and compare it with the generated state confirmation index after determination, and determine the state confirmation degree of the current node when the data processing stage has not been completed according to the comparison result.

[0088] In software systems, pre-setting threshold intervals for the status confirmation index is typically achieved through a combination of data-driven modeling and rule configuration. First, the system extracts a large amount of actual process execution data from the process engine's historical behavior database. The system collects the corresponding status codes, behavior completion ratios, and path stability values ​​for each processing node when progress has not yet been completed. Based on this data, the system calculates the status confirmation index for a large number of known samples. Next, the system analyzes the historical distribution of the status confirmation index using statistical methods such as cluster analysis, density distribution modeling, or piecewise regression to identify typical intervals with decision-making value. After analysis, administrators can enter these intervals as formal evaluation parameters through the system configuration interface. These are stored as configuration items in the rule engine or parameter management module for subsequent use in decision logic. To enable flexible adjustments, the system also supports defining multiple threshold intervals based on process type, business domain, or risk level. The appropriate threshold scheme is automatically selected during process initialization or node activation, enabling dynamic adaptation and personalized configuration of status confirmation judgments. This entire process requires no manual analysis or modeling, is replicable, and self-evolving, ensuring that threshold interval settings are both statistically reliable and automatically optimized as business evolves.

[0089] In this embodiment, the specific logic for obtaining the behavior deviation index and the path disturbance coefficient is as follows:

[0090] Normalize the status code A to obtain the normalized status value GA, which is equal to the status code A divided by the maximum value of the status code 3;

[0091] Add 1 to the behavior completion ratio B and the normalized state value GA, and denote them as B+1 and GA+1 respectively;

[0092] Perform natural logarithm operation on B+1 and GA+1 respectively to obtain their respective logarithmic values, calculate the absolute value of the difference between the obtained logarithmic values, and the result is the behavior deviation index;

[0093] The specific calculation formula is: , where is the behavioral deviation index;

[0094] The behavior deviation index is calculated using a combination of normalization, translation, and logarithmic difference. The goal is to construct a nonlinear, sensitive metric that reflects whether the degree of behavior completion matches the node's current processing state. First, the state code A is divided by its maximum value of 3 to obtain the normalized state value GA. This standardizes the processing states at different stages to a uniform range of [0, 1], providing a basis for comparison during mathematical processing. Next, the behavior completion ratio B and GA are each incremented by 1 to prevent errors when the logarithmic function encounters zero or extremely low values. This also serves to convert the behavior data from "completion degree" to "logarithmically comparable quantities." Natural logarithm operations are then performed on B+1 and GA+1, respectively, transforming the original linear proportional relationship into a growth trend in logarithmic space, thereby amplifying deviation signals caused by small differences. Finally, the absolute value of the difference between the two logarithmic values ​​is calculated to reflect the degree of deviation between the behavior and the state. A larger value indicates a greater deviation between the behavior completion degree and the state, providing a precise quantification of the coupling relationship between the state and behavior.

[0095] The behavior deviation index directly measures the credibility of the current node's processing status, even if it's not yet completed. A smaller behavior deviation index indicates good consistency between the node's responsible person's completion rate and the node's processing status. For example, when the status code is "Processing," the completion rate is moderately high, indicating reasonable progress and a high degree of confidence. Conversely, a larger behavior deviation index indicates a significant mismatch between the completion rate and the status code. For example, if the status code displays "Submission Completed" but the completion rate is low, this indicates the node may have been prematurely advanced or contains false processing behavior or abnormal jumps, reducing the credibility of the status. When determining the degree of status confirmation for incomplete progress, the system uses the behavior deviation index as a negative parameter in the evaluation model. A larger index indicates a less favorable outcome for extending permissions for the current node. Conversely, a smaller index indicates a more reliable status, and data field access permissions can be conditionally relaxed. Therefore, this index is an essential credibility assessment dimension for dynamically adjusting data permissions.

[0096] Subtract the path stability value C from the value 1, and multiply the absolute value of the difference by the exponential power of the natural constant e. The result is the path disturbance coefficient, where the exponent of the exponential power is the normalized state value GA.

[0097] The specific calculation formula is: , where is the path perturbation coefficient.

[0098] The path perturbation coefficient is calculated using a combination of path deviation identification and state level amplification. This approach aims to assess the impact of node path jumps on process reliability, taking into account the current state level. Since the path stability value C is fixed to two values ​​in this method: 1.0 indicates no path jumps, and 0.8 indicates a path jump. Therefore, the system first determines whether the current path has a jump to indirectly determine the path deviation. This is done by subtracting the path stability value C from 1.0 and taking the absolute value. If there is no jump, the difference is 0; if there is a jump, the difference is 0.2. This difference is then multiplied by an exponential factor, generated by normalizing the state code A, to reflect the current node's stage within the overall process. By exponentially linking the path deviation with the current state level, the coefficient remains low even if a path jump occurs in the early stages of the process. However, if a jump occurs near a higher-level stage, such as "Submitted Completed" or "Confirmed Completed," the perturbation is multiplied, thus more accurately reflecting process stability and path reliability. The entire calculation process ensures the simplicity of the formula while enhancing the sensitivity and dynamic response capabilities of risk identification.

[0099] The path perturbation coefficient reflects the degree of alignment between the path compliance and the progress status of the current processing node, even if the progress has not yet been completed. When the path perturbation coefficient is 0, the current node's path has not undergone any jumps. Regardless of the status code, the path is considered part of the standard process, and this does not affect the determination of the status confirmation. In this case, if the behavior-related parameters also meet the requirements, the node status can be judged as trustworthy, and permission extension can be considered. When the path perturbation coefficient is positive (for example, 0.2 multiplied by an exponential factor greater than 0), indicating a jump in the path, the system will amplify the potential risk based on the status. This indicates that the node is not progressing naturally along the expected path, but rather has entered the current stage prematurely without clear responsibilities or upstream confirmation, posing a risk of process disruption or unauthorized overreach. In this case, the larger the path perturbation coefficient, the more likely the node's progress is irrational, and the lower the degree of status confirmation. In comprehensive assessments, the path perturbation coefficient is used as a negative indicator in status credibility assessments to mitigate the risk of jump paths being mistakenly deemed "fully processed" at high status stages, ensuring that the data permission control mechanism effectively detects and intervenes in process path anomalies.

[0100] In this embodiment, based on the generated behavior deviation index and path disturbance coefficient, a state confirmation index is generated, specifically: the behavior deviation index and the path disturbance coefficient are added by 1 respectively to obtain a first adjustment value and a second adjustment value; the first adjustment value and the second adjustment value are respectively subjected to reciprocal processing to obtain a first reciprocal value and a second reciprocal value; the first reciprocal value and the second reciprocal value are weighted and summed to generate a state confirmation index, and it is calibrated as , where the status confirmation index is used to characterize the status confirmation degree of the current node when the data processing stage has not yet been completed. The larger the value of the status confirmation index, the higher the status confirmation degree of the current node.

[0101] At the software level, the process of generating the state confirmation index relies on the system's standardized and weighted fusion of the behavior deviation index and path perturbation coefficient. First, the system obtains the two structured values ​​calculated in the previous step—the behavior deviation index and the path perturbation coefficient—and adds 1 to each to generate two adjustment values. This operation is intended to prevent calculation errors caused by zero values ​​during the subsequent reciprocal calculation and uniformly shift the numerical range to the positive real range. The system then performs a reciprocal operation on these two adjustment values ​​to obtain the first and second reciprocal values. This mathematically transforms the original "risk factor" (a larger value indicates a less trustworthy state) into a "credibility factor" (a larger value indicates a more trustworthy state), thus giving the resulting state confirmation index a positive evaluation. Finally, the system performs a weighted sum of these two reciprocal values ​​based on preset weighting factors (e.g., 0.6 for the behavior deviation dimension and 0.4 for the path perturbation dimension) to produce the state confirmation index, which represents the trustworthiness of the current node state. This index is continuous, adjustable, and normalized. The system compares it with pre-set assessment thresholds to dynamically determine whether permissions can be safely expanded during data processing. This approach, through mathematical transformation, achieves a stable mapping of negative parameters to positive indicators, aligning with computational logic and facilitating model interpretation and review.

[0102] In this embodiment, the preset state confirmation index threshold interval is determined , and after confirmation with the generated status confirmation index Perform a comparison and determine the degree of status confirmation of the current node when the data processing stage is not completed based on the comparison results. The specific comparison analysis is as follows:

[0103] like ,In the data processing stage, if the progress is not completed, the status confirmation degree of the current node is low;

[0104] This situation means that when the data processing stage has not yet been completed, there is an obvious mismatch between the completion status of the current node's behavior and its corresponding processing status, and there are abnormal flow behaviors such as jumps in the path, resulting in the overall process advancement being unconfirmable. Such nodes usually appear when the responsible person has not yet performed key operations, the process is forced to jump, or key approval links are bypassed. There is a high risk of process instability and unclosed responsibility loops. At this time, if field access rights are extended, it may lead to the premature exposure of sensitive data, unauthorized use, or a break in the chain of responsibility. Therefore, at this level, the system should prohibit permission extension, and can intervene in the process operation by triggering alarms, freezing fields, or forced rollbacks to prevent improper use of data.

[0105] like ,In the data processing stage, when the advancement is not completed, the status confirmation level of the current node is medium;

[0106] This situation indicates that the status confirmation of the current node is in a critical or uncertain range. This usually means that the node status and behavior are basically consistent, but some behaviors are still incomplete or there are slight jumps in the path. For example, some non-critical operations have not been submitted, or the process path is delegated but has not been confirmed by the main responsible person. At this time, the overall stability of the process is acceptable, but it is not enough to support full permission opening. At this level, the system can adopt a "prudent expansion" strategy, that is, allowing access to some non-sensitive fields or low-risk data, and at the same time restricting the operation permissions for key fields, while recording operation logs and setting approval marks to ensure that the permission expansion process is auditable and traceable, and prevent the risk of potential process misuse from further expanding.

[0107] like ,In the data processing stage, when the advancement is not completed, the status confirmation degree of the current node is high.

[0108] This situation shows that although the current processing node is still in an unfinished advancement state, its behavior completion ratio is highly consistent with its processing status, and the path stability is good, the process has not experienced abnormal jumps, and it has a complete and reliable data responsibility closed loop. At this point, the node is basically equivalent to the "advancement completed" state at the system behavior level, and the permission control policy can safely execute expansion operations. At this level, the system can automatically open the field access rights corresponding to the current node, or release data according to the complete field set in the node mapping table, without the need to introduce additional manual approval, thereby improving process efficiency. A high degree of status confirmation is also the core support basis for the "relaxation strategy" of the system evaluation mechanism, which helps to ensure the real-time and processing efficiency of data sharing without compromising process compliance and security.

[0109] Based on the result of the node status confirmation degree, control whether the field access rights are extended and the extended field range;

[0110] In this embodiment, whether the field access rights are extended and the extended field range are controlled according to the determination result of the node status confirmation degree, specifically:

[0111] When the node status confirmation level is low, the extension of field access rights is prohibited and the current field access rights range remains unchanged;

[0112] When the system determines that the status confirmation level of the current node is low, the software system first compares the status confirmation index with the set low trust threshold through the evaluation module, and forms a "prohibit extension" instruction flag. After the instruction is passed to the permission control engine, it will trigger two measures: one is to keep the authorized field set of the current processing node unchanged and not load any new field access permissions; the other is to set access shielding marks for fields that may be in the pre-extension list to prevent the fields from being displayed in advance due to system preprocessing or caching mechanisms. This processing logic is usually executed by the access policy engine in the permission control component based on the node identification and status level decision parameters. The core purpose of this approach is to minimize the misreading of data, unauthorized access, or triggering of unclear responsibility operation chains when the process status and behavior are not consistent and the path may jump abnormally, thereby strengthening the system's access convergence capabilities for abnormal promotion nodes.

[0113] When the node status confirmation level is medium, the field access rights are extended. The extension scope is limited to the field subset marked as low sensitivity in the field set corresponding to the current processing node. Only read permission is granted on this field subset, and write operations are not allowed.

[0114] When the system determines that the node status confirmation level is medium, the permission control logic enters "restricted expansion" mode. At this point, the system uses the field sensitivity tag information based on the field set corresponding to the current processing node in the field permission mapping table, filters all fields in this set, and extracts a subset of fields that have been pre-defined as "low sensitivity." These fields are typically pre-labeled by data administrators during the business modeling phase based on risk level, such as basic identity information, business number, and non-confidential status. The system registers this subset as the temporary accessible field list for the current node and automatically configures the read-only permission bit, ensuring that users can only read the field contents and cannot modify, delete, or submit operations. This policy is implemented through the Field-Level Access Control (FLAC) mechanism, allowing for fine-grained permission configuration. It effectively reduces the operational risks associated with incomplete status while ensuring data availability, and is suitable for steady-state usage needs during data transition phases.

[0115] When the node status confirmation level is high, the field access rights are extended to include all fields in the field set corresponding to the current processing node, and read and write permissions are granted to the field set.

[0116] When the degree of confirmation of the node status is judged to be high, it means that the completion degree of the node's behavior is consistent with the process status, and there are no abnormalities in the path, which has high controllability and closed-loop responsibility. Therefore, the system can execute the "full permission release" strategy. In this mode, the permission control module will load all its associated fields according to the mapping relationship between the current node and the field set, and write them into the access context of the current user session. The system synchronously configures the field access permission bits, granting read and write capabilities, including data viewing, field editing and operation submission functions, and at the same time releases the read-only lock status. This processing process is usually completed through the field permission template management module, combined with the identity authentication system to ensure that the permission is only valid for the current node, avoiding the leakage of permission inheritance. Such a design can not only improve the efficiency of process execution and reduce blockages caused by insufficient permissions, but also ensure that the extended operation has a legal basis, while ensuring the integrity of the process and promoting efficient data sharing. It is an ideal authorization status model in the data process.

[0117] Execute the change operation of field access rights and record the node number, field set, confirmation degree and extension result during the field permission extension process. When the process rolls back, perform permission rollback based on the difference between the current node status and the recorded content.

[0118] In software systems, changes to field access permissions are typically performed by the "field permission dispatcher" within the permission control engine. Based on the status confirmation level calculated in the previous step, this dispatcher dynamically loads the corresponding permission policy template, including the field set and its access level (read / write / deny). The system retrieves the field set for the current node through a mapping table and updates the permission flag for the corresponding field in the field-level permission control table (such as the ACL table or policy cache), replacing the original permission status with the expanded status. This operation is completed before the user accesses the data, ensuring that the Policy Enforcement Point (PEP) can intercept and correctly authorize the access in real time. The change also triggers a refresh at the session layer to prevent users from accessing data with old permissions during the permission change process. This approach ensures that changes to field permissions are tightly tied to the state of the business process, enabling behavior-driven automatic permission adjustments and improving the dynamic responsiveness of data management.

[0119] While executing the change of field access rights, the system will automatically call the audit log recording module to capture and write the key contextual information in the permission extension process to form a complete permission change record entry. The record content includes at least: the unique number of the current processing node (used for process positioning), the field set (used to identify the range of controlled fields), the degree of status confirmation (as the basis for permission adjustment) and the final extension result (such as permission type and scope). The log structure is written to the permission audit database in a structured format (such as JSON or database table) and is bound to the current process instance ID to support subsequent retrieval, traceability and compliance verification. The purpose of this approach is to achieve visualization and traceability of permission changes, which not only meets audit requirements, but also provides a data basis for subsequent process status comparison and permission rollback.

[0120] When a rollback operation occurs in the process, such as the approval is revoked, the node status is manually corrected, or the process control logic is forced to jump to the previous node, the system will automatically trigger the permission rollback detection logic. This logic first obtains the actual status confirmation level of the current processing node, and then calls the permission extension history stored in the aforementioned record module to compare it with the current node status and field permission mapping relationship. If it is found that the current status is lower than the confirmation level at the time of the original extension, or the field permission no longer matches the original standard, the system will perform a permission rollback operation: reset the current field permission to the field permission range corresponding to the previous legal node in the process, and revoke write permissions or block unauthorized fields. This operation relies on the permission status version control mechanism in the system, which can restore field permission configuration according to the process node dimension. The purpose of this mechanism is to ensure that permission changes are consistent with the actual status of the process, avoid the risk of permission legacy due to process rollback, and ensure the security and timeliness of the entire data access process.

[0121] The above formulas are all dimensionless and numerical calculations. The formulas are obtained by collecting a large amount of data and performing software simulation to obtain the most recent real situation. The preset parameters in the formulas are set by technicians in this field according to actual conditions.

[0122] The above embodiments can be implemented in whole or in part via software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. A computer program product comprises one or more computer instructions or computer programs. When the computer instructions or computer program are loaded or executed on a computer, the processes or functions according to the embodiments of the present application are fully or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means (e.g., infrared, wireless, microwave, etc.). A computer-readable storage medium can be any available medium accessible by a computer or a data storage device such as a server or data center that contains a collection of one or more available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0123] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0124] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0125] In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the embodiments described above are merely illustrative. For example, the division of units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

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

[0127] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0128] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A dynamic data rights management method for data sharing, characterized in that: The specific steps include: Establish a binding relationship between the data processing stage and the field access rights, and form a mapping relationship between the data processing node and the field collection; Based on the formed mapping relationship, determine whether there is any incomplete progress in the data processing stage; Specifically: Based on the mapping relationship between the data processing node and the field set, the field set mapping entry corresponding to the current processing node is read to obtain the number of fields that have been actually opened for the processing node in the current process. The preset number of fields in the field set mapping entry is compared with the number of fields that have actually been opened. If the number of fields that have actually been opened does not reach the preset number of fields in the mapping entry, it is determined that the data processing stage has not been completed. In the case of incomplete progress during the data processing phase, process execution behavior information is collected and processed after collection, and converted into three types of structured values: status code, behavior completion ratio, and path stability value; Based on the three types of structured values ​​after conversion, the status confirmation degree of the current node is determined when the data processing stage has not yet completed the advancement; Based on the result of the node status confirmation degree, control whether the field access rights are extended and the extended field range; Execute the change operation of field access rights and record the node number, field set, confirmation degree and extension result during the field permission extension process. When the process rolls back, perform permission rollback based on the difference between the current node status and the recorded content.

2. The data sharing-oriented dynamic data rights management method according to claim 1 is characterized in that: In the case of incomplete progress during the data processing phase, process execution behavior information is collected and processed after collection, and converted into three types of structured values: status code, behavior completion ratio, and path stability value. Specifically: In the case of incomplete progress during the data processing phase, process execution behavior information is collected and preprocessed after collection; Extract the processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes from the pre-processed process execution behavior information; The processing status information of the current processing node specifically includes whether the processing status of the current processing node is one of the four processing states: task not accepted, processing, submission completed, or confirmed completed; the operation behavior information of the node responsible person specifically includes the number of operations performed by the node responsible person; the flow path information between nodes specifically includes whether the current node path has jumped; The extracted processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes are converted into three types of structured values: status code, behavior completion ratio and path stability value.

3. The data sharing-oriented dynamic data rights management method according to claim 2, characterized in that: The extracted processing status information of the current processing node, the operation behavior information of the node responsible person, and the flow path information between nodes are converted into three types of structured values: status code, behavior completion ratio, and path stability value. Specifically: According to the extracted processing status information of the current processing node, if the processing status of the current processing node is task not accepted, the value of the status code is determined to be 0 through the numerical mapping; if the processing status of the current processing node is processing, the value of the status code is determined to be 1 through the numerical mapping; if the processing status of the current processing node is submission completed, the value of the status code is determined to be 2 through the numerical mapping; if the processing status of the current processing node is confirmed completed, the value of the status code is determined to be 3 through the numerical mapping; The operation behavior information of the node responsible person is extracted. The number of operations performed by the node responsible person is calculated by comparing it with the total number of preset operations corresponding to the current processing node to obtain the behavior completion ratio. The specific calculation method is: behavior completion ratio = number of operations performed by the node responsible person / total number of preset operations corresponding to the current processing node; According to the flow path information between the extracted nodes, if the current node path has jumped, the path stability value is determined to be 0.8 through numerical mapping; If the current node path has not been jumped, the path stability value is determined to be 1.0 through numerical mapping.

4. The data sharing-oriented dynamic data rights management method according to claim 3 is characterized in that: Based on the converted three types of structured values, the status confirmation degree of the current node in the case of incomplete progress in the data processing stage is determined, which specifically includes the following steps: The three types of structured values ​​after conversion, namely, the state code, behavior completion ratio and path stability value, are calibrated as A, B and C respectively, where A represents the state code, B represents the behavior completion ratio and C represents the path stability value. Based on the converted state code and the behavior completion ratio, a behavior deviation index is generated; based on the converted state code and the path stability value, a path disturbance coefficient is generated; Based on the generated behavior deviation index and path disturbance coefficient, a state confirmation index is generated; Determine the pre-set state confirmation index threshold range, and compare it with the generated state confirmation index after determination, and determine the state confirmation degree of the current node when the data processing stage has not been completed according to the comparison result.

5. The data sharing-oriented dynamic data rights management method according to claim 4 is characterized in that: The specific acquisition logic of the behavior deviation index and path disturbance coefficient is as follows: Normalize the status code A to obtain the normalized status value GA, which is equal to the status code A divided by the maximum value of the status code 3; Add 1 to the behavior completion ratio B and the normalized state value GA, and denote them as B+1 and GA+1 respectively; Perform natural logarithm operation on B+1 and GA+1 respectively to obtain their respective logarithmic values, calculate the absolute value of the difference between the obtained logarithmic values, and the result is the behavior deviation index; Subtract the path stability value C from the value 1, and multiply the absolute value of the difference by the exponential power of the natural constant e. The result is the path disturbance coefficient, where the exponent of the exponential power is the normalized state value GA.

6. The data sharing-oriented dynamic data rights management method according to claim 5, characterized in that: Based on the generated behavior deviation index and path disturbance coefficient, a state confirmation index is generated, specifically: the behavior deviation index and the path disturbance coefficient are added by 1 respectively to obtain a first adjustment value and a second adjustment value; the first adjustment value and the second adjustment value are respectively subjected to reciprocal processing to obtain a first reciprocal value and a second reciprocal value; the first reciprocal value and the second reciprocal value are weightedly summed to generate a state confirmation index, and the index is calibrated as .

7. The data sharing-oriented dynamic data rights management method according to claim 6, characterized in that: Determine the pre-set status confirmation index threshold range , and after confirmation with the generated status confirmation index Perform a comparison and determine the degree of status confirmation of the current node when the data processing stage is not completed based on the comparison results. The specific comparison analysis is as follows: like ,In the data processing stage, if the progress is not completed, the status confirmation degree of the current node is low; like ,In the data processing stage, when the advancement is not completed, the status confirmation level of the current node is medium; like ,In the data processing stage, when the advancement is not completed, the status confirmation degree of the current node is high.

8. The data sharing-oriented dynamic data rights management method according to claim 7, characterized in that: Based on the result of the node status confirmation, whether the field access rights are extended and the extended field range are controlled. Specifically: When the node status confirmation level is low, the extension of field access rights is prohibited and the current field access rights range remains unchanged; When the node status confirmation level is medium, the field access rights are extended. The extension scope is limited to the field subset marked as low sensitivity in the field set corresponding to the current processing node. Only read permission is granted on this field subset, and write operations are not allowed. When the node status confirmation level is high, the field access rights are extended to include all fields in the field set corresponding to the current processing node, and read and write permissions are granted to the field set.

Images