Version archiving and permission borrowing management system in engineering project collaborative design

Abstract

The application discloses a version archiving and permission borrowing control system in cooperative design of engineering projects, relates to the technical field of engineering project management, and comprises the following modules: a data access module, which acquires engineering project, achievement directory, file submission, design achievement approval and file change data, and generates to-be-archived file records; an archiving verification module, which checks main files, attachments, file reference relationships and design achievement approval records, and re-verifies according to source record serial number changes; a version management module, which compares the to-be-archived files with current effective versions, and generates new versions and file change records; a borrowing approval module, which re-processes affected approval nodes when versions change, and generates temporary borrowing credentials for locking approved versions; an access control module, which executes browsing, downloading or printing according to the credentials; and an audit rollback module, which records business processing processes and processes version rollback. The application improves the corresponding accuracy of archiving content and approval content, and makes borrowing approval results consistent with version changes.

Description

Technical Field

[0001] This invention relates to the field of engineering project management technology, and in particular to a version archiving and access control system for collaborative design of engineering projects. Background Technology

[0002] Collaborative design in engineering projects typically involves multiple business stages, including project management, professional design, review and approval, deliverables submission, and document management. Design drawings, calculation sheets, specifications, and related approval records are continuously generated in different systems. To facilitate project implementation and data utilization, deliverables are usually organized according to project, design stage, specialty, and document category. After approval, they are archived to form an official version, and access, download, or printing is handled based on project member relationships, document confidentiality level, and borrowing purpose.

[0003] However, the existing methods still have two limitations: First, archived documents, output catalogs, and design output approval records are usually stored separately, and when documents are resubmitted or their numbers are changed, it is difficult to continuously confirm whether the actual archived content is consistent with the approved content; Second, borrowing approvals are mostly based on the version at the time of application, and when the version changes during the approval period, there is a lack of item-by-item verification between the original approval result and the current valid version, which can easily increase the situation of duplicate approvals or inconsistent version usage. Summary of the Invention

[0004] In view of the problems existing in the prior art, the present invention is proposed.

[0005] Therefore, this invention provides a version archiving and access control system for collaborative design of engineering projects, which solves the problems of difficulty in continuously verifying archived and approved content and the inability to adjust access approval results according to version changes in collaborative design of engineering projects.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a version archiving and access control system for collaborative design in engineering projects. The system includes: a data access module, which acquires data on engineering projects, deliverables catalogs, document submissions, design deliverable approvals, withdrawals, invalidations, number changes, and document security classifications; determines document ownership and generates records of files to be archived, document reference relationships, and source record numbers; an archive verification module, which verifies the main file, attachments, deliverables catalogs, document reference relationships, and design deliverable approval records; calculates the file content hash value; generates an archive verification record when the source record numbers before and after verification are consistent; and re-verifies based on newly added records when the sequence numbers change; and a version management module, which compares the archived files with the current valid version's file list, content hash value, file security classification, and attachment reference relationships; generates new versions and file change records when data changes; and updates the current valid version and its update sequence number. The borrowing approval module processes borrowing requests based on project member relationships, file access permissions, file security levels, and borrowing approval configurations. When a version change occurs during the approval process, the module reprocesses and checks the approval nodes and their dependent nodes for the changed fields. Upon approval, a temporary borrowing voucher is generated, locking the approved version and the file storage object. The access control module verifies the user, voucher, approved version, current valid version update number, allowed operations, validity period, and number of uses. It then performs browsing, downloading, or printing on the file storage object locked by the voucher. The module occupies the number of uses before delivery, confirms the occupancy after delivery, and releases the occupancy if delivery fails. The audit rollback module associates and saves archives, versions, borrowing approvals, vouchers, and file delivery records. It verifies version rollback requests and the hash values ​​of the files, approvals, and content of the previous historical version, updating affected vouchers and access records based on the rollback results.

[0007] As a preferred embodiment of the version archiving and access control system for collaborative design of engineering projects described in this invention, the acquisition of engineering project, deliverables directory, file submission, design deliverables approval, withdrawal, invalidation, number change, and file security classification data includes: after the data access module receives records sent by external business systems, it retrieves received records according to the source system number, source record number, and data type. If the business fields are the same, they are not written repeatedly. If the business fields are different, the modified field, the value before modification, the value after modification, and the modification time are saved. The source record sequence number is assigned in a continuously increasing order according to the order in which records are successfully received. The source record sequence number is not modified after being written, and the maximum source record sequence number of the corresponding file is updated after each new record is added.

[0008] As a preferred embodiment of the collaborative design system for engineering projects described in this invention, the process of determining file ownership and generating a record of files to be archived, file reference relationships, and source record numbers includes: the data access module determining file ownership according to the project number, design stage, specialty, file category, and file number; determining the main file and attachments of the same submission based on the file upload record referenced in the deliverable submission record or design deliverable approval record; when the same file number is uploaded multiple times, the corresponding deliverable submission record and file upload record are read backwards from the design deliverable approval record with an approved result; uploaded files not referenced by new approval records do not use the original approval result; and a record of files to be archived is generated when the file upload status is complete, the file storage object number exists, and the file size is greater than zero.

[0009] As a preferred embodiment of the version archiving and access control system for collaborative design of engineering projects described in this invention, the following steps are included: verifying the main file, attachments, deliverables directory, file reference relationships, and design deliverables approval records, and calculating the hash value of the file content: when the file record to be archived is in a pending verification state, the archiving verification module updates the record to "in verification," reads the project deliverables directory items and their directory record version numbers, and saves the maximum source record sequence number at the start of verification; reads all byte data of the main file and attachments according to the file storage object number, compares the actual number of bytes read with the file size, and calculates the hash value of the main file and each attachment using a 256-bit secure hash algorithm.

[0010] As a preferred embodiment of the version archiving and access control system for collaborative design of engineering projects described in this invention, the following steps are included: generating an archive verification record when the source record serial numbers before and after verification are consistent, and re-verifying based on newly added records when the serial number changes: the archive verification module compares the file set required by the deliverables catalog, the file set referenced by the deliverables submission records, and the file set referenced by each design deliverables approval node item by item, and verifies the approval process number, node order, pre-approval node, approval result, file upload record number, and content hash value of each necessary design deliverables approval node; after verification, the maximum source record serial number is read again, and an archive verification record is generated when the serial numbers before and after verification are consistent; when the serial numbers are inconsistent, newly added file upload, approval, withdrawal, invalidation, number change, or deliverables catalog change records between the two serial numbers are read and re-verified.

[0011] As a preferred embodiment of the version archiving and access control system for collaborative design of engineering projects described in this invention, the comparison of the archived files with the current valid version's file list, content hash value, file security level, and attachment reference relationship includes: the version management module compares the file list in the archive verification record with the current valid version item by item; when the file number, file quantity, content hash value, file security level, and attachment reference relationship are all the same, a duplicate submission record is generated; when there are changes such as file addition, content modification, file deletion, file number change, file security level change, or attachment reference relationship change, a corresponding file change record is generated according to the specific file.

[0012] As a preferred embodiment of the version archiving and access control system for collaborative design of engineering projects described in this invention, the following steps are included: updating the current valid version and the current valid version update sequence number: the version management module reads the historical maximum version sequence number in the same database transaction, generates an incrementing new version sequence number, saves the new version and file change records, updates the original current valid version to the historical version, updates the new version to the current valid version, and adds the current valid version update sequence number; before the transaction is committed, the version number of the engineering project results catalog record, the current processing record number of the design results approval node, and the source record sequence number are re-compared; if any data changes, the current version writing is cancelled and returned to the archiving verification module for reprocessing.

[0013] As a preferred embodiment of the version archiving and access control system for collaborative design of engineering projects described in this invention, the following steps are taken: When a version changes during the approval process, the approval nodes and their dependent nodes that check the changed fields are reprocessed. After approval, a temporary access certificate is generated that locks the approved version and the file storage object. This includes: When the access approval module enters the approval process for an access application, it saves the file number, content hash value, file security level, attachment reference relationship, and current valid version update sequence number of the application version; when a change in the current valid version update sequence number is detected during the approval process, the corresponding fields of the application version and the current valid version are compared, and the approval nodes that have checked the changed fields and all direct or indirect dependent nodes determined along the relationship with the preceding nodes are updated to be reprocessed, while the approval results that have not checked the changed fields and do not depend on the affected nodes are retained; after all necessary approval nodes have passed, a temporary access certificate that locks the application file record number, the approved version number, and the file storage object number is generated.

[0014] As a preferred embodiment of the version archiving and access control system for collaborative design of engineering projects described in this invention, the following steps are included: verifying the user, voucher, approved version, current valid version update number, allowed operations, validity period, and number of uses; performing browsing, downloading, or printing according to the file storage object locked by the voucher; occupying usage counts before delivery; confirming occupation after delivery; and releasing occupation upon delivery failure. This includes: the access control module verifying the logged-in user, voucher signature, voucher status, validity period, allowed operations, approved version number, current valid version update number at the time of issuance, and file storage object number based on the temporary borrowing voucher; comparing the current valid version number and current valid version update number for current valid version usage requests; verifying the approved version status and file storage object readable status for specified historical version viewing requests; and generating a usage count occupation record in the same database transaction after a download or print request passes verification. Upon delivery completion, the occupied quantity is updated to "confirmed," and upon delivery failure, cancellation, or exceeding the release period, the occupied quantity is updated to "released."

