A method and device for hierarchical control of permissions of an online bidding and tendering review system

Abstract

The application relates to the technical field of online bidding and tender evaluation systems, and discloses a permission hierarchical control method and device for an online bidding and tender evaluation system, which comprises the following steps: obtaining a bidding file evaluation request sent by an expert terminal, and analyzing to obtain an evaluation role, an operation type and a resource path; performing permission mapping on a preset evaluation permission table according to the evaluation role, the operation type and the resource path, obtaining a locking level, a resource granularity and a locking mode; when the locking mode is exclusive writing, performing resource conflict identification on a current lock table to obtain a conflict result, and generating a node lock when the conflict result is no conflict; during the validity period of the node lock, performing writing control on a synchronous writing request to obtain a writing control result; and obtaining a permission hierarchical control result of the bidding file according to the node lock and the writing control result. The method can realize hierarchical locking of a target resource node of a bidding file and orderly control of synchronous writing.

Description

Technical Field

[0001] This invention relates to the technical field of online bidding review systems, and in particular to a method and apparatus for hierarchical access control in online bidding review systems. Background Technology

[0002] Currently, online bidding review systems are gradually shifting from a single-person sequential review method to a multi-expert concurrent collaborative review method. Chapters, tables, scoring items, and annotations in bid documents typically need to be read, filled in, or modified simultaneously by multiple review terminals. To ensure data consistency during the review process, the system usually needs to implement read / write controls for different review roles, different operation types, and different file nodes.

[0003] In a current technology, the system typically configures fixed read / write ranges for expert accounts based on their roles before the review task begins, and handles file editing using either full file locking or simple queuing. While this approach is suitable for typical sequential editing scenarios, it becomes problematic when multiple experts are simultaneously working on the same tender document. Full file locking can lead to unrelated sections being restricted along with the rest, while simple queuing struggles to differentiate between different operation types such as critical annotations, score modifications, and general browsing. Furthermore, when a senior reviewer is critically writing to a specific score item or section, other reviewers may still initiate synchronous write requests to the same resource nodes. If the system only uses a fixed role table for access control, or only determines whether the entire file is in an editing state, it struggles to accurately identify overlapping resource paths and to process synchronous write requests of different levels in an orderly manner during the locking period. Consequently, issues such as content overwriting, disordered waiting sequences, or delayed re-entry requests after the lock is released may arise.

[0004] Existing technologies have the problem that the write status of target resource nodes in tender documents is difficult to manage in an orderly manner according to the review level when multiple experts conduct concurrent reviews. Summary of the Invention

[0005] This invention provides a hierarchical access control method and apparatus for an online bidding review system, in order to solve the problem in the prior art that the write status of target resource nodes in bid documents is difficult to manage in an orderly manner according to the review level when multiple experts conduct concurrent reviews.

[0006] Firstly, in order to solve the above-mentioned technical problems, the present invention provides a hierarchical access control method for an online bidding review system, comprising:

[0007] Obtain the tender document review request sent by the expert terminal, parse the tender document review request, and obtain the review role, operation type, and resource path; Based on the review role, the operation type, and the resource path, a preset review permission table is mapped to obtain the lock level, resource granularity, and lock method. When the locking method is exclusive write, resource conflict identification is performed on the current lock table according to the resource path and the resource granularity to obtain the conflict result, and a node lock is generated when the conflict result is no conflict. During the period when the node lock is valid, the synchronous write request pointing to the resource path is subjected to level verification to obtain the write verification result, and the synchronous write request is controlled according to the write verification result and the node lock to obtain the write control result. The node lock is released and verified to obtain a release result. The lock state of the node lock is updated according to the release result. The write access verification is performed on the waiting request in the write control result to obtain the permission hierarchical control result of the tender document.

[0008] Secondly, the present invention provides a permission hierarchical control device for an online bidding review system, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0009] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention obtains the bid document review request sent by the expert terminal, parses it to obtain the review role, operation type, and resource path, and maps the preset review permission table according to the review role, operation type, and resource path to obtain the locking level, resource granularity, and locking method. Therefore, the system no longer relies solely on fixed role permissions or the entire file editing status for judgment, but incorporates the reviewer level, actual operation content, and bid document node position into the permission determination process, enabling write permissions in different review scenarios to correspond to specific resource nodes. Ultimately, this achieves hierarchical identification of bid document review operations, providing clear data basis for subsequent node locking and synchronous write control.

[0010] (2) This invention identifies resource conflicts in the current lock table based on resource path and resource granularity when the locking mode is exclusive write, and generates a node lock when the conflict result is no conflict. Therefore, the system can lock target resource nodes such as chapters, tables, or scoring items without restricting the entire tender document, avoiding unrelated resource nodes being affected by the same locking state. Simultaneously, by identifying conflict relationships between resource paths through the current lock table, it can confirm whether the target resource node has already been occupied before synchronous write occurs. Ultimately, this achieves fine-grained exclusive write control of target resource nodes in the tender document, reducing the risk of content overwrite during concurrent review.

