Skip to content

Finalize variants in analysis

Description

Closes issues: LA-1454 Related issues:

Add a "finalize variant" function in ANALYSES/VARIANT mode. See issue description for further details.

TODO:

  • Improve collision logic Done

List of changes:

  • Adds a new button to UI on the classification card, for finalization of a single variant
  • "Undo re-evaluation" uses new button (new widget, <confirm-button>) to avoid accidental clicks.
  • A new endpoint was made in backend for each workflow type: actions/finalizeallele/. A lot of stuff that was done on actions/finalize/ is moved there.
  • @request_json(jsonschema=<schemafile.json>) is added to take in a jsonschema for validation. Relevant schemas for actions/finalizeallele/ are added, more should be added later.
  • Data sent to /actions/finalize/ has also changed a lot, to accommodate changes.
  • [Allele|Analysis]InterpretationSnapshot table is simplified, so presented_alleleassessment_id and presented_allelereport_id are now renamed to just alleleassessment_id and allelereport_id. The data in the old alleleassessment_id and allelereport_id columns are migrated into interpretationlog entries.
  • interpretationlog table has two new columns to hold information about created/updated alleleassessments/allelereports.
  • These two types of entries are added as info in the Work log in the UI.
  • Unused allelereports/ resource is removed.
  • Mark class 2 button is removed.

Notes to reviewer

Type of change

Application (affects UI or general functionality):

  • New feature
  • Bug fix
  • Improvement

Ops / admin / CI related only (not impacting users):

  • New feature
  • Bug fix
  • Improvement

Tests

General

  • Tests have been added that prove my fix is effective or that my feature works
  • Related tests have been modified/removed

Hypothesis testing:

  • Soak testing has been done
  • Distribution between positive / negative cases has been checked

Database

  • Includes changes to database schema
  • Includes necessary database migrations

Configuration

  • Includes changes to configuration
  • Includes configuration migration instructions in documentation

Merge checklist

  • Self-review of code performed
  • Feature review against specification (if applicable)
  • Need for documentation has been evaluated and, if necessary, updated
  • Code and implementation is reviewed by other core developer (all changes, inc. changes based on initial review)
Edited by Øyvind Evju

Merge request reports