[0015] As a preferred embodiment of the version archiving and access control system in the collaborative design of engineering projects described in this invention, the following steps are included: Associating and saving archives, versions, access approvals, vouchers, and document delivery records; verifying version rollback requests and the hash values ​​of files, approvals, and content from the previous historical version; and updating affected vouchers and access records based on the rollback results. This includes: appending and saving audit records according to the order in which business records are received; continuously inputting the content hash value of the previous audit record and the business fields of the current audit record into a secure hash algorithm to generate the content hash value of the current audit record; and upon receiving a version rollback request, verifying the applicant's... The system retrieves the archive management permissions, current valid version number, and current valid version update sequence number. It reads the archiving verification record, main file, attachments, file reference relationships, design result approval record, and content hash value of the previous historical version to determine the affected borrowing applications, temporary borrowing vouchers, usage count records, and document delivery records. After a successful version rollback, the system locks the current valid version usage voucher of the previous version and updates it to "suspended." For specified historical version access vouchers, the system maintains the original state as long as the approved version file is readable and the permissions and validity period meet the requirements. Vouchers that have been suspended, replaced, or expired will not be restored to their original state.

[0016] The beneficial effects of this invention are as follows: By verifying the main file, attachments, results catalog, file reference relationships, and design results approval records through the archiving verification module, calculating the hash value of the file content, and comparing the source record serial numbers before and after verification, continuous confirmation of the archived content and approval basis is achieved, forming an archiving verification record, and achieving the effect of the archived version corresponding to the approved results; By comparing the content hash value, file security level, and attachment reference relationships of the application version with the current valid version through the borrowing approval module, the approval nodes and their dependent nodes of the changed fields are reprocessed and checked, and the unaffected approval results are retained, achieving the effect of adjusting the borrowing approval results with version changes. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of a version archiving and access control system for collaborative design of engineering projects.

[0019] Figure 2 Flowchart for archiving verification and re-verification of newly added records.

[0020] Figure 3 A flowchart for the reprocessing of version creation and borrowing approval.

[0021] Figure 4 This is a flowchart for file access and version rollback processing.

[0022] Figure 5 A comparison chart of the consistency rate of archived verification results under the percentage of newly added records in different verification periods.

[0023] Figure 6 A comparison chart of the consistency rate and retention rate of borrowing approval results under the different percentages of fields with varying versions. Detailed Implementation

[0024] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0025] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0026] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0027] Reference Figures 1-6 This is one embodiment of the present invention, which provides a version archiving and access control system for collaborative design of engineering projects, including the following steps: This system is deployed on an engineering project collaborative design management server. The server includes a processor and memory. The memory stores the program instructions used to implement the data access module, archiving verification module, version management module, borrowing approval module, access control module, and audit rollback module. The processor executes the corresponding program instructions to complete the data reading, comparison, verification, status update, record generation, and data sending processing for each module. The processing performed by the following modules is all implemented by the server running the corresponding program instructions.

[0028] Obtain data on engineering projects, deliverables catalogs, document submissions, design deliverable approvals, withdrawals, invalidations, number changes, and document security classifications; determine document ownership; and generate records of documents to be archived, document citation relationships, and source record numbers.

[0029] The data access module establishes data connections with the project management system, collaborative design system, drawing collection system, and design review system to acquire basic project records, design phase records, professional division of labor records, project deliverables catalog records, file upload records, deliverables submission records, approval milestone records, file withdrawal records, file obsolescence records, file number change records, and design phase change records. Basic project records include the project number, project name, and project manager; project deliverables catalog records include the design phase, specialty, file category, file number, main file, attachments, and planned archiving time. Each record stores the source system number, source record number, data type, data generation time, and data reception time.

[0030] The data access module receives records according to the data methods provided by the business system. When the business system sends data via messages, it reads the source record number and business fields; when it provides data via an interface, it reads newly added records according to the last saved query position; when it provides database change results, it reads newly added, modified, and deleted records. The query position is saved after reception is complete; if reception is interrupted, it continues reading from the most recently saved position.

[0031] When data with the same source system number, source record number, and data type is received, the current business field is compared item by item with the already saved fields. If all fields are the same, no new business record or source change event record is generated; only the current reception time is added. If any field is different, the original business record is retained, and a source change event record is generated, which includes the source system number, source record number, data type, change type, changed field, value before modification, value after modification, and change time. When the source system sends a deletion, withdrawal, or cancellation result, the already saved original business record is not deleted; corresponding source change event records are generated, recording the business status before deletion, withdrawal, or cancellation and the business status after the change. Changes in document number, document security level, design result approval results, and project result catalog records are generated in the same way.

[0032] Upon receiving a new business record for the first time, or upon changes such as modifications, deletions, withdrawals, invalidations, changes in document number or security classification, changes in design outcome approval results, or changes in the project outcome catalog, a new, continuously increasing source record sequence number is assigned according to the order in which the corresponding business record or source change event record is successfully written. Already assigned source record sequence numbers, and the pre-modification and post-modification values ​​in source change event records, are not overwritten or modified. No new source record sequence number is assigned to data with identical business fields and business statuses received repeatedly. The archiving verification module saves the maximum source record sequence number at the start of verification and reads it again before verification is complete. If the two sequence numbers are inconsistent, it reads the newly added business records and source change event records between the two sequence numbers, filters records related to the currently archived document based on the project number, document number, and related record numbers, and re-executes the archiving verification based on the filtering results.

[0033] When different business systems use different field names, the field mapping table is read to convert the source fields into fields used for project archiving. The field mapping table includes the source system number, source field name, source field value, archived field name, archived field value, effective date, and deactivation date. Project number, project number, and project code are converted into project numbers, while stage name, professional name, and file category are converted into fields used in the project deliverables directory record. When processing historical records, valid field mappings are selected based on the data generation time. If the same source field value corresponds to multiple archived field values ​​or no corresponding value exists, a field conversion exception record is generated, and no archived file record is generated.

[0034] After field conversion, the scope of engineering design documents is determined according to project number, design stage, specialty, document category, and document number. File upload records, deliverable submission records, approval node records, document withdrawal records, and document voiding records with all five fields identical are grouped into the same file. When a document number changes, a correspondence is established between two document numbers only if the document number change record simultaneously includes the project number, design stage, specialty, original document number, new document number, confirmer, confirmation time, and change basis record number. Number correspondence is not established based on file name, file size, or upload time.

[0035] The data access module assigns sequentially increasing source record numbers to newly received business records and source change event records corresponding to additions, modifications, deletions, withdrawals, invalidations, document number changes, design phase changes, professional changes, document security level changes, and design outcome approval changes, according to the order in which records are successfully received. Source record numbers are uniformly assigned within the same project number range and are not counted separately according to design phase, professional field, document category, or document number. Once a source record number is written, it is not modified, and the data generation time and data reception time are not used to rearrange the already assigned source record numbers. When a document number, design phase, or professional field changes, the corresponding source change event record simultaneously saves both the pre-change and post-change values ​​and continues to use the next source record number within the same project number range. Each time a business record or source change event record is successfully written, the maximum source record sequence number of the project is updated for the archiving verification module to compare the verification start sequence number and the verification end sequence number. If the two sequence numbers are inconsistent, the business records and source change event records between the two sequence numbers are read, and the records related to the current file to be archived are determined based on the file number before and after the change, the design stage, the profession, and the related record number, and then the archiving verification is re-executed.

[0036] Verify the main file, attachments, deliverables catalog, file reference relationships, and design deliverables approval records. Calculate the hash value of the file content. Generate archived verification records when the source record serial numbers are consistent before and after verification. If the serial numbers change, re-verify based on the newly added records.

[0037] The data access module reads the project deliverables catalog records and matches each submitted document with an item in the catalog. If all five fields match, the submitted document is considered a match. If a project deliverable is listed as a main document, it is registered as such; if it is listed as a calculation sheet, instruction manual, material list, or review sheet, it is registered according to the attachment number.

[0038] If the submitted document does not match any item in the project deliverables catalog and there is no catalog change record, a deliverables catalog mismatch record is generated. If it is confirmed that the document is a new deliverable, a project deliverables catalog change record is first generated, and then the matching is repeated. If it is confirmed that the document number or project affiliation is incorrect, the source business system modifies it and resends it. If it is confirmed that the document does not belong to the archiving scope, it is marked as not to be archived.

[0039] The data access module reads the project deliverables catalog records according to the inspection cycle configured in the archive management system. When the server's current time reaches the planned archiving time and the corresponding file does not have an upload completion record, a "File to be Archived Not Received" record is generated, and the planned archiving time, inspection time, and responsible professional are written into it. The inspection cycle is configured by hour or day, and modification records are saved.

[0040] The data access module determines the files included in a single deliverable submission based on the reference relationships in the business records. When a deliverable submission record references one or more file upload records, the referenced upload records are included in the same deliverable submission. When an approval node record references a deliverable submission record, the approval node record is associated with the corresponding deliverable submission. When an approval node record directly references a file upload record, the referenced file is used as the file actually checked by that approval node. When the main file and attachments are uploaded separately, these files are combined into the same deliverable submission only if the deliverable submission record or approval node record references both the main file and attachments. If there is no submission batch number and file reference relationship, the main file and attachments are not combined based on the upload time interval.

[0041] When multiple upload records exist for the same file number, the system reads the referenced deliverables and file upload records from the approval node record with an approved result, and includes the files actually referenced by the approval node in the archived scope. If a new file upload record appears after approval, but is not referenced by the new approval node record, the new uploaded file is saved separately, without using the original approval result. When an approval node references multiple files, the corresponding relationships are saved separately for each file.

