Variant details samples grid - IGV link per sample, loading that sample's BAM

[davmlaw]

🤖 Written by Claude

Split out of #49 (Variant Details improvements, 2018), where it was raised as:

• Make a second IGV link at the samples (for when you have no bams in any)
• Add IGV link to jump to sample bams (if they have it)

The rest of #49 is either done or not worth doing — see that issue.

What we have now

The variant details page has one IGV link, in the links box (vc_links.js:generateIgv → createIgvUrl(locus)).
With no BAM function it falls through to noBamsHere, so it's a plain goto — IGV jumps to the locus with
whatever tracks the user already had loaded. variant_details.html:63 has a stub getBams() returning [].

That covers the "no bams anywhere" case. What's missing is jumping to a sample's BAM from the samples grid.

Proposed

An IGV link per row in the variant details samples grid, which loads that sample's BAM(s) and goes to the locus —
i.e. the load op that create_igv_url already builds when it's handed files.

Only draw the link for rows that have a BAM. Most deployments have none (SampleFilePath is populated by seqauto,
or by hand), so a column of dead links would be noise. If no row in the grid has one, leave the column out entirely.

Data

SampleFilePath with file_type=BAM — Sample.get_bam_files() (snpdb/models/models_vcf.py:541), the same source
AnalysisNode.get_bams_dict() (analysis/models/nodes/analysis_node.py:302) uses for the analysis grid's IGV links.

One query for the samples we're already building rows for, added to _build_rows /
_row_to_json in snpdb/variant_sample_information.py. Rows are already scoped to samples the user can read, so
adding the path there doesn't widen what anyone can see.

Client

js/variant_sample_information.js — a render function per row calling the existing
open_igv_link(locus, bams) (js/grid.js:195). Path prefix rewriting (UserDataPrefix) and the "is IGV running?"
error modal are already handled inside create_igv_url / open_igv_link.

view_variant.html already ships window.ANALYSIS_SETTINGS.igv_data (base_url, genome, replace_dict), so nothing new
is needed there. The section also loads inside the analysis variant details tabs, where ANALYSIS_SETTINGS comes from
the analysis window — getAnalysisWindow() handles that already.

Gating

createIgvUrl returns null unless ANALYSIS_SETTINGS.show_igv_links is set, and the settings feature flag is
get_settings_form_features().igv_links_enabled (already passed to the page as igv_links_enabled,
variantopedia/views.py:839). Both should gate the column, on top of "some row has a BAM".

Note

The link takes the locus from the row's own genome build — the grid can hold rows from several builds (an allele's
variants), and IGV is pointed at one igv_genome at a time (igv_data['genome'] comes from the page's build).
Loading a BAM aligned to a different build than IGV's current genome is meaningless, so rows in other builds
should either be skipped or use that build's genome.