A defect accessory processing method and device, computer equipment and storage medium

Abstract

The present application relates to the technical field of computer, disclose a kind of defect accessory processing method, device, computer equipment and storage medium, method includes: obtaining at least one target defect task in unprocessed state in user folder;In shared storage space, the corresponding target access path is generated for each target defect task;Based on target access path, the file processing operation is executed to the accessory file corresponding to target defect task of target defect task.The present application solves the problem that the existing defect accessory management process relies on manual repetitive operation, accessory scattered storage and cannot be automatically centralized.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically to a method, apparatus, computer device, and storage medium for processing defective attachments. Background Technology

[0002] In software development and test management, defect tracking systems (such as JIRA) are widely used for the flow and management of tasks and defects. After testers create defect tasks and upload relevant attachments in the defect attachment management system, the task is routed to the corresponding development node for processing. Currently, the personnel at the development node need to manually log in to the defect attachment management system, locate and download the attachments to local storage. If the work order is subsequently transferred to others, each recipient must repeat the same login, search, and download operations. The entire process relies on manual intervention, and attachments are stored scattered across the terminal devices of each processor. This leads to inefficiency, redundancy, and scattered storage and lack of centralized management of attachments in the defect attachment management process. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a method, apparatus, computer equipment, and storage medium for processing defective attachments, in order to solve the problems of existing defective attachment management processes relying on repetitive manual operations, scattered storage of attachments, and inability to automatically and centrally process them.

[0004] In a first aspect, embodiments of the present invention provide a method for processing defective attachments, the method comprising:

[0005] Retrieve at least one target defect task that is currently in an unprocessed state from the user folder; Generate a corresponding target access path for each of the target defect tasks in the shared storage space; Based on the target access path, file processing operations are performed on the attachment files corresponding to the target defect task.

[0006] Furthermore, the step of obtaining at least one target defect task in the user folder that is in an unprocessed state includes: Obtain at least one original defect task from the user folder, wherein the original defect task includes a task identifier and a first task status; Detect whether there is a server task associated with the task identifier in the shared storage space; If there is no server task associated with the task identifier, the original defect task is determined to be a target defect task in an unprocessed state. Alternatively, if a server task is associated with the task identifier, the second task status of the server task is obtained, and it is checked whether the first task status and the second task status are consistent. If they are inconsistent, the original defect task is determined to be a target defect task in an unprocessed state.

[0007] Furthermore, generating a corresponding target access path for each target defect task in the shared storage space includes: Obtain the attribute information of the target defect task, wherein the attribute information includes at least one of project identifier, authority identifier, and task identifier; Obtain the path configuration template of the shared storage space, and replace the variable placeholders of the path configuration template with the attribute information to generate the initial access path of the target defect task; Verify whether the initial access path meets the preset access conditions, obtain the verification result, and adjust the initial access path based on the verification result to obtain the target access path.

[0008] Furthermore, the step of performing file processing operations on the attachment files corresponding to the target defect task based on the target access path includes: Obtain the attachment file and attachment name corresponding to the target defect task; In the shared storage space, query whether there is a pre-stored file with the same file name as the attachment name under the target access path; If no pre-stored file with the same name as the attachment exists, the attachment file corresponding to the target defect task is stored in the shared storage space according to the target access path; or, if a pre-stored file with the same name as the attachment exists, file processing operations are performed on the attachment file corresponding to the target defect task based on the pre-stored file.

[0009] Furthermore, the step of performing file processing operations on the attachment file corresponding to the target defect task based on the pre-stored file includes: Calculate the first hash value of the pre-stored file and obtain the second hash value of the attached file; The first hash value is compared with the second hash value to obtain the comparison result; If the comparison result shows that the first hash value and the second hash value are the same, the file processing operation is terminated; or, if the comparison result shows that the first hash value and the second hash value are not the same, the attachment file corresponding to the target defect task is re-stored in the shared storage space according to the target access path to overwrite the pre-stored file.

[0010] Furthermore, the step of performing file processing operations on the attachment files corresponding to the target defect task based on the target access path includes: In response to an attribute change event of the target defect task; Based on the attribute change event, a corresponding update access path is regenerated in the shared storage space for the target defect task; Move the attachment files corresponding to the target defect task stored under the target access path to the update access path for storage.

[0011] Furthermore, the step of performing file processing operations on the attachment files corresponding to the target defect task based on the target access path includes: In response to the state change event of the target defect task; The third task status of the target defect task is reacquired based on the state change event; When the third task is in a non-processing state, delete the attachment file corresponding to the target defect task in the shared storage space according to the target access path.

[0012] Secondly, embodiments of the present invention provide a defective accessory processing apparatus, the apparatus comprising: The acquisition module is used to acquire at least one target defect task that is in an unprocessed state in the user folder; The generation module is used to generate a corresponding target access path for each of the target defect tasks in the shared storage space; The execution module is used to perform file processing operations on the attachment files corresponding to the target defect task based on the target access path.

[0013] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0014] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect or any corresponding embodiment thereof.

[0015] The method provided in this application has the following beneficial effects: The method provided in this application can automatically identify and focus on defect tasks that need to be processed by obtaining unprocessed target defect tasks in the user folder, avoiding the manual operation of traversing and filtering all tasks, and providing input for subsequent targeted processing. By generating a corresponding target access path for each target defect task in the shared storage space, a unique storage location is dynamically established for each task in the shared storage, realizing the automation and standardization of attachment storage paths, laying the foundation for centralized file management and collection by task and responsibility. By performing file processing operations on the attachment files corresponding to the target defect task based on the target access path, the method can automatically complete the download, move or delete operations of attachments based on the generated path, thereby integrating the discrete actions performed manually into an automated process, improving processing efficiency, ensuring the accuracy and consistency of file operations, and realizing the full lifecycle automated management of attachments from acquisition to archiving or cleaning. Attached Figure Description