[0042] An approval data anomaly record is generated when the submitted record or file upload record referenced by an approval node does not exist, the fields are inconsistent with the referenced file, or the referenced file has been withdrawn or invalidated. For approval nodes responsible for checking the content of the main file or attachments, the review system is designed to read the complete byte data of the corresponding file based on the file upload record actually referenced by the approval node when the approval node is completed, calculate the corresponding file content hash value at the time of approval using a 256-bit secure hash algorithm, and send the file upload record number and file content hash value along with the approval result to the data access module; for approval nodes that do not check file content, no file content hash value is generated. The data access module stores the approval process number, approval node number, approval node order, preceding approval node number, node processing sequence number, approval result, approval completion time, referenced file upload record number, and the file content hash value corresponding to the approval node responsible for checking file content. When there are multiple processing records for the same approval node, the record with the largest node processing sequence number is used as the current record; if the node processing sequence number is the same but the approval result is different, an approval result conflict record is generated. The archiving verification module determines the main file or attachment actually approved by the approval node based on the upload record number of the referenced file. It compares the hash value of the file content calculated when reading the file during archiving with the hash value of the file content during approval stored in the approval record item by item, and combines the processing results of all necessary approval nodes to determine whether the approval process corresponding to the project deliverable catalog item is completed.

[0043] A file upload record is generated only if the project number, design stage, specialty, file category, file number, and file storage object number are all non-empty, the file size is greater than zero, and the upload status is complete. If any condition is not met, a file upload data exception record is generated, and the unmet fields, source system number, and source record number are written to it. The archiving verification module reads the corresponding file based on the file storage object number in the file upload record, verifies whether the file can be read completely and whether the actual number of bytes read matches the file size, and calculates the file content hash value if the file is read completely and the number of bytes read matches the file size.

[0044] The data access module outputs records of files to be archived, a list of submitted documents, file reference relationships, approval node records, file number correspondences, and the sequence number of the largest source record, and sends them to the archiving verification module. It also saves records of mismatched result directories, unreceived files to be archived, abnormal field conversions, abnormal file upload data, abnormal approval data, and conflicting approval results. After anomaly handling is completed and the records of files to be archived are regenerated, they are then sent to the archiving verification module.

[0045] The archiving verification module reads the records of files to be archived, project deliverables catalog item numbers, project deliverables catalog record version numbers, deliverables submission document lists, file reference relationships, approval node records, file number correspondence relationships, file storage object numbers, and maximum source record serial numbers generated by the data access module. It then checks each of the main files, attachments, and approval data to be archived during the collaborative design process of the project and generates archiving verification records.

[0046] The processor reads the current status of the file record to be archived and updates it to "Verifying" only if the status is "Pending Verification". Status checking and updating are completed within the same database operation; processing stops if the update fails to prevent the same file record from being verified by multiple processing tasks simultaneously. After a successful status update, the processor reads the project number, design stage, specialty, document category, document number, project deliverables catalog item number, and project deliverables catalog record version number.

[0047] The processor reads the corresponding catalog item based on the project deliverables catalog item number and verifies whether the catalog item record version number matches the catalog version number in the file to be archived. If they do not match, it reads the catalog change record and re-determines the main file, attachments, and required approval nodes; if a file or attachment is canceled in the catalog change record, the deliverables submission file list is updated according to the changed catalog item; if a file or attachment is added in the catalog change record, the file to be archived record lacking the added file is changed to a pending supplementation status. If the corresponding catalog item or catalog version number cannot be obtained, a catalog data anomaly record is generated and verification stops.

[0048] The processor reads the maximum source record number and the current maximum source record number saved when the file to be archived was generated. If the previous number is greater than the current number, an abnormal source record number is generated; if they are equal, verification begins; if the previous number is less than the current number, it reads the newly added file upload records, deliverable submission records, approval node records, approval revocation records, document withdrawal records, document invalidation records, document number change records, engineering project deliverable catalog change records, design phase change records, professional affiliation change records, and document confidentiality level change records between the two numbers, redetermines the scope of files to be verified and the scope of approval nodes based on the newly added records, and updates the verification start number.

[0049] When a document number changes, the processor reads the document number mapping relationship and verifies the project number, design stage, specialty, original document number, new document number, confirmer, confirmation time, and change basis record number. If any field is missing, the mapping relationship is not used; if all fields are complete, the original document number and the new document number are mapped to the same archived file, and the document numbers before and after the change are retained respectively.

[0050] The processor reads the main file and attachments item by item according to the deliverables list. Each upload record should have a file storage object number, file size, upload completion time, and upload status. If the upload status is not complete, the file storage object number is empty, or the file size is not greater than zero, the record to be archived is changed to a pending supplementation status. The file storage object number is used to locate the independent file object formed by each upload, without searching for the file again based on the file name or ordinary storage path.

[0051] The processor reads file bytes based on the file storage object number and compares the actual number of bytes read with the file size in the upload record. If they are not equal, an incomplete file read record is generated; if they are equal, a 256-bit secure hash algorithm is used to calculate the content hash value of all bytes. Large files are read in segments according to storage order, with each segment continuously input into the same calculation process. After the last segment is processed, its content hash value is output; the calculation results of each segment are not directly concatenated. The main file and each attachment separately store the file storage object number, file size, and content hash value.

[0052] The processor compares the actual files read with each item in the project deliverables list. The project number, design stage, specialty, document category, and document number of the main file should match the list item; the attachment number, parent file number, project number, design stage, and specialty of the attachments should match the list item. If any main file or attachment required by the list item is not included in the deliverables list, a missing archive record is generated. If the deliverables list includes a file not listed in the list item, a deliverables list mismatch record is generated, and that file is not included in this archive verification.

[0053] When main files and attachments are uploaded in separate batches, the processor reads the file reference relationships. If a submission record or approval node record references both the main file upload record and the attachment upload record, these files are considered to belong to the same submission. If there is no submission batch number and no explicit reference relationship, files are not grouped based on upload time, file name, or file size. When the same attachment is referenced by multiple main files, the reference record number between each main file and attachment is saved separately; when an attachment is replaced, the approval record corresponding to the original attachment is not used for the replaced attachment.

[0054] The processor reads the approval node records according to the approval node numbers required by the project deliverables catalog. All necessary approval nodes should belong to the same approval process, or have a clear succession relationship in the approval process configuration. Each node reads the current processing record number, node processing sequence number, approval result, approval completion time, previous approval node number, previous approval result number, and the file upload record number referenced. The current result of the previous node should be "passed," the completion time of the previous node should not be later than the completion time of the current node, and the previous approval result number referenced by the current node should be consistent with the actual record.

[0055] Approval nodes responsible for checking the content of main files or attachments should save the upload record number of the referenced file and its corresponding content hash value. The processor compares the file set saved by the approval node with the list of submitted deliverables, and compares the content hash values ​​of the main file and attachments item by item. If a required file is missing, another upload record is referenced, or the content hash value is different, an approval content inconsistency record is generated. Approval nodes that only check project participation relationships, archiving periods, or file security levels should read their check fields according to the approval process configuration, and are not required to save the file content hash value.

[0056] When an approval node references a file that has a withdrawal, voiding, or approval revocation record, the processor determines the affected object based on the referenced record number and the node processing sequence number. If the withdrawal, voiding, or approval revocation occurs after the current approval result, the current approval result is no longer used as the basis for archiving; if a new upload record and a new approval node record have been created, the verification is carried out again according to the new file reference relationship.

[0057] After verifying the files, attachments, references, and approval nodes, the processor reads the current maximum source record number again. If this number differs from the verification start number, the processor reads the new record and re-determines the file scope, directory requirements, and approval results; the verification result for this time is not sent to the version management module. If the two numbers are the same, the status of the file to be archived is updated from "in verification" to "in archiving," and an archive verification record is generated.

[0058] The data access module writes the file security classification to the archived file record. The archive verification module reads the file security classification from the archived file record and writes it to the archive verification record. The archive verification record includes the archive verification record number, project number, design stage, specialty, file category, file number, project deliverables catalog item number, project deliverables catalog record version number, file storage object number of the main file and attachments, file size, content hash value, file security classification, file reference record number, approval process number, current processing record number of each approval node, verification start number, verification end number, verification result, and verification completion time. When the verification result is passed, the archive verification record is sent to the version management module. If there are directory data anomalies, missing files, incomplete file reading, missing reference relationships, incomplete approval nodes, or inconsistent approval content, the corresponding record is saved, and the archived file record is updated to "to be supplemented" or "verification failed."

[0059] The archived files are compared with the current valid version in terms of file list, content hash value, file security level, and attachment reference relationships. When data changes, a new version and file change record are generated, and the current valid version and its update sequence number are updated. File reference relationships are generated based on the reference fields of each file in the same deliverable submission. These relationships record the correspondence between the main file and attachments, as well as other established reference relationships between deliverable files. The correspondence between the main file and attachments is considered an attachment reference relationship within the file reference relationships. Subsequent archive verification and version comparisons use the complete file reference relationships as the processing object, with attachment reference relationships participating in verification and comparison as part of the file reference relationships.

[0060] The version management module reads the archive verification record sent by the archive verification module, reads the corresponding record according to the record number of the file to be archived in the archive verification record, compares the current archived file with the current valid version, determines whether it is a duplicate submission or a new version, generates version record and file change record, updates the current valid version and the current valid version update sequence number, and sends the version data to the borrowing approval module, access control module and audit rollback module.