[0011] (3) This invention performs level verification on synchronous write requests pointing to resource paths during the node lock's validity period, and controls the write requests based on the write verification results and the node lock, obtaining a write control result. After the node lock is released, the lock state of the node lock is updated based on the release result, and write admission verification is performed on the waiting requests in the write control result. Thus, the system can distinguish between different situations such as low-level writes, same-level or high-level waiting, and lock-holding session re-entry during the locking period, and re-admission judgment is performed on the waiting requests after the lock is released. Ultimately, it achieves the orderly connection of synchronous write requests in multi-expert concurrent review, improving the continuity of permission control and data consistency in the bid document review process. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the permission hierarchical control method for an online bidding review system provided in the first embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] Reference Figure 1 The first embodiment of the present invention provides a hierarchical access control method for an online bidding review system, comprising the following steps: S1, Obtain the tender document review request sent by the expert terminal, parse the tender document review request to obtain the review role, operation type and resource path; S2, based on the review role, the operation type, and the resource path, perform permission mapping on the preset review permission table to obtain the lock level, resource granularity, and lock method; S3, when the locking method is exclusive write, resource conflict identification is performed on the current lock table according to the resource path and the resource granularity to obtain the conflict result, and a node lock is generated when the conflict result is no conflict. S4, during the period when the node lock is valid, the synchronous write request pointing to the resource path is subjected to level verification to obtain the write verification result, and the synchronous write request is controlled according to the write verification result and the node lock to obtain the write control result. S5, perform release verification based on the node lock to obtain the release result, update the lock state of the node lock based on the release result, perform write access verification on the waiting request in the write control result, and obtain the permission hierarchical control result of the tender document.

[0015] In step S1, the bid document review request sent by the expert terminal is obtained, and the bid document review request is parsed to obtain the review role, operation type, and resource path, including: Read the session field, file field, node field, and operation field from the tender document review request; The review role is obtained by querying the login session table based on the session fields. The operation type is identified based on the operation field; Based on the file field, the node field, and the preset node directory table, at least one of the following is determined: file identifier, chapter identifier, table identifier, and rating item identifier. A resource path is generated based on at least one of the following: file identifier, chapter identifier, table identifier, and rating item identifier.

[0016] After receiving a bid review request from an expert terminal, this embodiment reads the session field, file field, node field, and operation field according to the structured message format of the bid review request. The session field is the session number written by the server after the expert terminal successfully logs in; the file field is the file number of the bid document in the review system; the node field is the node number of the accessed node within the bid document; and the operation field is the enumeration value of the review actions submitted by the expert terminal. After reading, this embodiment writes the session field, file field, node field, and operation field into the request parsing cache.

[0017] It should be noted that the login session table is established by the review system when an expert successfully logs in to the expert terminal. The login session table includes at least the session number, expert number, review role, session status, connection identifier, heartbeat update time, and session expiration time. The connection identifier is generated when the expert terminal establishes a WebSocket long connection with the server and is written into the login session table. The heartbeat update time is determined by the time the server last received the expert terminal's WebSocket heartbeat confirmation message. When the server receives the WebSocket heartbeat confirmation message, it writes the session status as valid and updates the heartbeat update time according to the arrival time of the WebSocket heartbeat confirmation message, and updates the session expiration time according to the updated heartbeat update time. When the server receives a WebSocket close event or a WebSocket abnormal disconnection event, it writes the session status as invalid and writes the session expiration time as the time the corresponding event arrived at the server. The lock expiration time of the node lock is directly taken from the session expiration time in the login session table; no separate node lock release threshold is set.

[0018] It should be noted that the WebSocket heartbeat confirmation message is sent from the expert terminal to the server according to a preset period. This preset period is sent to the expert terminal by the review system via a connection handshake message when establishing a WebSocket long connection. Each time the server receives the WebSocket heartbeat confirmation message, it updates the session expiration time to the current server time plus a preset multiple of the preset period. This preset multiple is set in the review system deployment configuration. Therefore, the lock expiration time of the node lock is indirectly determined by the existing preset period and preset multiple between the expert terminal and the server. This embodiment does not set a separate independent node lock timeout parameter.

[0019] In this embodiment, the login session table is searched for records with the same session number, valid session status, and session expiration time later than the current server time, based on the session field. The review role is then retrieved from these records. If no record with the same session number, valid session status, and expiration time later than the current server time exists in the login session table, this embodiment marks the tender document review request as invalid and stops the resource path generation process for that request.

[0020] It should be noted that the operation fields use fixed enumeration values ​​to represent review actions. These fixed enumeration values ​​include read, annotation write, score write, and review content modification. Review content modification refers to modifying the structured review data generated during the review process. This structured review data includes individual expert review data and shared review data; the original tender document, as a read-only file, does not enter the write control process. In this embodiment, after reading the operation field, the corresponding enumeration value is converted into a Chinese action item with the same name, and this Chinese action item is determined as the operation type. The operation type is directly derived from the business action field submitted by the expert terminal and is not inferred based on page dwell time, click location, or operation frequency.

[0021] It is worth noting that the preset node directory table is established by the review system when the bid documents enter the online review system. In establishing the preset node directory table, this embodiment performs structured parsing of the bid documents, generating directory records according to a four-level structure of documents, chapters, tables, and scoring items. Each directory record contains at least a document identifier, chapter identifier, table identifier, scoring item identifier, resource ownership identifier, and node number. The document identifier is determined by the document field; the chapter identifier is determined by the parsing result of the bid document's chapter directory; the table identifier is determined by the table number identified in the structured format of the bid document; and the resource ownership identifier is used to distinguish between individual expert review data and shared review data. For individual expert review data, the scoring item identifier is generated by combining the scoring item number in the review form and the expert identifier; for shared review data, the scoring item identifier is generated by combining the scoring item number in the review form and the sharing identifier. The scoring item identifier is unique within the same bid document, and the node number is consistent with the node field.

[0022] In this embodiment, the preset node directory table is queried based on the file field and the node field to determine at least one of the following: file identifier, chapter identifier, table identifier, and scoring item identifier. If the node field corresponds to the entire tender document, the file identifier is read; if the node field corresponds to a chapter, the file identifier and chapter identifier are read; if the node field corresponds to a table, the file identifier, chapter identifier, and table identifier are read; if the node field corresponds to a scoring item, the file identifier, chapter identifier, table identifier, and scoring item identifier are read.