[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a defect attachment processing method according to an embodiment of the present invention; Figure 2 This is a structural block diagram of a defect attachment processing system according to an embodiment of the present invention; Figure 3 This is a structural block diagram of a defective accessory processing device according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0019] According to embodiments of the present invention, a method, apparatus, computer device, and storage medium for processing defective attachments are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] This embodiment provides a method for processing defective attachments. Figure 1 This is a flowchart of a defect attachment processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain at least one target defect task in the user folder that is in an unprocessed state.

[0021] In this embodiment, the user folder refers to a personal directory pre-set for each task handler (e.g., a developer) in a shared storage space (such as a local area network shared drive), used to store attachments for the tasks they are responsible for; the unprocessed state refers to a task that requires system intervention to synchronize, update, or clean up attachments, such as a new task, a task whose status has changed, or an isolated task that does not exist on the server; the target defect task is the set of tasks to be processed determined after screening. In terms of implementation, firstly, the contents under the user folder (such as subfolders named after task identifiers) are traversed to identify the original defect task and obtain its local status (first task status); then, by calling the API of the defect management system (such as JIRA), it is checked whether each task identifier has an associated server task on the server side, and the status is compared. If the server task does not exist, or the latest status of the server task (second task status) is inconsistent with the local status, then the task is determined to be a target defect task in an unprocessed state.

[0022] For example, suppose there is a user folder "\NAS\JIRA_Attachments\UserA" in the shared storage space, which contains a subfolder "PROJ-123" (representing the original defect task with the task identifier PROJ-123). This subfolder contains a metadata file recording the local status. After scanning this folder, the task identifier "PROJ-123" and the first task status "In Progress" are obtained. Subsequently, the JIRA API is called to query the server task, and it is found that the task status on the server has been updated to "Resolved" (the second task status). Since the first task status and the second task status are inconsistent, "PROJ-123" is determined to be the target defect task in an unprocessed state, and it is added to the pending list so that an access path can be generated for it and attachment synchronization or cleanup operations can be performed later.

[0023] Step S102: Generate a corresponding target access path for each target defect task in the shared storage space.

[0024] In this embodiment, the attribute information of the target defect task (including project identifier, authority identifier, and task identifier) ​​is first obtained; then, a pre-configured path template (such as {root path} / {project identifier} / {authority identifier} / {task identifier}) is obtained, and the variable placeholders in the template are replaced with actual attribute values ​​to generate an initial access path; finally, the initial path is validated (such as format validity, directory existence, and sufficient permissions) and necessary adjustments are made according to the validation results (such as automatically creating missing directories, standardizing separators, and resolving naming conflicts) to obtain the final target access path.

[0025] As an example, suppose the target defect task has the following attributes: Project ID "PROJ", Responsibility ID "UserA", and Task ID "PROJ-456". The configured path template is \\NAS\JIRA_Attachments\{Project}\{Responsible Person}\{Task Number}. Substituting the attribute values ​​into the template generates the initial access path \\NAS\JIRA_Attachments\PROJ\UserA\PROJ-456. Subsequent verification reveals that the "PROJ" directory in this path does not exist, so it is automatically created, and \\NAS\JIRA_Attachments\PROJ\UserA\PROJ-456 is confirmed as the target access path for storing all attachments for this task.

[0026] Step S103: Perform file processing operations on the attachment files corresponding to the target defect task based on the target access path.

[0027] In this embodiment, file processing operations may specifically include downloading attachments from the server to the specified path, moving attachments to a new path (i.e., updating the access path) based on changes in task attributes, or deleting attachments from the specified path when the task status changes to a non-processing state. The implementation follows a unified decision-making and execution framework: first, based on the current attributes and status of the target defect task, the required operation type is determined; then, based on the target access path already determined for the task, specific file operation instructions (such as copy, move, or delete) are invoked through the file system operation module, acting on the attachment files under this path. The core objective of the processing is to ensure that the attachment storage location, content, and latest task status are synchronized. File processing operations support transactional execution, meaning the operation is either completely successful or rolled back to the state before the operation, ensuring data consistency; for processing large-scale attachments, chunked transmission or breakpoint resume mechanisms can be used.

[0028] As an example, suppose the target defect task "PROJ-789" has generated a target access path "\NAS\JIRA_Attachments\PROJ\UserB\PROJ-789". Subsequently, by listening to the JIRA Webhook, the status of this task changes to "Closed" (status change event). In response to this event, first confirm that its third task status is "Closed" (belonging to a non-processing state), and then, based on the aforementioned target access path, automatically delete all attachment files stored under this path (i.e., the PROJ-789 subfolder within the UserB folder), completing the automatic cleanup of storage space.

[0029] In this embodiment of the application, obtaining at least one target defect task in an unprocessed state in the user folder includes: Step A1: Obtain at least one original defect task from the user folder, wherein the original defect task includes a task identifier and a first task status.