[0061] After receiving the archive verification record, the processor reads the verification result, the record number of the file to be archived, and the record status. If the verification result is successful and the record status is "archiving," the status is updated to "version writing." The status check and update are completed in the same database operation. If the update fails, the verification result is not successful, or the record is not in the archiving process, no version record is generated.

[0062] The processor determines file ownership based on project number, design stage, specialty, and document category, then queries historical versions according to file number and its corresponding relationships. Different files in the design stage have separate version records; files with the same number are not grouped into the same version. When a file number change record exists, starting with the current file number, it reads earlier file numbers one by one according to the relationship between the new and original file numbers, and uses all the read file numbers for querying historical versions. If a file number that has already been read reappears, a file number correspondence anomaly record is generated, the record for the file to be archived is updated to pending verification, and no further versioning is performed.

[0063] If no historical version exists, this archive is considered the first archive. If a historical version exists, the current valid version, its main file, attachments, file security level, project deliverables catalog item number, project deliverables catalog record version number, file content hash value, file reference record number, and approval process number are read. If the file number, number of main files and attachments, hash value of each file content, reference relationship between main file and attachments, file security level, project deliverables catalog item number, catalog record version number, and approval process number are all the same, a duplicate submission record is generated, and a new version is not created. The file storage object number is used to locate the file object formed each time it is uploaded, but it is not a condition that duplicate submissions must be identical. The duplicate submission record saves the current valid version number, archive verification record number, source system number, source record number, submitter, and submission time, and updates the record of the file to be archived to show that the duplicate submission has been confirmed.

[0064] When there are new files, modified file content, changes in attachment references, changes in file security levels, changes in file numbers, or a reduction in files with directory cancellation or obsolescence records, the new version will be processed. Files that exist in the current valid version but are not in the current archived file list will only be recorded as deleted if the project deliverables directory change record explicitly cancels the file, or if the obsolescence record includes the file number, obsolescence version, reason for obsolescence, approver, and approval time. If corresponding evidence is lacking, a record indicating missing evidence for version file reduction will be generated, the file to be archived will be updated to pending verification, and the file will be returned to the archive verification module.

[0065] The processor generates file change records for each specific file. Files that exist in a new version but not in the current valid version are recorded as newly added; files that exist in both the old and new versions but have different content hash values ​​are recorded as modified; files with directory cancellation or file obsolescence records and removed from the new version are recorded as deleted; files whose file numbers have changed and have complete number change records are recorded as file number changes; if the content of the main file or attachments remains unchanged but the reference relationship changes, it is recorded as an attachment reference relationship change; if the file's security level changes, the security level before and after the change is recorded. If the file number changes and the content hash value is different, both a file number change record and a file modification record are generated. When a file is deleted and then re-added in the next version, both deletion and addition records are generated; when the file content is modified and then restored to an earlier version, the modification is still recorded separately for adjacent versions.

[0066] Version sequence numbers are used to arrange official versions of the same file. The first archive entry is assigned a sequence number of 1, and a new version is assigned the sequence number of the highest historical version plus one. The version number consists of the actual file number used in that version and the version sequence number; historical version numbers are not modified due to changes in file numbers. Version rollback does not change existing version sequence numbers. The current valid version update sequence number indicates whether the current valid version points to a different version. It is assigned a sequence number of 1 when the current valid version is first created, and incremented by one each time a new current valid version is created or a version rollback is performed; duplicate commits, additions to source records, and modifications to field mapping tables do not increment this sequence number.

[0067] Before writing a new version, the processor requests a version write tag based on the project number, design stage, specialty, file category, and all file numbers obtained through the file number correspondence. If the version write tag does not exist, it is generated and written to the archive verification record number in the same database operation; if it already exists, the current archive verification record remains in the archiving process, waiting to be processed in ascending order of verification completion number. After obtaining the version write tag, the processor reads the historical maximum version sequence number, generates a new version sequence number, and saves the new version record and file change record in the same database transaction.

[0068] Before committing a transaction, the processor rereads the project deliverables catalog record version number, the current processing record number of each approval node, and the maximum source record number before version writing, and compares them with the catalog record version number, the current processing record number of each approval node, and the verification end number in the archive verification record. If any data is inconsistent, the transaction is rolled back, the version write flag is deleted, and the file record to be archived is updated to be verified. If all data is consistent, the new version's main file, attachments, file storage object number, content hash value, file reference relationship, file security level, approval record correspondence, and file change record are saved in the same transaction. The original currently valid version is updated to the historical version, the new version is updated to the currently valid version, and the current valid version update number is incremented by one. After a successful transaction commit, the file record to be archived is updated to archived and the version write flag is deleted; if the transaction write fails, it resumes to archiving processing, saves the reason for the failure, and deletes the version write flag.

[0069] Upon receiving a version rollback request verified by the audit rollback module, the processor reads the project number, file number, current valid version number, proposed restore version number, rollback reason, applicant, and approval record number. The proposed restore version should be in a historical version state, with its main file and attachments accessible according to the file storage object number, the recalculated content hash value consistent with the version record, and the approval record still existing. Before committing the transaction, the current valid version number is checked again. If the number has not changed, the current valid version before the rollback is updated to a historical version, the proposed restore version is updated to the current valid version, the current valid version update sequence number is incremented by one, the original version sequence number remains unchanged, and a file change record from the version before the rollback to the proposed restore version is generated.

[0070] The version management module outputs the current valid version number, the current valid version update sequence number, the original version number, the new version number, the version effective time, the version formation type, the version file list, the file storage object number, the file security level, the main file and attachment reference relationship, the file change record number, the file change record, the approval record correspondence relationship, and the version status, and sends them to the borrowing approval module, the access control module, and the audit rollback module.

[0071] Borrowing applications are processed based on project member relationships, file access permissions, file security levels, and borrowing approval configurations. When a version changes during the approval process, the approval node and its dependent nodes that have changed fields are reprocessed and checked. After approval, a temporary borrowing certificate is generated that locks the approved version and the file storage object.

[0072] The borrowing approval module reads the current valid version number, current valid version update sequence number, version file list, file storage object number, file content hash value, file security level, file reference relationships, file change records, and version status output by the version management module, and receives borrowing requests. A borrowing request includes a borrowing request number, applicant number, project number, purpose of request, request operation, request start time, request end time, number of downloads requested, and number of copies requested. When a borrowing request contains multiple files, separate application file records are generated according to the file numbers. Each application file record stores the application version number, file number, file content hash value, file security level, file storage object number, and the reference relationships between the main file and attachments.

[0073] The processor reads the project member records, file access permission records, user permission level records, and permission mapping table. The project member records include user ID, project ID, member's valid time and professional specialty; the file access permission records include user ID, project ID, permitted document scope, permitted operations, valid time, and approval record number; the user permission level records include user ID, permission level, valid time, and approval record number; the permission mapping table includes document security level, minimum permission level, and permitted operations. Processing continues if the applicant is a project member and their valid time covers the application period, or if their file access permission covers the applied document, application operation, and application period. If the permission mapping table does not allow the current permission level to access the corresponding document security level, a borrowing application rejection record is generated.

[0074] Application purposes are divided into "Using the Current Valid Version" and "Viewing a Specified Historical Version." "Using the Current Valid Version" only allows selection of the currently valid version at the time of application submission; "Viewing a Specified Historical Version" allows selection of historical versions. Application operations include online browsing, downloading, and printing. When downloading is included, the number of downloads requested is a positive integer; when downloading is not included, the number of downloads requested is zero. The number of print copies is entered according to the same rules. If the application end time is no later than the application start time, the requested version does not exist, the file storage object number is empty, or the application period and number of requests exceed the configured limits, the application file record will be updated to "Pending Supplementation."

[0075] The processor checks whether there are any pending applications or effective certificates for the same applicant, the same project, the same document, and the same version. Duplicate records are not generated for pending applications; if an effective certificate covers the current operation and timeframe, the original certificate number is saved; if the current operation, timeframe, or number of operations exceeds the scope of the original certificate, a new application document record is generated.

[0076] The processor reads the borrowing approval configuration record based on the file's security level, application purpose, and application operation. The borrowing approval configuration record includes the configuration version number, effective date, deactivation date, approval process number, approval node number, node sequence, preceding approval node number, serial or parallel processing method, node check fields, approver determination rules, node processing period, maximum borrowing period, maximum number of downloads, and maximum number of prints. This configuration is used when the application submission time falls within the configuration's valid timeframe, and the configuration version number is written to the application file record; if the applicable configuration is not available, a borrowing approval configuration missing record is generated.

[0077] Approval node status includes pending approval, in progress, approved, returned, transferred, withdrawn, timed out, and pending reprocessing. Serial nodes begin after all preceding nodes have passed; parallel nodes process separately, and nodes dependent on all parallel nodes begin after all parallel nodes have passed. When an approver completes processing, they save the approval node record number, approver number, approval time, approval result, actual inspection field values, and preceding node record number. When an applicant withdraws an application, incomplete nodes are updated to "withdrawn"; when an approver transfers processing, the approver and transfer time before and after transfer are saved; if the processing deadline is exceeded, it is updated to "timed out" and sent to the designated personnel in the configuration record, without directly generating an approval result.

[0078] When an application enters the approval process, the processor saves the current valid version number, the current valid version update sequence number, the file number of the applied version, its content hash value, file security level, and file reference relationships. After each approval node is completed, the current valid version update sequence number is read again. When the update sequence number changes, the corresponding file in both the applied version and the current valid version is read. The file number correspondence is used to confirm whether they belong to the same file, and the existence of the file, file number, file content hash value, file security level, and file reference relationships are directly compared. Version change records are used to verify the file number change, deletion, and restoration times.