[0023] This embodiment generates a resource path based on at least one of the file identifier, chapter identifier, table identifier, and scoring item identifier. The resource path is represented by a hierarchical string, which is concatenated in the order of file identifier, chapter identifier, table identifier, and scoring item identifier, with adjacent levels separated by forward slashes. If a level identifier is missing, the resource path terminates at the corresponding level without adding an empty field. After the resource path is generated, this embodiment uses the review role, the operation type, and the resource path as the output of step S1.

[0024] In step S2, based on the review role, the operation type, and the resource path, a preset review permission table is mapped to obtain the lock level, resource granularity, and lock method, including: Extract resource granularity identifiers based on the resource path; The review role, the operation type, and the resource granularity identifier are combined into a permission query item; Search the preset review permission table for the permission record corresponding to the permission query item; Read the level field, granularity field, and method field from the permission record to obtain the lock level, resource granularity, and lock method.

[0025] In one implementation, the preset review permission table is generated jointly by review task configuration data and a structured directory of tender documents. The review task configuration data includes the expert accounts participating in the review, the review roles corresponding to the expert accounts, and the review role sequence codes. The structured directory of tender documents includes file identifiers, chapter identifiers, table identifiers, and scoring item identifiers. When generating the preset review permission table, the review roles, operation types, and resource granularity identifiers are combined to form multiple permission records, and then a level field, a granularity field, and a method field are written to each permission record.

[0026] It should be noted that the review role sequence code is directly converted from the role type in the review task configuration data. The review roles include review expert, review expert, and lead review expert. The review role sequence code for a review expert is number one, for a review expert it is number two, and for a lead review expert it is number three. These codes are set in ascending order according to the review hierarchy in the review process, with each review role within the same review task corresponding to a fixed code.

[0027] It should be noted that the operation type has an operation write attribute. The operation write attribute is determined by the scope of changes the operation type makes to the bid document data. Reading without changing review data corresponds to an operation write attribute of zero; writing comments changes comment data, corresponding to an operation write attribute of one; writing scores changes the score field, corresponding to an operation write attribute of two; modifying review content changes the structured review data generated during the review process, corresponding to an operation write attribute of three. The operation write attribute is directly converted from the fixed enumeration values ​​of the operation field; the original bid document is not used as the writing object for the operation write attribute.

[0028] This embodiment generates a grade field based on the review role sequence code and the operation write attribute. The generation process involves first reading the maximum value of all operation write attributes in the current review task, then adding one to the maximum value to obtain the grade carry-over base; subsequently, multiplying the value obtained by subtracting one from the review role sequence code by the grade carry-over base, and adding the operation write attribute to obtain the grade field. The grade carry-over base is determined by the set of operation write attributes for the current review task and is not manually set. Since the maximum value of the operation write attribute is three, and the grade carry-over base is four, when the lead reviewer performs a score write, the review role sequence code is three, the operation write attribute is two, and the grade field is ten. When the review expert performs a content modification, the review role sequence code is two, the operation write attribute is three, and the grade field is seven. Thus, the grade field has a definite numerical source and can be directly compared by the server. The grade field is used to determine the sorting position of the priority waiting record in the waiting queue in the synchronous write request, and to determine the grade comparison result in the write verification result. The value of the locking level does not change the inherent review hierarchy permission relationship between the review roles. That is, a reviewer with a lower review role level cannot interrupt a reviewer with a higher review role level from making an exclusive write request for any resource while the node lock is in a valid state.

[0029] It should be noted that the locking method is determined by the "method" field in the review permission table, which is written according to the operation type when the review permission table is generated. Reading corresponds to a non-write method, comment writing corresponds to a normal write method, and rating writing and review content modification correspond to an exclusive write method. The resource granularity identifier is used to determine the locking scope. If the resource granularity identifier is at the rating item level, the resource granularity record is at the rating item level; if the resource granularity identifier is at the table level, the resource granularity record is at the table level; if the resource granularity identifier is at the chapter level, the resource granularity record is at the chapter level; if the resource granularity identifier is at the file level, the resource granularity record is at the file level. The granularity field is directly derived from the hierarchical structure of the resource path and is not obtained through behavior inference.

[0030] This embodiment extracts resource granularity identifiers based on the resource path. Specifically, when the resource path contains only a file identifier, the resource granularity identifier is determined to be at the file level; when the resource path contains both a file identifier and a chapter identifier, the resource granularity identifier is determined to be at the chapter level; when the resource path contains a file identifier, a chapter identifier, and a table identifier, the resource granularity identifier is determined to be at the table level; and when the resource path contains a file identifier, a chapter identifier, a table identifier, and a rating item identifier, the resource granularity identifier is determined to be at the rating item level.

[0031] In this embodiment, the review role, operation type, and resource granularity identifier are combined into a permission query item. The permission query item uses a three-part key-value representation: the first part is the review role, the second part is the operation type, and the third part is the resource granularity identifier. After generating the permission query item, a permission record with identical review role, operation type, and resource granularity identifier fields is searched in the preset review permission table. Upon finding the permission record, the level, granularity, and method fields are read from the permission record. The level field is determined as the lock level, the granularity field as the resource granularity, and the method field as the lock method.

[0032] It is worth noting that when there is no corresponding permission record in the preset review permission table for the permission query item, this embodiment determines the locking method to be non-write and marks the bid document review request as a permission miss request. The permission miss request does not enter the subsequent exclusive write locking process. The server generates a permission miss response based on the permission miss request and sends the permission miss response to the expert terminal that initiated the bid document review request, while simultaneously writing the permission miss request to the permission exception log. This process is executed only based on whether a matching record exists in the preset review permission table, without introducing an additional judgment model.

