Skip to main content
Version: Next

Release Notes — v3.0.1

Release Date: TBD Previous Version: v3.0.0

Summary​

Version 3.0.1 introduces four new features focused on analysis integrity and configuration efficiency: archive dependency tracking with automatic reanalysis detection, a mix clone workflow for rapid configuration setup, EXCLUDE-status well filtering to prevent invalid data from entering analysis, and automatic reanalysis flagging when wells are edited or resolved. This release also includes targeted bug fixes for cross-run combined outcome handling, resolution priority assignment, LIMS status filtering logic, and several reporting and UI improvements.

New Features​

Archive Dependency Tracking​

The system now tracks which wells from previous runs are used during analysis of the current run. When a run is archived, all dependent runs are automatically flagged for reanalysis, ensuring that analysis results remain consistent even as the historical data set changes. Users are presented with a confirmation dialog explaining why reanalysis is recommended and can choose to reanalyze immediately or defer.

What users will see:

  • A confirmation modal stating "Results for wells in this run may be affected by recently archived runs" when opening a run that depends on recently archived data
  • The option to accept or defer reanalysis
  • An audit trail entry recording the reanalysis decision

Mix Clone​

A new Mix Clone feature allows users to duplicate an existing enabled mix's full configuration onto an unmapped (disabled) mix. This eliminates the need to manually re-enter targets, QC settings, rule mappings, combined outcomes, reporting groups, Westgard limits, and all other mix-level configuration. Target matching between source and destination mixes is performed automatically by dye identifier.

What users will see:

  • A new "Add Mixes" widget in the assay configuration screen
  • Selectors for the unmapped mix and the clone source
  • A toggle to include or exclude Westgard limit duplication
  • Control label inputs for the cloned mix's roles
  • A "Confirm Clone" button followed by the standard "Save" workflow

EXCLUDE LIMS Status Well Filtering​

Wells marked with the EXCLUDE LIMS status are now systematically removed from analysis across all applicable analyzer rules. This prevents excluded wells from producing false errors or influencing outcomes. Wells with RPT (Repeat) or RXT (Re-extract) statuses continue to participate in analysis normally. Archive dependency tracking is preserved for all wells regardless of LIMS status, ensuring the dependency graph remains complete.

Impact on results:

  • Wells with LIMS status EXCLUDE no longer appear in rule evaluations or contribute to error codes
  • RPT and RXT wells are unaffected and continue to participate in analysis
  • Six core analyzer rules (Repeat Well, IC Qualitative, IC Quantitative, Sample/BACT Check, BACT Result, and Adjacent Zika) implement this filtering

Edited and Resolved Wells Reanalysis​

The system now automatically detects when wells that other runs depend on are edited or resolved, and flags those dependent runs for reanalysis. For edited wells, only changes to the sample role (role alias) trigger reanalysis — other field changes such as accession number or extraction date do not. For resolved wells, any applied resolution code triggers the check. Both scenarios present the user with a confirmation dialog before proceeding.

What users will see:

  • A confirmation modal stating "Results for wells in this run may be affected by recently edited wells" or "recently resolved wells" when applicable
  • Distinct messages for edited versus resolved scenarios, so the reason for reanalysis is clear
  • The option to accept or defer reanalysis, with an audit trail entry recorded in either case

Bug Fixes​

  • LIMS status filtering logic corrected — The method that determines whether a well should be excluded from analysis previously contained a logic error that caused it to treat all wells with any LIMS status as excluded. This has been corrected so that only wells with status EXCLUDE are filtered.
  • Cross-run combined outcome guard — A guard has been added to prevent spurious combined outcome associations when the outcome is "Ignored." Without this guard, cross-run logic could create invalid well associations that triggered unnecessary reanalysis or, in some cases, caused analysis to hang indefinitely.
  • Resolution priority on new roles — Newly created roles via control label configuration now correctly receive the expected resolution priority value. Previously, the priority was not assigned on creation.
  • Ignore role excluded from trends — Wells with the "Ignore" role are no longer included in trends and daily outcomes reports, correcting a filtering omission.
  • Accession history multi-site isolation — The accession history section of the run print report now correctly filters by site, preventing wells from other sites from appearing in the history.

Reporting and UI Improvements​

  • Accession history in run print — Full accession history details, including outcome data, are now included in the run print report. Previously, this data was disabled.
  • LJ report table sorting — Sorting order in the Levey-Jennings report table is now consistent across multiple pages of results.
  • Trends report pagination — The pagination controls on the daily outcome frequencies table now remain visible (sticky) when scrolling through large data sets.
  • Dark-mode manage-result colors — Corrected color values in the manage-result widget when dark mode is active.

Known Issues​

For the full list of known issues and behavior differences, see the Known Issues Registry. Key items relevant to this release:

  • MIXMISS cross-run reanalysis (KI-005) may be mitigated by the new combined outcome association guard but has not been fully resolved in all edge cases.
  • Archive dependency tracking is a new feature; the dependency cache builds up gradually as runs are analyzed after upgrade. Runs analyzed before the upgrade will not have cached dependencies until they are reanalyzed.

Test Coverage​

This release has been validated with a comprehensive automated test suite: 2,496 Behat scenarios across API and browser tests, with a 97.6% pass rate. Remaining non-passing scenarios are attributed to documented known code issues and test infrastructure limitations, all tracked in the Known Issues Registry.

Tests are version-tagged (@V3_0_0, @V3_0_1) to support multi-tenant deployments where different client sites may run different software versions. The --target-version filter ensures the correct test set executes for each deployment.