[0079] The processor compares the changed fields with the checked fields of each borrowing approval node item by item. If a node's checked fields contain any changed fields, the corresponding node is identified as an affected approval node and updated to be reprocessed. For each affected approval node, a reverse lookup relationship is established based on the preceding approval node number in the approval node record. The approval nodes that point to the affected approval node with the preceding approval node number are found, and the found nodes are identified as direct dependent nodes. Then, each direct dependent node is used as a new query object, and its subsequent approval nodes are searched level by level in the same way until no new subsequent approval nodes exist, thus obtaining all indirect dependent nodes. Completed direct and indirect dependent nodes are updated to be reprocessed, and the process is re-executed according to the original approval node order. Parallel nodes that have not checked changed fields and are not affected approval nodes, direct dependent nodes, or indirect dependent nodes retain their original approval results. When a file in the current valid version of the borrowing application is deleted, the approval of that file is stopped. If the original version in the application can still be read when a specified historical version is viewed, the original version continues to be processed. Files added in the new version are not added to the original borrowing application.

[0080] After all necessary nodes have passed verification, the processor rereads the current valid version number, current valid version update sequence number, application version status, file content hash value, file security level, file reference relationships, applicant permissions, and current processing records of each approval node within the same database transaction. If all data matches the final verification result, a temporary borrowing voucher is generated; if any data changes, the voucher generation is revoked, and the approval node requiring further processing is redefined.

[0081] The temporary borrowing voucher includes the voucher number, borrowing application number, application document record number, user number, project number, document number, approved version number, current valid version update sequence number at the time of issuance, file storage object number, file content hash value, file security level, allowed operations, valid start and end time, maximum number of downloads, maximum number of prints, confirmed number of downloads, confirmed number of prints, voucher status, configuration version number, current processing record number of each approval node, random number, server key version number, and voucher signature. The borrowing approval module performs unified serialization processing on the fields involved in the voucher signature calculation: character fields are uniformly encoded in UTF-8; time fields are uniformly converted to a fixed format containing year, month, day, hour, minute, second, and time zone offset; the number of times and sequence number fields are uniformly converted to decimal integer form without adding thousands separators or plus signs; empty values ​​are uniformly recorded as empty value markers. Following a fixed order, the following fields are sequentially written: voucher number, borrowing application number, application document record number, user number, project number, document number, approved version number, current valid version update sequence number at the time of issuance, file storage object number, file content hash value, file security level, allowed operations, valid start and end time, maximum number of downloads, maximum number of prints, configuration version number, current processing record number of each approval node, random number, and server key version number. The encoded byte length and byte data for each field are then concatenated to form a unique voucher signature byte sequence. The borrowing approval module uses a hash-based message authentication code algorithm with a 256-bit secure hash function to calculate the voucher signature from the byte sequence. Confirmed download counts, confirmed print counts, and voucher status are stored in the database as updatable fields and are not included in the voucher signature calculation. The access control module obtains the corresponding key based on the server key version number, reconstructs the credential signature byte sequence according to the same field order, character encoding, time format, numeric format, null value representation, and length writing rules as when it was issued, and calculates the credential signature. If the calculated result is inconsistent with the credential signature stored in the credential, access is denied and a credential verification exception record is generated. If the two are consistent, the credential status and confirmed usage count in the database are read for access verification. When the credential status or confirmed usage count is updated, the credential signature is not recalculated.

[0082] When the current valid version changes, the processor compares the file number, file content hash value, file security level, and file reference relationship of the original approved version with the new current valid version. If the file number, file content hash value, file security level, and file reference relationship remain unchanged, but only the approved version number, current valid version update sequence number, or file storage object number changes, and the applicant's permissions are still valid, a new certificate locking the new current valid version and the corresponding file storage object is generated. If any file number, file content hash value, file security level, or file reference relationship changes, a new certificate is not generated directly. Instead, the approval node checking the changed fields and its direct or indirect dependent nodes are updated to "pending reprocessing." A new certificate is generated only after all necessary approval nodes have passed. The effective start time of the new certificate is the later of the issuance time and the original approval start time, and the effective end time remains the original approval end time. The maximum number of downloads and the maximum number of prints continue to use the original approval count corresponding to the application document record. After a new credential is generated, the access control module associates the original credential, the new credential, and the replacement credentials already generated under the same application document record number. It then summarizes the confirmed download count, confirmed print count, unreleased download count, and unreleased print count, and uses the result of subtracting the corresponding confirmed and unreleased counts from the original approved count as the current available count. The document delivery record in progress continues to reference the original credential and its original usage count record. Upon delivery completion, the corresponding usage is updated to "confirmed"; upon delivery failure, cancellation, or exceeding the release period, the corresponding usage is updated to "released." After a change in usage status, the access control module re-summarizes the confirmed and unreleased counts of each credential under the same application document record upon the next access request, thereby re-determining the current available count. The maximum download count and maximum print count already issued in the new credential are not modified. After a new credential is successfully generated, the original credential is updated to "replaced"; if re-approval is required, it is updated to "suspended"; and when the credential expires, all original approved counts have been confirmed for use, or the approval is revoked, it is updated to "invalid."

[0083] The borrowing approval module outputs borrowing application records, application document records, borrowing approval node records, approval results, temporary borrowing vouchers, voucher signature results, and voucher status change records. It also sends the vouchers to the access control module and sends the approval process records and voucher status change records to the audit rollback module.

[0084] Verify the user, credentials, approved version, current valid version update number, allowed operations, validity period, and number of uses. Perform browsing, downloading, or printing according to the file storage object locked by the credentials. Use the number of uses before delivery, confirm the use after delivery, and release the use if delivery fails.

[0085] The access control module receives online browsing, downloading, or printing requests from users for engineering project design deliverables. It reads temporary borrowing vouchers, voucher signatures, application document records, and voucher status change records generated by the borrowing approval module. It also reads version status, current valid version number, current valid version update sequence number, file size, file storage object number, and file content hash value stored by the version management module. The processor processes access requests according to the user who approved the voucher, the engineering project, the application document, the version, the operation type, the validity period, and the allowed number of access attempts, generating access request records, access attempt records, document delivery records, and access processing results.

[0086] When a user submits an access request, the processor records the access request number, credential number, login session number, project number, application document record number, request version number, request operation, request time, number of copies to be printed, and original document delivery record number. When requesting online browsing or download, the number of copies to print is zero; when requesting printing, the number of copies to print is a positive integer. The original document delivery record number is only used for continued transmission of files that have not been downloaded completely. If required fields are missing or the request operation does not fall under online browsing, downloading, or printing, the file will not be read.

[0087] The processor reads the user ID, session expiration time, and session status based on the login session number. If the session does not exist, has expired, or the user ID differs from the credential user ID, a user identity mismatch record is generated. If the identity matches, the processor reads the user account status, project member records, file access permission records, user permission level records, and permission mapping table. The account status should be normal, the project member records or file access permission records should cover the request time, application documents, and requested operations, and the user permission level should allow access to the corresponding file's security level.

[0088] The processor reads the credential fields, credential signature result, and server key version number from the database based on the credential number. The fields involved in the signature are read from the database credential record, and the processor recalculates the signature according to the field order, separator method, and character encoding used when the credential was issued. Access is denied if the signatures differ, the key version number is missing, or the credential record is missing. After the signatures match, the database credential status is read. If the database status differs from the signature fields, the database status prevails.

[0089] Processing continues as long as the voucher status is active and the current time is within the validity period. If the current time exceeds the validity period's end time, the voucher will be updated to expired. When the voucher status is suspended or expired, no new document delivery record will be created; when the voucher status is replaced, only document deliveries that were created and are in progress before the status change time are allowed to continue processing.

[0090] The processor reads the main file number, attachment number, file category, and parent main file number based on the application document record number. When accessing the main file, the attachment number is empty; when accessing attachments, both the attachment number and the parent main file number are verified. The application document record number should correspond to a unique file storage object number approved by the credential. The processor does not select files using user-submitted file paths, file names, or external addresses. Archived file storage objects cannot be overwritten; a new storage object number is generated when a file is replaced.

[0091] When the application is for use of the current valid version, the approved version number of the certificate is compared with the current valid version number, and then compared with the update sequence number of the current valid version at the time of access. If both match, processing continues. If either data is different, a version inconsistency record is generated, and the original certificate is not restored even if the approved version becomes the current valid version again after a version rollback. When the application is for viewing a specified historical version, the approved version is not required to be equal to the current valid version, but the approved version should be in a historical version or current valid version state, and the file storage object should be readable.

[0092] After the initial verification is successful, the processor generates a file delivery record, saving the delivery record number, access request number, credential number, application document record number, user number, approved version number, current valid version update sequence number, file storage object number, file size, content hash value, operation type, creation time, delivery status, and range of delivered bytes. During file delivery, the file is read only based on the file storage object number in the file delivery record, and a fixed external address is not provided to the user.