[0033] In step S3, when the locking method is exclusive write, resource conflict identification is performed on the current lock table according to the resource path and the resource granularity to obtain the conflict result, and a node lock is generated when the conflict result is no conflict.

[0034] Specifically, resource conflict identification is performed on the current lock table based on the resource path and the resource granularity to obtain conflict results, including: The resource path is normalized according to the resource granularity to obtain the target lock path; Read the lock records with valid states from the current lock table to obtain the set of valid locks; The target lock path is compared with the locked paths in the set of valid locks to determine the conflict result.

[0035] In one implementation, the current lock table is a lock status data table maintained by the review system server. The current lock table includes at least the lock identifier, target lock path, resource path, resource granularity, locking level, lock holding session, lock status, creation time, heartbeat update time, and lock expiration time. The lock status includes valid and invalid states. The lock record is a data record in the current lock table. The locked path is the resource path recorded in the lock records with valid states. The valid lock set is a data set formed by all valid lock records read from the current lock table whose lock expiration time is later than the current server time. If there are no valid lock records with lock expiration times later than the current server time in the current lock table, then the valid lock set is an empty set.

[0036] It should be noted that the heartbeat update time is determined by the time when the most recent WebSocket heartbeat confirmation message from the expert terminal corresponding to the lock-holding session arrives at the server. The lock expiration time is taken from the session expiration time of the lock-holding session in the login session table. When the server receives the WebSocket heartbeat confirmation message corresponding to the lock-holding session, it synchronously updates the heartbeat update time and session expiration time in the login session table, and writes the updated session expiration time into the lock expiration time of the corresponding node lock in the current lock table. When the server reads the set of valid locks, it does not write lock records with expiration times earlier than or equal to the current server time into the set of valid locks, but instead updates the lock status of the aforementioned lock records to an invalid state.

[0037] It should be noted that path normalization converts the resource path into a hierarchical path consistent with the resource granularity. If the resource granularity is file-level, the file identifier in the resource path is retained, while the chapter identifier, table identifier, and rating item identifier are deleted; if the resource granularity is chapter-level, the file identifier and chapter identifier in the resource path are retained, while the table identifier and rating item identifier are deleted; if the resource granularity is table-level, the file identifier, chapter identifier, and table identifier in the resource path are retained, while the rating item identifier is deleted; if the resource granularity is rating item-level, the file identifier, chapter identifier, table identifier, and rating item identifier in the resource path are retained. The path obtained after path normalization is determined as the target lock path.

[0038] In this embodiment, the resource path is normalized according to the resource granularity. After obtaining the target lock path, lock records with valid lock status and lock expiration times later than the current server time are selected from the current lock table and written into the valid lock set. Subsequently, the lock records in the valid lock set are read one by one, and locked paths are extracted from the lock records. Path conflict is determined between the target lock path and the locked paths. If any locked path conflicts with the target lock path, the corresponding conflict result is directly output; if none of the locked paths conflict with the target lock path, no conflict is output.

[0039] Specifically, the process involves determining a path conflict between the target lock path and the locked paths in the valid lock set to obtain a conflict result, including: When the target lock path is the same as any locked path in the set of valid locks, the conflict result is determined to be a same path conflict; When the target lock path contains the locked path or the locked path contains the target lock path, the conflict result is determined to be a hierarchical path conflict; When both the target lock path and the locked path contain a file identifier and a rating item identifier, and the file identifier in the target lock path is the same as the file identifier in the locked path, and the rating item identifier in the target lock path is the same as the rating item identifier in the locked path, the conflict result is determined to be a rating item conflict. When the target lock path and the locked path do not satisfy the same path conflict, hierarchical path conflict, and scoring item conflict, the conflict result is determined to be no conflict.

[0040] In one implementation, path conflicts are determined by string matching. If all level identifiers of the target locked path and all level identifiers of the locked path are identical segment by segment, this embodiment determines the conflict result as a path conflict. Segment-by-segment identical means that the file identifier, chapter identifier, table identifier, and rating item identifier have the same value at the same level, and the number of levels is the same.

[0041] It should be noted that hierarchical path conflicts are determined through parent-child hierarchy inclusion. If the preceding level of the target lock path is the same as all levels of the locked path, and the number of levels in the target lock path is greater than the number of levels in the locked path, then the locked path is the parent path of the target lock path, and in this embodiment, the conflict result is determined as a hierarchical path conflict. If the preceding level of the locked path is the same as all levels of the target lock path, and the number of levels in the locked path is greater than the number of levels in the target lock path, then the target lock path is the parent path of the locked path, and in this embodiment, the conflict result is determined as a hierarchical path conflict.

[0042] It should be noted that scoring item conflicts are determined through scoring item identifiers. These identifiers originate from the preset node directory table in step S1 and are directly written into the resource path. Each scoring item identifier is unique within the same tender document. This embodiment does not infer the scoring item relationship from two arbitrary strings; instead, it reads the scoring item identifiers already existing in the target lock path and the locked path. If both the target lock path and the locked path contain the same file identifier and the same scoring item identifier, then this embodiment determines the conflict result as a scoring item conflict.

[0043] It is worth noting that when the target lock path and a locked path simultaneously satisfy multiple conflict conditions, this embodiment determines the conflict result in the order of identical path conflict, hierarchical path conflict, and scoring item conflict. This order is determined by the scope of the path relationship: identical path conflict indicates complete overlap, hierarchical path conflict indicates overlap of upper and lower level resources, and scoring item conflict indicates overlap of the same scoring item. If the target lock path and all locked paths in the valid lock set do not satisfy the above three conflict conditions, then this embodiment determines the conflict result as conflict-free.