[0030] Specifically, it iterates through all direct subfolders under the specified user folder (usually named with a task identifier, such as JIRA ticket number "PROJ-123"), each subfolder representing an original defect task. The task identifier is obtained by parsing the subfolder's name, and the initial task status is inferred or obtained by reading specific metadata files within the subfolder (such as status.info), parsing the status code embedded in the folder name, or using file system timestamps (such as last modified time). The initial task status reflects a snapshot of the task's status in the local storage view at the start of the current processing cycle, such as pending, downloaded, or processing.

[0031] In addition, the system can maintain a lightweight database or index file that records the task identifiers and statuses of all subfolders (i.e., original defect tasks) under each user's folder. By querying this database or index, a list of original defect tasks, along with their corresponding task identifiers and first task statuses, can be retrieved in batches. The system can also determine, based on configuration files, which specific user folders (such as the folders of all active developers) to retrieve original defect tasks from, allowing administrators to flexibly define the scope of task processing.

[0032] Step A2: Detect whether there is a server task associated with the task identifier in the shared storage space.

[0033] Specifically, the JIRA interface module in the attachment management engine proactively queries the central server of the defect management system (such as the JIRA server) based on the task identifier carried by the original defect task (e.g., JIRA ticket number "PROJ-123") to confirm whether the task still has a valid record on the server side. The implementation involves: first, calling the REST API interface provided by the defect management system using pre-configured account credentials. The task identifier is passed as a key parameter to the API request to query the server for the basic information of the corresponding task. Second, receiving and parsing the server's API response. If the server returns valid task data (e.g., a JSON object containing fields such as status identifier and responsibility identifier), it is determined that a server task associated with the task identifier exists; if the server returns an error code (e.g., "404 Not Found"), indicating that the task has been deleted on the server side or the task identifier is invalid, it is determined that the task does not exist.

[0034] Additionally, the system can include a cache of queried task identifiers. During detection, the local cache is queried first. If the cache records that the task identifier recently existed on the server, the real-time API query can be temporarily skipped (especially for polling mode), and it can be directly determined to exist. Alternatively, the task identifiers of multiple original defective tasks can be packaged and detected through batch API queries. The detection process can also include handling logic for abnormal situations such as network timeouts and authentication failures.

[0035] Step A3: If there is no server task associated with the task identifier, the original defect task is determined to be a target defect task in an unprocessed state.

[0036] Specifically, when a clear signal indicating that a task does not exist is received (e.g., an API returning a "404 Not Found" status code), it is assumed that there is no valid record corresponding to this task identifier in the server-side data source. At this point, the subfolder named with that task identifier and its contents (i.e., the original defect task) in the user's folder are considered as pending data. This corresponds to situations such as the server-side task being deleted, the task identifier being entered incorrectly, or the current query account lacking sufficient permissions to access it. This original defect task is classified as an unprocessed target defect task, requiring special handling by the system and not representing a regular processing state. The judgment operation can also trigger internal status flags (such as setting flags in memory objects indicating needing cleanup or alerts) or generate a pending item record containing the task identifier, so that subsequent processes can identify and perform corresponding file processing operations, such as triggering the cleanup of local redundant files or notifying the administrator to verify the cause of data inconsistencies.

[0037] Step A4: If there is a server task associated with the task identifier, obtain the second task status of the server task and check whether the first task status and the second task status are consistent. If they are inconsistent, determine that the original defect task is a target defect task in an unprocessed state.

