Added front end checks for variant curation rules

[danielreti]

Closes #47

Rules implemented (in order, ie whichever one is hit first is triggered) (invalid options are greyed out) If no flags => lof only if flowchart overridden => anything if no-read-data => uncertain only if reference-error => not lof only if mapping or genotype or inconsequential or resuce => uncertain, likelynot or not lof only if any other flag (not from the above list) and not custom flag => lof or likely lof or uncertain Easy to add more rules later

Selected verdicts which are then invalid by further flagging (eg lof was ticked as verdict and then no-read-data flag was selected) are cleared Added clear button to remove verdicts Mapping/genotype/inconsequential/rescue can only selected if at least one child is selected AND will be deselected if all children are later deselected Added tick or cross beside variants on assigned variants page depending on if the current curation follows the rules or not. This makes it easy to spot and recurate non-compliant curations. Should be effective for existing curations and all future curation will not be able to be saved as non-compliant.

[SamBryen]

This is awesome, thanks @danielreti!

[daniaki]

@danielreti

Nice work! I like the approach of splitting the verdict validation logic out into a separate function to handle future cases with ease. Unfortunately there's a bug and the first rule doesn't work for me when custom flags exist. I'd also like to pair program with you to clean up this solution a bit - there are some really good ideas in here that need a bit of refactoring to highlight the semantics behind the new moving parts and make it bit more human readable.

Apart from that, there are a number of eslint issues that need fixing to make the CI checks happy.

[daniaki]

@SamBryen If a child of Mapping/genotype/inconsequential/rescue etc is selected, should these parent flags be automatically selected?

[SamBryen]

@daniaki nope, it is up to the curator to decide if the child flags are enough to justify marking the parent flag as well. The parent flag should only be selectable if at least one child flag is selected though, as this provides more specific information about why the parent flag was selected. eg. a variant has low read depth, so the read depth flag is selected, but the curator thinks the variant is probably real anyway, so would not selected the genotype parent flag. If the read depth was so low that they thought it was a genotyping error, then they must click read depth first, before selecting the parent flag, so that everyone knows why it was considered a genotyping error. Thanks!

[daniaki]

@SamBryen Another question! Which verdicts are allowed if only custom flags are selected?

[SamBryen]

@daniaki just LoF. I don't want custom flags to impact these rules at all. We can always select "flow chart overridden" if exceptions come up. Cheers!