[0044] The process of generating a node lock when the conflict result is conflict-free includes: When the conflict result is no conflict, the current session is extracted according to the tender document review request to obtain the lock holding session; The target lock path, the resource path, the resource granularity, the locking level, the lock holding session, and the lock validity status obtained after normalizing the resource path according to the resource granularity are written into the current lock table to obtain the node lock; An access status notification is generated based on the node lock, and the access status notification is sent to the expert terminal accessing the resource path.

[0045] In one implementation, the current session is the session number corresponding to the session field in the tender document review request. In this embodiment, when the conflict result is no conflict, the session field is read from the tender document review request, and the session number corresponding to the session field is determined as the lock-holding session. The lock-holding session represents the expert terminal login session to which the current node's lock belongs.

[0046] This embodiment writes the target lock path, the resource path, the resource granularity, the locking level, the lock holding session, and the lock validity status into the current lock table to obtain a node lock. The target lock path is used as the locked path read during subsequent resource conflict identification, and the resource path is retained in the current lock table as the request path corresponding to the node lock. The lock validity status is a lock status field assigned to the node lock when written to the current lock table, and the value of the lock status field is valid. When writing to the current lock table, the server re-executes resource conflict identification within the same database transaction. If the conflict result obtained from re-executing resource conflict identification is no conflict, the database transaction is committed, and a node lock is generated; if the conflict result obtained from re-executing resource conflict identification is not no conflict, the database transaction is rolled back, and the corresponding conflict result is output. This writing process ensures that the target lock path forms only one valid node lock at any given time.

[0047] It should be noted that the node lock also includes a heartbeat update time and a lock expiration time. The heartbeat update time is written to the current server time when the node lock is generated. The lock expiration time is taken from the session expiration time of the lock-holding session in the login session table. When the server receives a WebSocket close event or a WebSocket abnormal disconnection event corresponding to the lock-holding session, it updates the connection status of the record corresponding to the lock-holding session in the online session table to offline status, stops receiving new reentrancy write requests for the node lock from the lock-holding session, and writes the lock expiration time of the node lock to the current server time, so that the node lock is immediately updated to an invalid state when the valid lock set is read subsequently.

[0048] It should be noted that the access status notification is a structured notification message generated based on the node lock. The access status notification includes at least the resource path, resource granularity, locking level, lock status, lock holding session, and lock expiration time. In this embodiment, the online session table is used to query the expert terminals that are currently accessing the resource path and whose connection status is online, and the connection identifier corresponding to the expert terminal is read. The online session table is updated by the review system server when the expert terminal opens the tender document node, and the online session table includes at least the session number, resource path, connection identifier, and connection status. Based on the connection identifier, the server sends the access status notification to the expert terminal via the corresponding WebSocket long connection. If sending fails, the connection status of the corresponding record in the online session table is updated to offline.

[0049] In step S4, during the period when the node lock is valid, the synchronous write request pointing to the resource path is subjected to level verification to obtain a write verification result, and the synchronous write request is controlled according to the write verification result and the node lock to obtain a write control result.

[0050] During the period when the node lock is valid, synchronous write requests pointing to the resource path are subject to level verification to obtain write verification results, including: Receive a synchronous write request pointing to the resource path; The synchronous write request is parsed to obtain the request session and request operation, and the login session table is queried based on the request session to obtain the request role; Based on the requesting role, the requesting operation, and the resource path, a preset review permission table is mapped to obtain the request level. The request level is compared with the locking level in the node lock to obtain the write verification result.

[0051] In one implementation, the synchronous write request is an annotation write request, a rating write request, or a content modification request sent by the expert terminal while the node lock is in a valid state. The synchronous write request uses the same structured message format as the tender document review request, and includes at least a request session field, a request role field, a request operation field, a request resource field, and a request content field. The request session field records the login session that initiated the synchronous write request; the request role field records the review role that initiated the synchronous write request; the request operation field records one of annotation writing, rating writing, or review content modification; the request resource field records the resource path pointed to by the synchronous write request; and the request content field records the data content to be written.

[0052] It should be noted that the node lock validity period is the time period during which the node lock in the current lock table is in a valid state and its expiration time is later than the current server time. After receiving the synchronous write request, the server-side write interface first reads the current lock table to confirm whether the node lock corresponding to the resource path is within the node lock validity period. If the node lock is in an invalid state, or the node lock's expiration time is earlier than or equal to the current server time, the synchronous write request will not enter the level verification process in this step and will be handled by the subsequent write admission verification process. If the node lock is within the node lock validity period, the lock level and lock holding session in the node lock will be read, and the synchronous write request will continue to be parsed.

[0053] This embodiment parses the synchronous write request to obtain the request session and request operation. The request session originates from the request session field in the synchronous write request, and the request operation originates from the request operation field in the synchronous write request. Subsequently, this embodiment queries the login session table based on the request session, reads the review role corresponding to the request session, and determines the read review role as the request role. If the synchronous write request contains a role field submitted by the terminal, this embodiment performs a consistency check between the role field and the request role; when the role field is inconsistent with the request role, the synchronous write request is marked as an abnormal role request, and an interception record is generated. If the consistency check passes, this embodiment combines the request role, the request operation, and the resource path into a request permission query item, and searches for the permission record corresponding to the request permission query item according to the permission mapping method of the preset review permission table in step S2, reads the level field in the permission record, and determines the level field as the request level.