[0038] Specifically, firstly, by using the established (or re-invoked) defect management system API (such as JIRA's REST API), the current second task status (e.g., in progress, resolved, reopened, closed, etc.) of the confirmed server task is extracted from its detailed information. Next, the second task status is directly compared with the first task status carried by the original defect task (e.g., status recorded in a local metadata file, such as "processing") or an equivalence check is performed using predefined status mapping rules. If the two are inconsistent, it indicates that the server-side task status has changed (e.g., the task has been reassigned, reactivated, or the resolution status has changed), and the locally stored status information is outdated and fails to reflect this change. Therefore, the original defect task is determined to be a target defect task in an unprocessed state. An unprocessed state here refers to a status indicating that the task requires synchronization updates or corresponding file operations (e.g., moving attachments, re-downloading, or cleaning). The detection and judgment process can include a status caching mechanism. For example, if the status comparison of the same task identifier has been performed within a short period of time and the results are consistent, the current detection can be skipped; or, after a discrepancy is determined, the specific differences in the status change can be recorded (such as changing from in progress to resolved). By comparing the server's authoritative status with the local cache status, tasks whose status has changed are identified and filtered as target defect tasks that need to be processed, thereby ensuring real-time synchronization between local file management actions and server task status.

[0039] By retrieving at least one original defect task from the user folder, the system can automatically discover and load locally stored pending task data, providing initial input for subsequent status comparison and filtering. By detecting the existence of a server task associated with the task identifier in the shared storage space, a correlation verification mechanism between the local task identifier and the server-side authoritative record is established, providing a basis for determining whether a task is new or already exists. If the task does not exist, it is determined to be in an unprocessed state, identifying local tasks that no longer exist on the server and marking them as objects requiring processing, which helps maintain the consistency between local and server data. If the task exists, a second task status is retrieved and checked for consistency; if inconsistent, it is determined to be in an unprocessed state. This achieves dynamic comparison between the local cached status and the server's real-time status, enabling timely capture of task status updates and filtering tasks with changed statuses as targets requiring synchronous processing, thereby ensuring that subsequent file operations are based on the current task status.

[0040] In this embodiment of the application, a corresponding target access path is generated for each target defect task in the shared storage space, including: Step B1: Obtain the attribute information of the target defect task, wherein the attribute information includes at least one of project identifier, authority identifier, and task identifier.

[0041] It should be noted that attribute information is the core metadata used to dynamically construct storage paths, specifically including: Project Identifier: refers to the code of the specific project or product to which the defect task belongs (such as the project key in JIRA, such as "PROJ"), used for project-level categorization in shared storage; Responsibility Identifier: refers to the identity identifier of the current person in charge of the defect task (such as username "UserA" or employee ID), used to locate attachments to the personal folder of the corresponding person in charge; Task Identifier: that is, the number of the defect task (such as JIRA ticket number "PROJ-123"), used to create subfolders under the person in charge's folder to isolate attachments of different tasks.

[0042] Specifically, through its JIRA interface module, for each target defect task, a detailed API request is initiated to the defect management system server using its known task identifier as the query key. From the returned structured response data, such as JSON, the project identifier, responsibility identifier, and task identifier are parsed and extracted. A temporary attribute cache (MemoryCache) can also be built. For tasks referenced multiple times within the same processing cycle, attribute information can be preferentially read from the cache to avoid repeated API calls to the server. Alternatively, it supports pre-parsing some attribute information from upstream sources (such as the naming convention of the original defect task's folder) (e.g., parsing the task identifier and project identifier from the folder name "PROJ-123") as a supplementary or backup data source for API queries. Obtaining attribute information collects the necessary and accurate contextual data for path generation, ensuring that the generated target access path reflects the task's affiliation in the three dimensions of project, responsible person, and task.

[0043] Step B2: Obtain the path configuration template of the shared storage space, and replace the variable placeholders in the path configuration template with attribute information to generate the initial access path of the target defect task.

[0044] It should be noted that a path configuration template is a predefined path string model containing placeholders for specific format variables. It is usually pre-configured by the system administrator and stored in a configuration file, database, or system memory. Its example format is like {BasePath}\{Project Identifier}\{Responsibility Identifier}\{Task Identifier}, where the part enclosed in curly braces {} is the variable placeholder.

[0045] Specifically, the rule processing module first obtains the template from the aforementioned configuration source. Then, using the attribute information (project identifier, responsibility identifier, task identifier) ​​as input, it executes a template rendering or string replacement process: it iterates through all variable placeholders in the template, identifies the variable name represented by each placeholder (e.g., project identifier), and searches for the corresponding specific value in the attribute information (e.g., "PROJ"). Then, it replaces the entire placeholder in the template with this specific value (e.g., replacing {project identifier} with PROJ). After this process, a specific path string is generated, instantiated by the specific attribute value, i.e., the initial access path, such as \\NAS\JIRA_Attachments\PROJ\UserA\PROJ-123. The path configuration template supports conditional judgments (determining whether to add a subdirectory layer based on the project identifier), date formats (e.g., {current date:YYYYMM}), and the replacement engine can handle the standardization of escape characters and path separators to ensure that the generated path is valid across different operating system environments.

[0046] Step B3: Verify whether the initial access path meets the preset access conditions, obtain the verification result, and adjust the initial access path based on the verification result to obtain the target access path.

[0047] Specifically, the initial access path (the specific path string) is taken as input and checked against preset access conditions. These preset access conditions include, but are not limited to: path validity checks to ensure the path format conforms to operating system specifications, contains no illegal characters, and its length does not exceed limits; storage boundary checks to confirm that the root directory of the path is within the allowed range of the configured shared storage space (such as a specified LAN shared drive), preventing the path from pointing to unauthorized storage locations; and directory existence and permission pre-checks, which simulate or lightweightly check the existence of the parent directory in the path through the file system operation module, and whether the system process has write permissions to create subdirectories and files within it. After verification, a verification result is generated (e.g., success, failure - invalid path, failure - insufficient permissions, etc.).

[0048] The adjustment operation is based on the verification result: if the verification is successful, the initial access path is directly used as the target access path; if the verification fails, it is automatically corrected according to the preset adjustment strategy, such as: automatically creating missing intermediate directories in the path, replacing illegal characters in the path with underscores, or automatically adding a sequence suffix (such as "_1") to generate a path when there is a name conflict, thereby obtaining a certain usable and compliant target access path. The verification process can introduce path security filtering (to prevent directory traversal attacks) and performance optimization (such as caching recently successful paths and skipping duplicate verifications); the adjustment strategy can be configured for hierarchical processing, such as triggering an alarm for permission errors instead of automatic adjustment.

[0049] By acquiring the attribute information of the target defect task, the core metadata of the task can be extracted, providing a dynamic data foundation for constructing storage paths with clear attribution and classification significance. By obtaining the path configuration template and replacing variable placeholders with attribute information, an initial access path is generated, achieving automated generation from abstract rules to concrete paths. This ensures that attachments for each task can be located according to a predetermined directory structure. By verifying whether the initial access path meets preset access conditions and adjusting based on the results, the target access path is obtained. A usability check is performed on the generated path, automatically correcting illegal paths, creating missing directories, or handling naming conflicts, ensuring that the obtained path is writable and conforms to specifications, thus guaranteeing reliable storage of attachments.

[0050] In this embodiment of the application, file processing operations are performed on the attachment files corresponding to the target defect task based on the target access path, including: Step C1: Obtain the attachment file and attachment name corresponding to the target defect task.

[0051] Specifically, based on the identified target defect task (i.e., the task that has been selected for processing) and its task identifier, a list of all attachments under that task is queried by calling the API interface of the defect management system (such as JIRA). From the structured data (usually a JSON array) returned by the API, each attachment is parsed to obtain: the attachment file, which is a binary data stream or temporary file that can be downloaded from the server via a specific URL (usually containing the attachment ID); and the attachment name, which is the original filename of the attachment when it is stored on the server (e.g., error_log.txt). The retrieval process may include parallel download optimization (initiating download requests for multiple attachments simultaneously), network error retry mechanisms, and temporarily storing attachment metadata (such as name, size, MIME type) in an in-memory structure for later use.

[0052] Step C2: In the shared storage space, check if there is a pre-saved file with the same file name as the attachment name under the target access path.

[0053] Specifically, the file system operation module directly accesses the directory at the specified path in the shared storage space (i.e., the designated LAN shared disk or network storage location) based on the target access path, lists all existing files (i.e., pre-stored files) in that directory, and extracts the filenames of these files one by one. Simultaneously, it compares the attachment name (the original filename obtained from the server, such as error_log.txt) with the filename of each pre-stored file (including case-sensitive handling, depending on the operating system configuration) to determine if there is a completely identical match. The query process can use a cached index (e.g., maintaining a mapping from a path to a list of files) or support fuzzy matching to handle minor differences in filenames caused by automatic system renaming (such as the addition of a suffix), but the core comparison remains based on name consistency.

[0054] Step C3: If no pre-stored file with the same name as the attachment exists, store the attachment file corresponding to the target defect task in the shared storage space according to the target access path; or, if a pre-stored file with the same name as the attachment exists, perform file processing operations on the attachment file corresponding to the target defect task based on the pre-stored file.

[0055] By obtaining the attachment files and names corresponding to the target defect task, the source data content of the attachments to be processed and their original identifiers on the server can be obtained, providing input for subsequent file location and comparison. By querying the shared storage space to see if a pre-stored file with the same file name as the attachment exists under the target access path, an existence check of the target location is performed before storage, enabling the detection of potential file duplication or conflict, providing information for decision-making. Storing new attachments in the shared storage space if they do not exist achieves conflict-free archiving; while performing file processing operations based on pre-stored files if they exist introduces differentiated processing logic for existing files, avoiding simple overwriting or ignoring, providing an execution method for subsequent deduplication or version updates, and achieving effective storage management of attachments.

[0056] In this embodiment of the application, a file processing operation is performed on the attachment file corresponding to the target defect task based on the pre-stored file, including: calculating the first hash value of the pre-stored file and obtaining the second hash value of the attachment file; comparing the first hash value and the second hash value to obtain a comparison result; if the comparison result is that the first hash value and the second hash value are consistent, then the file processing operation is terminated; or, if the comparison result is that the first hash value and the second hash value are inconsistent, then the attachment file corresponding to the target defect task is re-stored to the shared storage space according to the target access path to overwrite the pre-stored file.

[0057] Specifically, differentiated file processing is performed based on the query results. If the query indicates that no pre-stored file with the same attachment name exists under the target access path, the attachment file (binary data stream) obtained from the server is directly downloaded and stored under that path through the file system operation module, completing the initial archiving of the attachment. If a pre-stored file with the same name exists, content-based verification processing is triggered: first, the first hash value of the pre-stored file is calculated (e.g., using MD5 or SHA-1 algorithms to hash the file content), and simultaneously, the second hash value of the attachment file is obtained through metadata attached when the attachment file is obtained from the server or through real-time calculation; then, the two hash values ​​are compared to obtain the comparison result. If the comparison result is consistent, it indicates that the pre-stored file and the server attachment content are the same, and no repeated operation is needed, so the current file processing is terminated (downloading is skipped) to save bandwidth and storage I / O; if inconsistent, it indicates that the attachment has been updated on the server side, and the attachment file is downloaded and stored again according to the target access path, overwriting the original pre-stored file, ensuring that the local storage is synchronized with the server version. Hash calculation can be stream-based (calculated while downloading); at the same time, hash value results can be cached to avoid repeated calculations for unchanged files.

[0058] By calculating the first hash value of the pre-stored file and obtaining the second hash value of the attached file, the content characteristics of local and server files can be quantified, avoiding misjudgments caused by comparing only filenames, sizes, or modification times. Comparing the first and second hash values ​​enables rapid comparison of file content, providing a basis for subsequent operational decisions. If the comparison result is consistent, terminating the file processing operation allows skipping redundant download and write operations when the content has not changed, avoiding waste of network bandwidth and storage resources. If the comparison result is inconsistent, re-storing to overwrite the pre-stored file allows for file version synchronization when content updates are detected, ensuring that locally stored attachments are consistent with the latest version on the server.

[0059] In this embodiment of the application, file processing operations are performed on the attachment files corresponding to the target defect task based on the target access path, including: Step D1, in response to the attribute change event of the target defect task.

[0060] Specifically, an attribute change event refers to a modification of a specific attribute value of a target defect task in a defect management system (such as a JIRA server). For example, the current person in charge of the task (responsibility identifier) ​​changes from user A to user B, or the project to which the task belongs (project identifier) ​​is adjusted. The response operation implementation methods include at least the following two modes: Event-driven mode: By listening to the Webhook notification mechanism provided by the defect management system, when a task attribute update occurs, the server actively sends an event notification containing the task identifier and change details to the callback address registered in the system. Parsing this notification triggers a response. Timed polling mode: During the execution cycle of a scheduled task, the latest task attributes (such as the person in charge) obtained from the server are compared with the old attributes reflected in local records or paths. When a difference is detected, an attribute change event is generated internally. The response mechanism can include event deduplication (avoiding multiple triggers of the same event within a short period), event priority queue processing (ensuring that important changes are responded to first), and compensatory polling checks for network anomalies or event loss.

[0061] Step D2: Based on the attribute change event, regenerate the corresponding update access path for the target defect task in the shared storage space.

[0062] Specifically, an attribute change event must include at least the identifier of the target defect task that has changed (e.g., task ID) and the new attribute values ​​(e.g., the new responsible person's username). First, based on the task identifier, the latest attribute information for the task (including potentially changed project identifiers, responsibility identifiers, etc.) is retrieved from the server or event data. Then, the path generation mechanism is reused: a path configuration template from shared storage is obtained, and the variable placeholders in the template are replaced with the new attribute information, thereby generating an updated access path reflecting the latest task attribution (e.g., after the responsible person changes from UserA to UserB, the path is updated from ...\UserA\... to ...\UserB\...). For common events like responsible person changes, the generation process can directly perform partial replacement in memory based on the old path string (replacing the old responsible person's name with the new responsible person's name) without fully executing the template rendering process; simultaneously, lightweight validation is performed on the newly generated path.

[0063] Step D3: Move the attachment files corresponding to the target defect task stored under the target access path to the update access path for storage.

[0064] Specifically, atomic file system move instructions are executed through the file system operation module. Based on the updated access path as the target directory, and utilizing the target defect task associated with the attribute change event, the attached files under the target access path generated based on the old attributes in the shared storage space are located. Then, all attached files under this path are moved as a whole to the updated access path. This operation ensures that the physical location of the files on the storage medium is updated without creating redundant copies. The move operation can include transactional guarantees: for example, creating all files successfully under the new path before deleting the files under the original path to prevent data loss during the move; simultaneously, the internal file location index can be updated or a move log can be recorded to maintain metadata consistency.

[0065] By responding to attribute change events of target defect tasks, changes in core task attributes on the server side can be detected in a timely manner, providing a trigger signal to initiate the attachment location synchronization process. By regenerating the corresponding update access path based on the attribute change event, the new storage location where attachments should be moved can be calculated based on the new attribute values, achieving a match between the path and the latest task ownership. By moving attachment files from the target access path to the update access path for storage, attachments can be automatically transferred from the old responsible person's folder to the new responsible person's folder, completing the tracking and distribution of attachment storage locations. These processes collectively enable the automatic migration of attachment locations as tasks progress, solving the problem of scattered attachment storage due to task transfer in traditional methods, and ensuring the centralization and consistency of attachment management.

[0066] In this embodiment of the application, file processing operations are performed on the attachment files corresponding to the target defect task based on the target access path, including: Step E1, in response to the state change event of the target defect task.

[0067] Specifically, a state change event refers to a change in the workflow state of a target defect task within a defect management system (such as a JIRA server), particularly a change to a final state such as closed, completed, or canceled (collectively referred to as a non-processing state). Response operations are executed by the system's rule processing module (which can also be combined with a separate cleanup thread). Its core implementation can also include two modes: event-driven mode and timed polling mode. Additionally, the response mechanism can include event filtering, for example, focusing only on events that change to a specific non-processing state while ignoring intermediate state changes; it can also buffer and batch process events to improve the efficiency of cleanup operations.

[0068] Step E2: Reacquire the third task status of the target defect task based on the status change event.

[0069] Specifically, the rule processing module, based on the target defect task identifier (such as task ID) carried in the state change event, initiates a query request to the defect management system (such as the JIRA server) to obtain the latest state information of the task from the server data source. This latest state is defined as the third task state. Unlike the first task state (local snapshot) and the second task state (last server state), the third task state is specifically obtained in response to this state change event and serves as the final basis for deciding whether to perform cleanup. The state change event itself (such as in a Webhook message) already contains a complete and reliable new state value, and the third task state can be obtained by directly parsing the event data, thereby reducing an additional API call; alternatively, a short-lived state cache can be maintained, and the server query is only executed when the state of the task in the cache does not match the event indication.

[0070] Step E3: When the third task status is non-processing, delete the attachment file corresponding to the target defect task in the shared storage space according to the target access path.

[0071] Specifically, the file system operation module parses the status of the third task and compares it with a preset list of non-processing statuses (e.g., closed, canceled, completed). If a match is found, the task's corresponding storage directory (i.e., the target access path, generated during task processing and potentially updated due to changes in responsibility) is located in the shared storage space based on the known task identifier (e.g., ticket number) of the target defective task and existing path generation rules. Then, a deletion operation is performed, recursively deleting all attachment files under that path, as well as the task number subfolder itself, thereby freeing up the storage space occupied by the task. The deletion operation can be designed with a security mechanism for delayed deletion or archiving to the recycle bin, and detailed deletion logs should be recorded. Simultaneously, before deletion, it should be verified that all files under that path belong to the task to prevent accidental deletion of other files.

[0072] By responding to state change events of the target defective task, the system can detect state transitions as the task lifecycle enters its final stage, providing an automated trigger for initiating the attachment cleanup process. By retrieving the third task status of the target defective task based on the state change event, the final status of the task can be confirmed from an authoritative server source, ensuring the accuracy of the cleanup judgment and preventing accidental deletion due to state synchronization delays. When the third task status is in a non-processing state, deleting the corresponding attachment files according to the target access path clears the attachment resources occupied by completed tasks in shared storage, achieving storage space reclamation. These processes collectively constitute automated attachment lifecycle management, solving the problem of storage space waste caused by reliance on manual cleanup.

[0073] In this embodiment of the application, the method further includes: detecting the remaining storage capacity and availability status of the shared storage space; when the shared storage space is unavailable or the remaining storage capacity is below a threshold, switching the root node of the access path to an alternative cloud storage path and sending an alarm notification.

[0074] Specifically, the shared storage space (i.e., the LAN shared disk or network-attached storage serving as the primary storage) is periodically monitored via the file system operation module or a dedicated monitoring thread. This monitoring involves two aspects: first, querying the remaining storage capacity (i.e., free disk space) of the storage volume using the operating system's API and comparing it to a preset threshold (e.g., less than 10% remaining space or less than 1GB); second, verifying the storage space's unavailability (e.g., network disconnection, lost permissions, or device failure) by attempting to access the root directory or creating test files. If either condition is met (unavailability or capacity below the threshold), a storage path switch is automatically triggered: the root node of all access paths in the global configuration (i.e., the basic path variable in the path template, such as {BasePath}) is dynamically replaced from the original shared storage path to a pre-configured backup cloud storage path. Simultaneously, an alert notification is sent to the administrator via integrated notification channels (e.g., email, SMS, or instant messaging API), including the trigger reason, timestamp, affected storage paths, and the executed switch action. The detection process can employ a gradual strategy (such as sending an alert when the capacity is close to the threshold), and during switching, it can ensure that ongoing file operations are completed or rolled back, and the alert notification can support a resending mechanism until confirmation.

[0075] This embodiment provides a defect attachment processing system. Figure 2 This is a structural block diagram of a defect attachment processing system according to an embodiment of the present invention, such as... Figure 2 As shown, the system includes: a server 10, an attachment management engine 20, a shared storage space 30, and user terminals 40; wherein, the attachment management engine 20 includes: a timed scheduling module 21, an interface module 22, a rule processing module 23, and a file system operation module 24; the shared storage space 30 includes: a root directory 31, a first user folder 32, a second user folder 33, and other user folders; the user terminals 40 include: a first user terminal 41, a second user terminal 42, and other user terminals; Server 10 is used to provide defect management services, store defect task data, status information and corresponding attachment files, and provide task query, status change notification and attachment download functions to external systems through application programming interface; Attachment management engine 20 is used to execute a defect attachment processing method, including: obtaining at least one target defect task in an unprocessed state in a user folder; generating a corresponding target access path for each target defect task in a shared storage space; and performing file processing operations on the attachment files corresponding to the target defect tasks based on the target access paths. Shared storage space 30 is used as a centralized network storage medium to provide a physical storage location accessible by permissions for the attachment files of all defective tasks; User terminal 40 is used to allow users to access their corresponding user folder in the shared storage space to process defect task attachments assigned to them without having to manually download them from the server.

[0076] In this embodiment, the attachment management engine 20 includes: a timed scheduling module 21, an interface module 22, a rule processing module 23, and a file system operation module 24; The timed scheduling module 21 is used to start or coordinate the execution cycle and timing of the defect attachment processing flow according to a preset time strategy or event triggering conditions. Interface module 22 is used to communicate with the server 10 and call its application programming interface to obtain a list of defective tasks, task details, status information and attachment file data; Rule processing module 23 is used for logical judgment and rule processing in the execution method, including: filtering target defect tasks, generating and verifying access paths, and determining the type of file processing operation to be performed based on task attributes or status changes; The file system operation module 24 is used to perform specific file-level operations on the shared storage space 30 according to the decision of the rule processing module 23, including: creating directories, downloading and storing files, moving files, deleting files, and querying file status; In this embodiment of the application, the shared storage space 30 includes: a root directory 31, a first user folder 32, a second user folder 33, and other user folders; The root directory 31 is used as the top-level starting path for storing all defect task attachments in the shared storage space 30; The first user folder 32, the second user folder 33, and other user folders are used to correspond to different rights and responsibilities. Subdirectories are created under them according to the task identifier to store the attachment files of the defect tasks they are responsible for, so as to realize the centralization and isolation of attachments by the person in charge. In this embodiment of the application, the first user terminal 41, the second user terminal 42, and other user terminals are used to allow users with different rights and responsibilities to connect to and operate their corresponding user folders in the shared storage space 30 through network file system protocols or shared access methods, so as to realize convenient access and processing of the attachments of the defect tasks they are responsible for.

[0077] This embodiment also provides a defect attachment processing device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0078] This embodiment provides a defective accessory processing device, such as... Figure 3 As shown, it includes: The acquisition module 31 is used to acquire at least one target defect task in the user folder that is in an unprocessed state; Generation module 32 is used to generate a corresponding target access path for each target defect task in the shared storage space; Execution module 33 is used to perform file processing operations on the attachment files corresponding to the target defect task based on the target access path.

[0079] In this embodiment of the application, the acquisition module 31 is specifically used to acquire at least one original defect task from the user folder, wherein the original defect task includes a task identifier and a first task status; detect whether there is a server task associated with the task identifier in the shared storage space; if there is no server task associated with the task identifier, then determine that the original defect task is a target defect task in an unprocessed state; or, if there is a server task associated with the task identifier, acquire the second task status of the server task, detect whether the first task status and the second task status are consistent, and if they are inconsistent, then determine that the original defect task is a target defect task in an unprocessed state.

[0080] In this embodiment of the application, the generation module 32 is specifically used to obtain attribute information of the target defect task, wherein the attribute information includes at least one of project identifier, authority identifier and task identifier; obtain the path configuration template of the shared storage space, and replace the variable placeholders of the path configuration template with the attribute information to generate the initial access path of the target defect task; verify whether the initial access path meets the preset access conditions, obtain the verification result, and adjust the initial access path based on the verification result to obtain the target access path.

[0081] In this embodiment of the application, the execution module 33 is specifically used to obtain the attachment file and attachment name corresponding to the target defect task; query in the shared storage space whether there is a pre-stored file with the same file name as the attachment name under the target access path; if there is no pre-stored file with the same attachment name, then store the attachment file corresponding to the target defect task to the shared storage space according to the target access path; or, if there is a pre-stored file with the same attachment name, then perform file processing operation on the attachment file corresponding to the target defect task based on the pre-stored file.

[0082] In this embodiment of the application, the execution module 33 is specifically used to calculate the first hash value of the pre-stored file and obtain the second hash value of the attachment file; compare the first hash value with the second hash value to obtain the comparison result; if the comparison result is that the first hash value and the second hash value are consistent, then terminate the file processing operation; or, if the comparison result is that the first hash value and the second hash value are inconsistent, then re-store the attachment file corresponding to the target defect task to the shared storage space according to the target access path to overwrite the pre-stored file.

[0083] In this embodiment, the execution module 33 is specifically used to respond to the attribute change event of the target defect task; regenerate the corresponding update access path for the target defect task in the shared storage space according to the attribute change event; and move the attachment file corresponding to the target defect task stored under the target access path to the update access path for storage.

[0084] In this embodiment of the application, the execution module 33 is specifically used to respond to the state change event of the target defect task; re-acquire the third task state of the target defect task according to the state change event; when the third task state is a non-processing state, delete the attachment file corresponding to the target defect task in the shared storage space according to the target access path.

[0085] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 4As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system).

[0086] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0087] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0088] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0089] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0090] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0091] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0092] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for processing defective attachments, characterized in that, The method includes: Retrieve at least one target defect task that is currently in an unprocessed state from the user folder; Generate a corresponding target access path for each of the target defect tasks in the shared storage space; Based on the target access path, file processing operations are performed on the attachment files corresponding to the target defect task.