[0093] When a download request arrives, the processor reads the maximum number of downloads, the number of confirmed downloads, and the number of unreleased downloads within the same database transaction. If there are at least one remaining download attempt, a download attempt occupancy record with a occupancy count of one is generated; otherwise, the download is rejected. Print requests generate a print count occupancy record based on the requested number of copies, ensuring that the remaining print count is not less than zero. Online browsing does not consume download attempts. The occupancy record stores the occupancy record number, operation type, occupancy quantity, occupancy time, release period, and occupancy status. The processor reads the operation type, basic delivery duration, unit file size, increment duration corresponding to the unit file size, and maximum delivery time from the access control configuration record. The unit file size must be greater than zero, and the basic delivery duration, increment duration corresponding to the unit file size, and maximum delivery time must all be at least zero, using the same time unit. Matching parameters according to operation type, the file size is divided by the unit file size and rounded up to obtain the calculation quantity corresponding to the file size. The product of this calculation quantity and the increased duration is added to the base delivery duration to obtain the allowed delivery duration. If the allowed delivery duration exceeds the maximum delivery time, the maximum delivery time is taken, and the sum of the occupied time and the allowed delivery duration is determined as the release period. If the access control configuration record lacks the corresponding operation type parameter, the unit file size is not greater than zero, or any duration parameter is less than zero, the release period calculation is not performed, the generation of the count occupancy record is refused, and an access control configuration exception record is generated.

[0094] After the usage count is completed, the processor re-verifies the credential signature, credential status, validity period, logged-in user ID, user permissions, approved version number, allowed operations, file storage object number, file size, content hash value, and file security level within the same transaction. Requests for the currently valid version also need to compare the currently valid version number with the currently valid version update sequence number; requests for viewing specified historical versions check the approved version status and file storage object. If the verification fails, the usage count is updated to "released," and the file delivery record is updated to "stopped."

[0095] After verification, the processor reads the file bytes according to the file storage object number, compares the actual number of bytes read with the file size in the voucher, and calculates the content hash value using a 256-bit secure hash algorithm. Large files are read in segments according to storage order, with each segment continuously input into the same calculation process. If the actual number of bytes or the content hash value is inconsistent, a file storage data inconsistency record is generated, and the occupied count is released.

[0096] After the online browsing request is verified, the processor converts the file into read-only display data and writes the user ID, project ID, version ID, and server time to the display page. The access control configuration record stores the browsing idle termination time, which is pre-configured based on the session security policy and network connection timeout policy for project file access. This time must be greater than zero and uses a time unit consistent with the server time. After a browsing session is established, the processor records the server time of the most recent valid browsing request. This time is updated upon receiving a new valid browsing request. The browsing session ends when the difference between the current server time and the server time of the most recent valid browsing request reaches the browsing idle termination time. The browsing session also ends upon receiving a browsing end request, when the login session expires, or when a temporary borrowing credential expires. If a temporary borrowing credential is updated to paused or expired during browsing, new read-only display data is stopped, and the corresponding browsing session is closed. If the browsing idle termination time in the access control configuration record is missing or not greater than zero, a new browsing session is not established, and an access control configuration exception record is generated.

[0097] The downloaded file is sent in segments according to byte order, and the start and end positions of each segment, as well as the sending result, are saved. Resume requests from breakpoints carry the original file delivery record number and login session number, sending only the incomplete byte range. When the entire non-overlapping byte range covers the complete file and the file transfer interface returns a complete response status, the download is updated to complete, the confirmed download count is incremented, and the count is released. The allocated space is released upon transmission failure, user cancellation, or expiration of the release period.

[0098] After the print request is verified, the processor generates a print job according to the fixed file storage object number, saving the print job number, print device number, the number of copies requested, and the job status. Once the print device returns the planned number of copies, the number of completed copies, and the number of incomplete copies, the processor confirms the occupancy of the completed copies and releases only the incomplete copies. If the number of completed copies cannot be obtained, the print job is updated to await manual confirmation, and all occupancy is not automatically released. If a voucher is paused or expired, print jobs that have not yet started are canceled.

[0099] The access control module sends access request records, signature verification results, identity and permission verification results, version inconsistency records, access usage records, document delivery records, download results, print results, rejection reasons, and credential status change records to the audit rollback module. When a version inconsistency is detected, the module sends the application document record number, approved version number, currently valid version number at the time of access, currently valid version update sequence number at the time of issuance, and currently valid version update sequence number at the time of access to the borrowing approval module. The borrowing approval module reads the corresponding borrowing application and application document record, compares the original approved version with the currently valid version's document number, document content hash value, document security level, and document reference relationship, and performs credential substitution or updates the affected approval node and its direct or indirect dependent nodes to pending reprocessing based on the comparison results. When user permissions are detected as invalid, the module sends the user number, project number, application document record number, credential number, and permission verification results to the borrowing approval module. The borrowing approval module re-verifies project member relationships and file access permissions; if permissions are still invalid, the corresponding temporary borrowing credential is updated to invalid, and the generation of new temporary borrowing credentials for the corresponding application document record is stopped. When the number of downloads or prints of the voucher is exhausted, the access control module will directly update the corresponding temporary borrowing voucher to invalid and send the result of the exhaustion of the number of downloads and the voucher status change record to the audit rollback module, instead of sending it to the borrowing approval module.

[0100] It links and saves archives, versions, borrowing approvals, vouchers, and document delivery records; verifies version rollback applications and the hash values ​​of documents, approvals, and content from the previous historical version; and updates affected vouchers and access records based on the rollback results.

[0101] The audit rollback module reads business records generated by the data access module, archiving verification module, version management module, borrowing approval module, and access control module. It establishes a corresponding relationship according to the number of each business record and adds and saves records of project design results archiving, version formation, borrowing approval, voucher issuance, online browsing, downloading, printing, access denial, and version rollback. It checks the voucher expiration and usage frequency according to the file management configuration. It receives version rollback requests, verifies the request permissions, the version file to be restored, and the affected borrowing data, and sends them to the version management module after obtaining the version rollback approval record.

[0102] When the processor receives records from various modules, it checks the source module name, source business record number, record type, server time, and main associated number. If all required fields are complete, an audit record sequence number is requested; if a field is missing, an audit data anomaly record is generated and the original received content is saved. If data from the same source module, source business record number, and record type arrives repeatedly, the business fields are compared item by item. Fields that are identical are not written repeatedly; for fields that are different, the modified field, the value before modification, the value after modification, the modification time, and the modification source are saved.

[0103] Audit record numbers are sequentially incremented according to the system's receiving order. Within the same database transaction, the processor reads the current maximum audit record number, performs a conditional update on the record with the maximum number, increments the number upon successful update, reads the hash value of the previous audit record, and writes it to the current record; if the update fails, the maximum number is read again. The source system generation time, system reception time, and business processing completion time are stored separately.

[0104] The archived audit records store the file record number to be archived, the archived verification record number, the result catalog item number, the verification result, and the reason for failure; the version records store the original version number, the new version number, the version sequence number, the current valid version update sequence number, the version formation type, the file size, the file security level, and the version change record number; the borrowing records store the borrowing application number, the application document record number, the approval configuration version number, the borrowing approval node record number, the approver, the approval result, and the temporary borrowing voucher number; the access records store the user number, the login session number, the file storage object number, the operation type, the processing result, the number of times the record is used, the file delivery record number, the actual number of bytes delivered, and the number of copies printed.

[0105] Each audit record is standardized according to a unified character encoding, date format, field order, and field representation rules. The set of business fields involved in the content hash value calculation is pre-determined according to the audit record type, and the field names and values ​​are written sequentially in a fixed field order. When a field exists but its value is empty, a unified null value marker is written; if a field does not belong to the current audit record type, it is not written, to distinguish between empty fields and non-existent fields. All standardized business fields and the content hash value of the previous audit record are continuously input into a 256-bit secure hash algorithm to generate the content hash value of the current audit record. The content hash value of the previous audit record of the first audit record uses a fixed-length all-zero value. When a new audit record is added, the content hash value of the previous audit record is checked to see if it is consistent with the previous hash value saved for the current record; and according to the inspection cycle in the audit inspection configuration record, the same standardization process and content hash value calculation are re-executed for the specified audit record sequence number range. If the recalculated result is inconsistent with the saved content hash value, an audit record continuity anomaly record is generated, and the anomaly audit record number, the previous audit record number, the saved content hash value, and the recalculated content hash value are saved.

[0106] Audit logs can only be added and queried. When correction is required, personnel with audit log management permissions submit a correction request and obtain a correction approval record. The processor adds an audit correction record, saving the original audit record number, original content hash value, corrected fields, value before correction, value after correction, reason for correction, person making the correction, correction approval record number, and correction time, without overwriting the original record.

[0107] The access control module checks credentials in real time when an access request arrives, while the audit rollback module processes credentials for which no new access requests have occurred according to the check cycle configured in the document management system. If the server's current time exceeds the valid end time, or if the confirmed download count and print count have reached the approved limits and the credential does not include online browsing operations, the effective or suspended credential will be changed to invalid through conditional updates. Similarly, if a borrowing approval result is revoked, the corresponding credential will be changed to invalid. If other modules have already completed the same status update, a status change record will not be generated again. The credential status change record saves the status before the change, the status after the change, the reason for the change, the trigger record number, and the change time.

[0108] The processor compares the confirmed download count, confirmed print count, and unreleased occupancy quantity in the voucher with the occupancy record, document delivery result, and print task result. If a confirmed download count lacks a corresponding completion record, released occupancy is still counted as unreleased occupancy, or the same document delivery record corresponds to multiple effective occupancy records, an abnormal voucher count data record is generated. The records management personnel create a count correction record based on the document delivery record, recording the original count, corrected count, corresponding document delivery record number, reason for correction, applicant, approver, and approval time; the borrowing approval module only performs updates when the current count on the voucher matches the original count.