[0054] It should be noted that the lock level and the request level adopt the same level code system. The level code system is determined by the preset review permission table mentioned in step S2, and the level code is generated by the review role sequence encoding and operation write attribute. Both the lock level and the request level come from the level field in the preset review permission table, and the server can directly compare their sizes. In this embodiment, the request level is compared with the lock level in the node lock to obtain the write verification result. If the request level is lower than the lock level, the write verification result is recorded as a low-level request; if the request level is not lower than the lock level, the write verification result is recorded as a qualified request. The write verification result only records the level comparison result, and the subsequent write control process continues to combine the lock holding session for judgment.

[0055] Specifically, the write control of the synchronous write request is performed based on the write verification result and the node lock to obtain the write control result, including: Read the lock holding session and locking level from the node lock, and extract the request identifier, request source and request time from the synchronous write request; When the request session is consistent with the lock holding session, a reentrancy pass record is generated based on the synchronous write request; When the request session is inconsistent with the lock holding session, and the write verification result indicates that the request level is lower than the lock level, an interception record is generated based on the request identifier, the request source, and the resource path; When the request session is inconsistent with the lock holding session, and the write verification result indicates that the request level is not lower than the lock level, the synchronous write request, the request level, and the request time are written into the waiting queue to generate a priority waiting record; The re-entry record, the interception record, or the priority wait record is determined as the write control result.

[0056] In one implementation, the request identifier is a unique request number generated by the server when it receives the synchronous write request. The request identifier is generated by a server-side atomic counter or a database auto-incrementing sequence according to the order of request arrival. The request source is the expert terminal session information that initiated the synchronous write request, and the request source includes at least the request session and connection identifier. The request time is a system timestamp recorded by the server when it receives the synchronous write request. The request identifier and the request time are written to the write control table simultaneously, and the request identifier serves as the basis for the arrival order when both the request level and request time are the same.

[0057] It should be noted that the reentrancy pass record is one type of write control result. If the request session is consistent with the lock holding session, it indicates that the synchronous write request originates from the current node's lock holding session. In this embodiment, a reentrancy pass record is generated based on the synchronous write request, and the synchronous write request is submitted to the write commit process for processing. The reentrancy pass record includes at least the request identifier, request session, resource path, request time, and pass status. The reentrancy pass record is not written to the waiting queue.

[0058] It should be noted that the interception record is a type of write control result. If the request session is inconsistent with the lock holding session, and the write verification result indicates that the request level is lower than the lock level, then in this embodiment, the synchronous write request is not written to the tender document resource node. Instead, an interception record is generated based on the request identifier, the request source, and the resource path. If the request operation of the synchronous write request is a review content modification, the interception record includes a write rejection identifier; if the request operation of the synchronous write request is an annotation write or a scoring write, the interception record includes a read-only degradation identifier. The write rejection identifier indicates that the synchronous write request has not entered the write submission process, and the read-only degradation identifier indicates that the expert terminal only receives the read status of the resource path. The server generates a write interception response based on the interception record and sends the write interception response to the expert terminal corresponding to the request source.

[0059] It should be noted that the priority wait record is another way of writing control results. If the request session is inconsistent with the lock holding session, and the write verification result indicates that the request level is not lower than the lock level, then this embodiment does not preempt the current node's lock, but instead executes the wait queue writing process. After writing to the wait queue, this embodiment generates a priority wait record, which at least includes the request identifier, request session, resource path, request level, request time, and waiting status.

[0060] In this embodiment, the re-entry pass record, the interception record, or the priority wait record is determined as the write control result. The write control result is written to the write control table. The write control table includes at least the request identifier, resource path, request level, request time, control type, and control status. The control type includes interception, priority wait, and re-entry pass. The control status includes intercepted, waiting, and passed. Step S5 reads the priority wait record from the write control result and performs subsequent write access verification based on the priority wait record.

[0061] In step S5, a release verification is performed based on the node lock to obtain a release result, and the lock state of the node lock is updated based on the release result. A write access verification is then performed on the waiting requests in the write control result to obtain the permission hierarchy control result for the tender document, including: Read the lock holding session and lock expiration time from the node lock, and perform holding verification on the completion request and the lock holding session based on whether a completion request for the node lock has been received, to obtain the holding verification result; A timeout check is performed based on the lock expiration time and the current server time to obtain the timeout check result, and the release result is determined based on the holding check result and the timeout check result. When the release result indicates that the verification has passed or the timeout has occurred, the node lock is updated to an invalid state, and the priority waiting record is read from the write control result. Candidate write requests are determined based on the request level, request time, and request identifier in the priority waiting record; Based on the current lock table, write access verification is performed on the candidate write requests to obtain the permission level control result of the tender documents.

[0062] In one implementation, the completion request is a structured message sent by the expert terminal to the server after writing to the resource path. The expert terminal generates a completion request for the node lock when writing to complete, canceling editing, switching resource paths, or closing the editing control corresponding to the resource path. The completion request includes at least a completion session field and a completion lock identifier field. The completion session field records the login session that initiated the completion request, and the completion lock identifier field records the lock identifier of the node lock to be released. The lock identifier is written into the current lock table by the server when the node lock is generated in step S3 and is returned to the expert terminal corresponding to the lock-holding session along with the access status notification.

[0063] This embodiment reads the lock holding session and lock expiration time from the node lock, and performs a holding verification on the completion request and the lock holding session based on whether a completion request for the node lock has been received, thus obtaining a holding verification result. When parsing the completion request, the completion session field in the completion request is read, and the field value of the completion session field is determined as the completion session; the completion lock identifier field in the completion request is read, and the field value of the completion lock identifier field is determined as the completion lock identifier.