2. The method according to claim 1, characterized in that, The step of obtaining at least one target defect task in the user folder that is in an unprocessed state includes: Obtain at least one original defect task from the user folder, wherein the original defect task includes a task identifier and a first task status; Detect whether there is a server task associated with the task identifier in the shared storage space; If there is no server task associated with the task identifier, the original defect task is determined to be a target defect task in an unprocessed state. Alternatively, if a server task is associated with the task identifier, the second task status of the server task is obtained, and it is checked whether the first task status and the second task status are consistent. If they are inconsistent, the original defect task is determined to be a target defect task in an unprocessed state.

3. The method according to claim 1, characterized in that, The step of generating a corresponding target access path for each target defect task in the shared storage space includes: Obtain the attribute information of the target defect task, wherein the attribute information includes at least one of project identifier, authority identifier, and task identifier; Obtain the path configuration template of the shared storage space, and replace the variable placeholders of the path configuration template with the attribute information to generate the initial access path of the target defect task; Verify whether the initial access path meets the preset access conditions, obtain the verification result, and adjust the initial access path based on the verification result to obtain the target access path.

4. The method according to claim 1, characterized in that, The step of performing file processing operations on the attachment files corresponding to the target defect task based on the target access path includes: Obtain the attachment file and attachment name corresponding to the target defect task; In the shared storage space, query whether there is a pre-stored file with the same file name as the attachment name under the target access path; If no pre-stored file with the same name as the attachment exists, the attachment file corresponding to the target defect task is stored in the shared storage space according to the target access path; or, if a pre-stored file with the same name as the attachment exists, file processing operations are performed on the attachment file corresponding to the target defect task based on the pre-stored file.