[0109] When archival management personnel discover errors in the official version archiving, inconsistencies between document content and approved deliverables, or an incorrect version being set as the current valid version, they submit a version rollback request. The request includes the project number, design phase, specialty, document category, document number, current valid version number, current valid version update sequence number, proposed restore version number, reason for rollback, applicant, request date, and supporting record number. The processor reads the archival management permission record, verifies the scope of projects the applicant is authorized to manage and the version rollback operation, and checks whether the proposed restore version is the direct predecessor of the current valid version.

[0110] The processor reads the archived verification records, main file and attachment list, file reference relationships, design result approval records, file storage object number, file size, and content hash value of the version to be restored. If any file cannot be read, the actual file size is inconsistent, the recalculated content hash value is different, the main file and attachment reference relationships are inconsistent, the design result approval record does not exist, the version to be restored has been invalidated, or the current valid version number and update sequence number have changed, a version rollback verification failure record is generated.

[0111] After verification, the processor reads the currently valid version usage applications under review, application document records that have been approved but not yet issued certificates, temporary borrowing certificates that have not yet taken effect and those that have taken effect, unreleased usage times, online browsing records, download delivery records, and print tasks, and generates a version rollback impact record. After obtaining the version rollback approval record, it verifies the approval result, approver, approval time, current valid version number, and the version number to be restored, and then sends the rollback application, approval record, and impact record to the version management module.

[0112] After the version management module returns a successful rollback result, the processor rereads the affected borrowing applications, temporary borrowing vouchers, usage count records, and document delivery records, and distinguishes between normal version switching and error correction rollback based on the reason for the rollback. When a normal version switching occurs due to version order adjustments or normal restoration of historical versions, the update of the version before rollback is paused by the currently valid version's usage voucher; the version before rollback is maintained if the specified historical version's viewing voucher is locked, and the corresponding version file is still readable, user permissions, and validity period all meet the requirements. When an error correction rollback occurs due to archiving errors, inconsistencies between document content and design outcome approval results, or an incorrect version being set as the current valid version, the temporary borrowing voucher locking the version before rollback is updated to invalid, unstarted download and print tasks are stopped, and the corresponding usage count records not yet delivered are released; download and print tasks that have started but not yet completed are stopped from continuing delivery, and the corresponding document delivery records are updated to terminated, the usage count records for incomplete deliveries are updated to released, and records for completed deliveries are retained and written with an error correction rollback association marker; online browsing immediately stops returning new read-only display data and closes the browsing session. Temporary borrowing passes that have been suspended, replaced, or expired will not automatically become valid again upon version restoration. When the version management module returns a rollback failure result, it will not modify the current status of borrowing applications, temporary borrowing passes, usage count records, and document delivery records.

[0113] The processor generates a version rollback processing record, saving the rollback application number, approval record number, version number before rollback, restored version number, current valid version update sequence number before and after rollback, affected applications and vouchers, execution result, and completion time. When querying audit records, it reads the audit query permission record, verifies the scope of engineering projects, time range, and record types that the querying personnel are allowed to view, and saves the queryer, query conditions, query time, and number of returned records.

[0114] To verify the archiving verification module's continuous confirmation of archived files and design deliverables approval content upon receiving business change records during verification, and to verify the borrowing approval module's re-determining of the approval node's processing scope after a change in the current valid version, a business simulation environment for collaborative design of engineering projects was established. Simulation data includes engineering project deliverable catalog records, main files, attachments, deliverable submission records, design deliverable approval records, withdrawal records, invalidation records, number change records, document security classification data, source change event records, version records, document change records, borrowing application records, and borrowing approval node records. According to the data processing rules of the data access module, each initial receipt of a business record, as well as any modification, deletion, withdrawal, invalidation, document number change, document security classification change, design deliverable approval result change, or engineering project deliverable catalog record change, generates an independent business record or source change event record. Within the same engineering project number range, new source record serial numbers are assigned according to the order of successful receipt; already assigned source record serial numbers are not modified, thus ensuring consistency between the business change record generation method in the simulation and the actual source record serial number generation method used by the data access module.

[0115] In the archiving verification simulation, one hundred business records associated with the current archiving object are pre-generated for each task to be archived. A series of disturbance levels are set based on the proportion of newly added business records and source change event records during the verification period to these one hundred initial associated records. Each level independently executes ten thousand simulations. Disturbance records are generated using stratified random sampling. First, it is ensured that file re-uploads, changes in design outcome approval results, file withdrawals, file invalidations, changes in file numbers, changes in file security levels, and changes in project outcome catalog records all enter the sample of the corresponding level. Then, affected files and business records are randomly selected within each disturbance type. All random sampling uses a fixed random seed to ensure that the same set of disturbance records can be obtained again under the same input conditions. Each simulation first generates the file records to be archived and starts the archiving verification. During the archiving verification execution, a corresponding number of disturbance records are inserted, and each disturbance record generates a new source record sequence number.

[0116] After all disturbances are completed, a full replay method, independent of the re-triggered processing during the verification period, is used to generate a reference archive result. Specifically, starting from the set of business records saved at the beginning of the project simulation, all subsequent business records and source change event records are applied sequentially according to the source record number. The current archive verification record and its re-verification result are not read. The main file, attachments, file storage object number, file content hash value, file security level, file reference relationships, and design result approval results after the disturbance are re-determined. The archive verification record finally generated by the archive verification module is compared item by item with this reference archive result. If all corresponding fields are consistent, it is recorded as a consistent archive verification result. In each disturbance level, the number of simulation tasks with consistent archive verification results is divided by the total number of 10,000 simulation tasks in that level to obtain the result. Figure 5 Consistency rate of archived verification results.

[0117] Figure 5 Record the processing results separately for cases where the verification start number and end number are not compared, and for cases where the verification start number and end number are compared and new business records and source change event records are read during the period for re-verification when the numbers change. Figure 5 It is evident that as the proportion of newly added records gradually increased from zero during the verification period, the consistency rate of the archived verification results after adding source record number comparison and re-verification remained between 97.47% and 99.69%. Without source record number comparison and re-verification, as the number of records showing business changes increased during the verification period, the consistency rate of the archived verification results decreased from 99.13% to 67.69%. This result indicates that when documents, deliverable catalogs, document security levels, or design deliverable approval data change during the verification process, determining the newly added records based on the verification start and end numbers and re-verifying them ensures that the final archived verification records continue to correspond to the actual documents and approval status after the disturbance ends.

[0118] In the borrowing approval simulation, each borrowing application has a fixed set of required approval nodes. These nodes have sequential, parallel, and combined processing relationships, as well as relationships formed after multiple preceding approval nodes converge. Each approval node is configured with the file number, file content hash value, file security level, or file reference relationship to be checked, resulting in a fixed number of approval check fields for each borrowing application. Continuous perturbation levels are set according to the proportion of changed approval check fields to all approval check fields, with each level independently executing 10,000 borrowing approval simulations. A stratified random sampling method is used to select changed fields from file number, file content hash value, file security level, and file reference relationship, and then the actual changed objects are determined from the files associated with the approval nodes checking the corresponding fields. The same random seed is used to repeatedly generate version change records for the corresponding level, ensuring that both approval processing methods use identical input samples.

[0119] Figure 6 The reference approval result is not directly generated from the "reprocessing of changed fields and dependent nodes" result to be verified, but is formed by an independent full-scale approval verification process. For each borrowing application with version changes, the independent verification process does not read the set of affected approval nodes already determined by the borrowing approval module, but directly reads the new current effective version, the borrowing approval configuration, the checked fields of all necessary approval nodes, and the relationships of the preceding approval nodes. Starting from the starting node of the approval process, all checks are re-executed node by node until all necessary approval nodes are processed. This yields the processing status that each approval node should have under the new current effective version, which serves as the reference approval node status. The processing to be verified then determines the approval nodes that check the changed fields based on the file change record, and determines its direct and indirect dependent nodes level by level according to the reverse lookup relationship of the preceding approval node numbers. The corresponding nodes are reprocessed, while the completed approval results that have not checked the changed fields and do not depend on the affected nodes are retained.

[0120] The final status of each approval node formed during the verification process is compared item by item with the reference approval node status formed by independent full-scale approval verification. The number of borrowing applications with consistent node status is divided by the total number of borrowing applications in that tier to obtain the approval result consistency rate. The approval result retention rate is summarized and statistically analyzed according to the number of nodes. Completed approval nodes that have been confirmed by independent full-scale approval verification as not needing to be reprocessed due to this version change are used as reference retention nodes. The number of nodes that actually retain approval results during the verification process is counted, and the approval result retention rate is obtained by dividing the total number of actually retained nodes in that tier by the total number of reference retention nodes in that tier. When a single borrowing application has no reference retention nodes, the retention ratio of that application is not calculated separately, and its node count is not included in the denominator of the retention rate. If a complete disturbance tier has no reference retention nodes, the approval result retention rate of that tier is recorded as having no statistically significant retention nodes, and is not replaced by a zero value.