[0064] It should be noted that the completion lock identifier is the unique lookup key for the node lock in the current lock table. In this embodiment, the node lock is searched in the current lock table based on the completion lock identifier, and the lock holding session within the node lock is read. If the completion request lacks a completion session field, lacks a completion lock identifier field, the completion lock identifier does not match a node lock, or the node lock's lock state is invalid, this embodiment determines the holding verification result as failing the verification. If no completion request for the node lock is received, this embodiment determines the holding verification result as not triggering the verification.

[0065] This embodiment performs a consistency check between the completed session and the lock-holding session to obtain a holding check result. The consistency check uses a string exact match judgment. If the completed session and the lock-holding session are the same, the holding check result is determined to be a pass; if the completed session and the lock-holding session are different, the holding check result is determined to be a fail. The holding check result is determined solely by the completed session, the completed lock identifier, and the node locks in the current lock table, and does not accept the lock level or lock status submitted by the expert terminal as the verification basis.

[0066] This embodiment performs a timeout check based on the lock expiration time and the current server time to obtain a timeout check result. If the lock expiration time is earlier than or equal to the current server time, the timeout check result is determined to be a timeout failure; if the lock expiration time is later than the current server time, the timeout check result is determined to be no timeout. The lock expiration time is taken from the session expiration time of the lock-holding session in the login session table.

[0067] In this embodiment, the release result is determined based on the holding verification result and the timeout verification result. When the holding verification result is a pass, the release result is determined to be a pass; when the holding verification result is a fail and the timeout verification result is a timeout failure, the release result is determined to be a timeout failure; when the holding verification result is a fail and the timeout verification result is a no-timeout, the release result is determined to be a fail.

[0068] When the release result indicates that the verification passed or the lock expired, this embodiment updates the node lock to an invalid state and reads the priority waiting record from the write control result. When updating the node lock, this embodiment locates the node lock in the current lock table, modifies the lock status field of the node lock from valid to invalid, and retains the resource path, resource granularity, locking level, lock holding session, heartbeat update time, and lock expiration time in the node lock. The retained node lock no longer participates in the valid lock set reading in step S3.

[0069] It should be noted that the priority waiting record originates from the write control result generated in step S4. The priority waiting record includes at least a request identifier, a synchronous write request, a request level, a request time, a resource path, and a waiting status. In this embodiment, after the node lock is updated to an invalid state, a record with a control type of priority waiting, a control status of waiting, and a resource path identical to the resource path in the node lock is read from the write control result to obtain the priority waiting record. If the priority waiting record does not exist, this embodiment determines the permission hierarchical control result of the tender document as the node lock being released and there being no waiting request.

[0070] This embodiment determines candidate write requests based on the request level, request time, and request identifier in the priority waiting records. The determination process is as follows: First, the request levels are compared, and the synchronous write request corresponding to the priority waiting record with the highest request level is determined as a candidate write request; if there are multiple priority waiting records with the same request level, the request times are compared, and the synchronous write request corresponding to the priority waiting record with the earliest request time is determined as a candidate write request; if there are multiple priority waiting records with the same request level and the same request time, the request identifiers are compared, and the synchronous write request corresponding to the priority waiting record with the earliest arrival order corresponding to the request identifier is determined as a candidate write request.

[0071] This embodiment performs write admission verification on the candidate write request based on the current lock table. Specifically, it reads the resource path in the candidate write request and queries the current lock table for valid state lock records based on the resource path in the candidate write request. If there is no valid state lock record in the current lock table that conflicts with the resource path in the candidate write request, the priority waiting record corresponding to the candidate write request is updated to the admission state, and the candidate write request is re-entered into the permission mapping and resource conflict identification process. If there is still a valid state lock record in the current lock table that conflicts with the resource path in the candidate write request, the priority waiting record corresponding to the candidate write request is kept in the waiting state. The method for determining resource conflicts is the same as the method for determining path conflicts between the target lock path and the locked paths in the valid lock set in step S3.

[0072] It is worth noting that the permission hierarchical control result of the tender document includes node lock release status, waiting request admission status, and candidate write request identifier. The node lock release status is released, release failed, or timed out; the waiting request admission status is no waiting request, admission status, or waiting status; the candidate write request identifier is null or a selected request identifier. In this embodiment, the node lock release status, the waiting request admission status, and the candidate write request identifier are written to the permission control log, and the online session table is used to query the expert terminals that access the resource path and whose connection status is online. The server reads the connection identifier corresponding to the expert terminal and sends a status update message through the corresponding WebSocket long connection. The status update message includes at least the resource path, node lock release status, waiting request admission status, and candidate write request identifier. If the sending fails, the server updates the connection status of the corresponding record in the online session table to offline status.

[0073] In summary, this invention parses the bid review requests sent by expert terminals to obtain the review role, operation type, and resource path, and determines the locking level, resource granularity, and locking method based on a preset review permission table. When the locking method is exclusive write, resource conflict identification is performed on the current lock table and a node lock is generated. During the validity period of the node lock, the level verification and write control are performed on synchronous write requests. After the node lock is released or expires, write access verification is performed on waiting requests. This invention achieves hierarchical locking of target resource nodes of bid documents, orderly control of synchronous writes, and continuous access after lock release during the online bidding review process.

[0074] The second embodiment of the present invention provides a permission hierarchical control device for an online bidding review system, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.