5. The method according to claim 4, characterized in that, The step of performing file processing operations on the attachment file corresponding to the target defect task based on the pre-stored file includes: Calculate the first hash value of the pre-stored file and obtain the second hash value of the attached file; The first hash value is compared with the second hash value to obtain the comparison result; If the comparison result shows that the first hash value and the second hash value are the same, the file processing operation is terminated; or, if the comparison result shows that the first hash value and the second hash value are not the same, the attachment file corresponding to the target defect task is re-stored in the shared storage space according to the target access path to overwrite the pre-stored file.

6. The method according to claim 1, characterized in that, The step of performing file processing operations on the attachment files corresponding to the target defect task based on the target access path includes: In response to an attribute change event of the target defect task; Based on the attribute change event, a corresponding update access path is regenerated in the shared storage space for the target defect task; Move the attachment files corresponding to the target defect task stored under the target access path to the update access path for storage.

7. The method according to claim 1, characterized in that, The step of performing file processing operations on the attachment files corresponding to the target defect task based on the target access path includes: In response to the state change event of the target defect task; The third task status of the target defect task is reacquired based on the state change event; When the third task is in a non-processing state, delete the attachment file corresponding to the target defect task in the shared storage space according to the target access path.

8. A defective accessory processing device, characterized in that, The device includes: The acquisition module is used to acquire at least one target defect task that is in an unprocessed state in the user folder; The generation module is used to generate a corresponding target access path for each of the target defect tasks in the shared storage space; The execution module is used to perform file processing operations on the attachment files corresponding to the target defect task based on the target access path.

9. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1 to 7.

Images