[0121] Figure 6 Record the consistency rate and retention rate of approval results for two processing methods: reprocessing based on changed fields and dependent nodes, and reprocessing all approval nodes. Figure 6As can be seen, when reprocessing based on changed fields and dependent nodes, the consistency rate of approval results ranges from 98.49% to 99.72%. This indicates that after identifying affected approval nodes based on changed fields and tracing back along the relationships of preceding approval nodes to find direct and indirect dependent nodes, the final approval status can maintain a correspondence with the independent full-scale approval verification results. The approval result retention rate gradually decreases from 100% to 18.83% as the range of fields changes with the version expands, reflecting that the number of unaffected approval results that can actually continue to be used decreases as the range of version changes expands. When all approval nodes are reprocessed, the consistency rate of approval results ranges from 99.48% to 99.92%, but the approval result retention rate is zero. Therefore, the borrowing approval module, while maintaining the correspondence between approval results and the new currently valid version, can retain approval results unaffected by the current version change based on the actual changed fields and approval node dependencies, avoiding the need to reprocess unaffected approval nodes as well.

[0122] In summary, this invention uses an archiving verification module to check the main file, attachments, deliverables directory, file reference relationships, and design deliverables approval records. It calculates the hash value of the file content and compares the source record serial numbers before and after verification, thereby achieving continuous confirmation of the archived content and approval basis, forming an archiving verification record, and achieving the effect of the archived version corresponding to the approved deliverables. The borrowing approval module compares the content hash value, file security level, and attachment reference relationships of the application version with the current valid version, reprocesses the approval nodes and their dependent nodes that check the changed fields, and retains the unaffected approval results, achieving the effect of adjusting the borrowing approval results according to version changes.

[0123] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A version archiving and access control system for collaborative design of engineering projects, characterized in that, include: The data access module acquires data on engineering projects, deliverables catalogs, document submissions, design deliverables approvals, withdrawals, invalidations, number changes, and document security classifications; determines document ownership; and generates records of documents to be archived, document reference relationships, and source record serial numbers. The archiving verification module verifies the main file, attachments, deliverables directory, file reference relationships, and design deliverables approval records. It calculates the hash value of the file content and generates an archiving verification record when the source record serial number is consistent before and after verification. When the serial number changes, it re-verifies based on the newly added record. The version management module compares the archived files with the current valid version in terms of file list, content hash value, file security level, and attachment reference relationship. When data changes, it generates a new version and file change record, and updates the current valid version and the current valid version update sequence number. The borrowing approval module processes borrowing applications based on project member relationships, file access permissions, file security level, and borrowing approval configuration. When the version changes during the approval process, the approval node and its dependent nodes that check the changed fields are reprocessed and checked. After the approval is passed, a temporary borrowing certificate is generated that locks the approved version and the file storage object. The access control module verifies the user, credentials, approved version, current valid version update number, allowed operations, validity period, and number of uses. It performs browsing, downloading, or printing based on the file storage object locked by the credentials. The number of uses is reserved before delivery, and the reservation is confirmed after delivery. If delivery fails, the reservation is released. The audit rollback module links and saves archives, versions, borrowing approvals, vouchers, and document delivery records. It verifies the version rollback application with the hash values ​​of the documents, approvals, and content of the previous historical version, and updates the affected vouchers and access records based on the rollback results.

2. The version archiving and access control system for collaborative design of engineering projects as described in claim 1, characterized in that, The acquisition of project data, deliverables catalogs, document submissions, design deliverables approvals, withdrawals, invalidations, number changes, and document security classification data includes: After receiving records sent by external business systems, the data access module retrieves the received records according to the source system number, source record number, and data type. If the business fields are the same, they are not written repeatedly. If the business fields are different, the modified field, the value before modification, the value after modification, and the modification time are saved. Source record numbers are assigned sequentially in ascending order of successful record reception. Once a source record number is written, it is not modified. The maximum source record number of the corresponding file is updated after each new record is added.

3. The version archiving and access control system for collaborative design of engineering projects as described in claim 2, characterized in that, The process of determining file ownership and generating records of files to be archived, file reference relationships, and source record numbers includes: The data access module determines the file ownership according to the project number, design stage, specialty, document category, and document number, and determines the main file and attachments of the same submission based on the file upload records referenced in the deliverables submission record or design deliverables approval record; When the same file number is uploaded multiple times, the corresponding result submission record and file upload record are read in reverse from the design result approval record with the approval result being approved. Uploaded files that are not referenced by the new approval record will not use the original approval result, and a file record to be archived will be generated when the file upload status is completed, the file storage object number exists, and the file size is greater than zero.

4. The version archiving and access control system for collaborative design of engineering projects as described in claim 3, characterized in that, The process of verifying the main file, attachments, deliverables directory, file citation relationships, and design deliverables approval records, and calculating the hash value of the file content, includes: When a file record to be archived is in a pending verification state, the archiving verification module updates the record to "under verification", reads the project deliverables catalog items and their catalog record version numbers, and saves the maximum source record sequence number at the start of verification. Read all bytes of data from the main file and attachments based on the file storage object number, compare the actual number of bytes read with the file size, and use a secure hash algorithm (256 bits) to calculate the hash value of the main file and each attachment.

5. The version archiving and access control system for collaborative design of engineering projects as described in claim 4, characterized in that, The process of generating archived verification records when the source record serial numbers are consistent before and after verification, and re-verifying based on newly added records when the serial numbers change, includes: The archiving verification module compares the set of files required by the deliverables catalog, the set of files referenced in the deliverables submission records, and the set of files referenced by each design deliverables approval node item by item, and verifies the approval process number, node order, prior approval node, approval result, file upload record number, and content hash value of each required design deliverables approval node; After verification, the maximum source record number is read again. If the serial numbers before and after verification are consistent, an archived verification record is generated. If the serial numbers are inconsistent, the newly added file upload, approval, withdrawal, invalidation, number change or result catalog change records between the two serial numbers are read and re-verified.

6. The version archiving and access control system for collaborative design of engineering projects as described in claim 5, characterized in that, The comparison of the archived files with the current valid version includes the following: file list, content hash value, file security level, and attachment reference relationships. The version management module compares the file list in the archived verification record with the current valid version item by item. If the file number, number of files, content hash value, file security level and attachment reference relationship are all the same, a duplicate commit record is generated. When there are changes such as adding files, modifying content, deleting files, changing file numbers, changing file security levels, or changing attachment references, a corresponding file change record is generated for each specific file.

7. The version archiving and access control system for collaborative design of engineering projects as described in claim 6, characterized in that, The updated current version and the current version update sequence number include: The version management module reads the historical maximum version sequence number, generates an incrementing new version sequence number, saves the new version and file change records within the same database transaction, updates the original currently valid version to the historical version, updates the new version to the currently valid version, and increments the current valid version update sequence number. Before submitting the transaction, the version number of the project deliverables catalog, the current processing record number of the design deliverables approval node, and the source record number are re-compared. If any data changes, the current version writing is cancelled and the process is returned to the archiving and verification module for reprocessing.

8. The version archiving and access control system for collaborative design of engineering projects as described in claim 7, characterized in that, When the version changes during the approval process, the approval node and its dependent nodes that check the changed fields are reprocessed. After approval, a temporary borrowing certificate is generated to lock the approved version and the file storage object, including: When a borrowing application enters the approval process, the borrowing approval module saves the file number of the application version, the content hash value, the file security level, the attachment reference relationship, and the current valid version update number of the application version. When a change in the current valid version update sequence number is detected during the approval process, the corresponding fields of the application version and the current valid version are compared. The approval nodes with the changed fields and all direct or indirect dependent nodes determined along the relationship with the preceding nodes are updated to be reprocessed. Approval results that have not checked the changed fields and do not depend on the affected nodes are retained. Once all necessary approval steps are passed, a temporary borrowing certificate is generated, locking the application document record number, approval version number, and document storage object number.

9. The version archiving and access control system for collaborative design of engineering projects as described in claim 8, characterized in that, The process of verifying the user, credentials, approved version, current valid version update number, allowed operations, validity period, and number of uses, and performing browsing, downloading, or printing according to the file storage object locked by the credentials, occupies the number of uses before delivery, confirms the occupancy after delivery, and releases the occupancy in case of delivery failure, includes: The access control module verifies the logged-in user, credential signature, credential status, validity period, allowed operations, approved version number, current valid version update sequence number at the time of issuance, and file storage object number based on the temporary borrowing credential. The current valid version access request compares the current valid version number and the current valid version update sequence number at the time of access, and the specified historical version access request verifies the approved version status and the readable status of the file storage object. Once a download or print request is verified, a usage count record is generated within the same database transaction. Upon successful delivery, the usage count is updated to "confirmed." If delivery fails, is canceled, or the release period expires, the usage count is updated to "released." 10. The version archiving and access control system for collaborative design of engineering projects as described in claim 9, characterized in that, The associated storage includes archives, versions, borrowing approvals, vouchers, and document delivery records. It verifies version rollback requests and the hash values ​​of documents, approvals, and content from the previous historical version. Based on the rollback results, it updates affected vouchers and access records, including: Audit records are appended and saved in the order in which business records are received. The hash value of the content of the previous audit record and the business field of the current audit record are continuously input into a secure hash algorithm to generate the hash value of the content of the current audit record. Upon receiving a version rollback request, the system verifies the applicant's file management permissions, the current valid version number, and the current valid version update sequence number. It also reads the archive verification record, main file, attachments, file reference relationships, design result approval record, and content hash value of the previous historical version to determine the affected borrowing applications, temporary borrowing vouchers, usage records, and document delivery records. After a successful version rollback, the current valid version of the previous version will be locked and the update of the certificate will be suspended. For the certificate to be viewed for a specified historical version, the original state will be maintained as long as the approved version file is readable and the permissions and validity period meet the requirements. Certificates that have been suspended, replaced or expired will not be restored to the effective state.

Images