[0075] It should be noted that the permission hierarchical control device for an online bidding review system provided in this embodiment of the invention is used to execute all the process steps of the permission hierarchical control method for an online bidding review system described in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0076] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0077] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for hierarchical access control in an online bidding review system, characterized in that, include: The process involves acquiring a bid review request sent by an expert terminal, parsing the bid review request to obtain the review role, operation type, and resource path, including: reading the session field, file field, node field, and operation field from the bid review request; querying the login session table based on the session field to obtain the review role; identifying the operation type based on the operation field; determining at least one of a file identifier, chapter identifier, table identifier, and scoring item identifier based on the file field, the node field, and a preset node directory table; and generating a resource path based on at least one of the file identifier, the chapter identifier, the table identifier, and the scoring item identifier. Based on the review role, the operation type, and the resource path, a preset review permission table is mapped to obtain the lock level, resource granularity, and lock method. When the locking method is exclusive write, resource conflict identification is performed on the current lock table according to the resource path and the resource granularity to obtain the conflict result, and a node lock is generated when the conflict result is no conflict. During the period when the node lock is valid, the synchronous write request pointing to the resource path is subjected to level verification to obtain the write verification result, and the synchronous write request is controlled according to the write verification result and the node lock to obtain the write control result. The node lock is released and verified to obtain a release result. The lock state of the node lock is updated according to the release result. The write access verification is performed on the waiting request in the write control result to obtain the permission hierarchical control result of the tender document.

2. The access control method for an online bidding review system according to claim 1, characterized in that, The step of mapping permissions to a preset review permission table based on the review role, the operation type, and the resource path to obtain the lock level, resource granularity, and lock method includes: Extract resource granularity identifiers based on the resource path; The review role, the operation type, and the resource granularity identifier are combined into a permission query item; Search the preset review permission table for the permission record corresponding to the permission query item; Read the level field, granularity field, and method field from the permission record to obtain the lock level, resource granularity, and lock method.

3. The access control method for an online bidding review system according to claim 1, characterized in that, The step of identifying resource conflicts in the current lock table based on the resource path and the resource granularity to obtain conflict results includes: The resource path is normalized according to the resource granularity to obtain the target lock path; Read the lock records with valid states from the current lock table to obtain the set of valid locks; The target lock path is compared with the locked paths in the set of valid locks to determine the conflict result.

4. The access control method for an online bidding review system according to claim 3, characterized in that, The step of determining a path conflict between the target lock path and the locked paths in the valid lock set to obtain a conflict result includes: When the target lock path is the same as any locked path in the set of valid locks, the conflict result is determined to be a same path conflict; When the target lock path contains the locked path or the locked path contains the target lock path, the conflict result is determined to be a hierarchical path conflict; When both the target lock path and the locked path contain a file identifier and a rating item identifier, and the file identifier in the target lock path is the same as the file identifier in the locked path, and the rating item identifier in the target lock path is the same as the rating item identifier in the locked path, the conflict result is determined to be a rating item conflict. When the target lock path and the locked path do not satisfy the same path conflict, hierarchical path conflict, and scoring item conflict, the conflict result is determined to be no conflict.

5. The access control method for an online bidding review system according to claim 1, characterized in that, The step of generating a node lock when the conflict result is conflict-free includes: When the conflict result is no conflict, the current session is extracted according to the tender document review request to obtain the lock holding session; The target lock path, the resource path, the resource granularity, the locking level, the lock holding session, and the lock validity status obtained after normalizing the resource path according to the resource granularity are written into the current lock table to obtain the node lock; An access status notification is generated based on the node lock, and the access status notification is sent to the expert terminal accessing the resource path.

6. The access control method for an online bidding review system according to claim 1, characterized in that, During the period when the node lock is valid, the synchronous write request pointing to the resource path is subjected to a level verification to obtain a write verification result, including: Receive a synchronous write request pointing to the resource path; The synchronous write request is parsed to obtain the request session and request operation, and the login session table is queried based on the request session to obtain the request role; Based on the requesting role, the requesting operation, and the resource path, a preset review permission table is mapped to obtain the request level. The request level is compared with the locking level in the node lock to obtain the write verification result.

7. The access control method for an online bidding review system according to claim 6, characterized in that, The step of controlling the synchronous write request based on the write verification result and the node lock to obtain the write control result includes: Read the lock holding session and locking level from the node lock, and extract the request identifier, request source and request time from the synchronous write request; When the request session is consistent with the lock holding session, a reentrancy pass record is generated based on the synchronous write request; When the request session is inconsistent with the lock holding session, and the write verification result indicates that the request level is lower than the lock level, an interception record is generated based on the request identifier, the request source, and the resource path; When the request session is inconsistent with the lock holding session, and the write verification result indicates that the request level is not lower than the lock level, the synchronous write request, the request level, and the request time are written into the waiting queue to generate a priority waiting record; The re-entry record, the interception record, or the priority wait record is determined as the write control result.

8. The access control method for an online bidding review system according to claim 7, characterized in that, The process involves performing a release verification based on the node lock to obtain a release result, updating the lock state of the node lock based on the release result, performing write access verification on the waiting requests in the write control result, and obtaining the permission hierarchical control result for the tender document, including: Read the lock holding session and lock expiration time from the node lock, and perform holding verification on the completion request and the lock holding session based on whether a completion request for the node lock has been received, to obtain the holding verification result; A timeout check is performed based on the lock expiration time and the current server time to obtain the timeout check result, and the release result is determined based on the holding check result and the timeout check result. When the release result indicates that the verification has passed or the timeout has occurred, the node lock is updated to an invalid state, and the priority waiting record is read from the write control result. Candidate write requests are determined based on the request level, request time, and request identifier in the priority waiting record; Based on the current lock table, write access verification is performed on the candidate write requests to obtain the permission level control result of the tender documents.

9. A permission-based hierarchical control device for an online bidding review system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method according to any one of claims 1 to 8.

Images