ifokkema
commented
5 years ago Hi JP,
TL;DR: I'm afraid that's not really feasible.
Full version: The current order for the variants/in_gene view is Gene, internal Transcript ID, internal variant ID, so whatever gets submitted first, is shown first. That is not a very useful order, but the variants/in_gene view is suffering from slowness when not logged in because it has to check all variant's statuses, and specifying a more useful order will likely greatly affect the speed of the view (but I'll look into sorting on the DNA field by default).
When sorting views on the DNA field, the order between different entries of the same variant is either undefined, or it's sorted on the internal ID. For gene-specific views, the DNA field is the default sorting column already, but in principle, we could add columns to this sorting algorithm. The VariantOnGenome/Genetic_origin column (the one you mention values of) is on by default, so could be an easy target. However, the values you mention (summery and classification records) are currently non-standard values that are used in the GV shared LOVD only. Additionally, sorting should not go alphabetically in your suggestion so we'll need a custom algorithm. But since these values are non-standard and might also change in the future, I'd be writing code specific for one LOVD installation, that aims at a moving target. Using logic like "does the variant have an individual attached?" as sorting logic won't help either, because both the summary records and the classification records apply to your definition of not representing a case, but an overall variant classification.
It might be better if the "summary record" appeared on top of the list of variant entries instead of the "classification record" - the summary record is distinct because it does not represent an actual patient/case - but an overall variant classification.
Example: https://databases.lovd.nl/shared/variants/in_gene?search_geneid=MLH1&search_VariantOnTranscript/DNA=c.454-13A%3EG