mine filters - refactor to use pathquery

[yochannah]

We would like to create a webservice to allow mine admins to explicitly state which filters will be available in the tool for their mine. Right now our filters are hard-coded to certain functions. This won't scale well for other InterMines - instead, we should consider something like this:

{
  mineUrl: "http://www.kittenmine.com/kittenmine" //I think URL is probably the safest way to uniquely identify a mine
  customFilters: [{
      filterQuery: {
        "constraintLogic": "A and B",
        "from": "Gene",
        "select": [
          "alleles.clinicalSignificance"
        ],
        "orderBy": [{
          "path": "alleles.clinicalSignificance",
          "direction": "ASC"
        }],
        "where": [{
            "path": "alleles.type",
            "op": "=",
            "value": "XXX",
            "code": "A"
          },
          {
            "path": "alleles.clinicalSignificance",
            "op": "=",
            "value": "YYY",
            "code": "B"
          }
        ]
      },
      filterName: "CLINVAR"
    },
    {
      filterQuery: {
        "constraintLogic": "A and B",
        "from": "Gene",
        "select": [
          "alleles.clinicalSignificance"
        ],
        "orderBy": [{
          "path": "alleles.clinicalSignificance",
          "direction": "ASC"
        }],
        "where": [{
            "path": "alleles.type",
            "op": "=",
            "value": "XXX",
            "code": "A"
          },
          {
            "path": "alleles.clinicalSignificance",
            "op": "=",
            "value": "YYY",
            "code": "B"
          }
        ]
      },
      filterName: "ClinVar"
    }, {
      filterQuery: {
        "from": "Gene",
        "select": [
          "diseases.name"
        ],
        "orderBy": [{
          "path": "diseases.name",
          "direction": "ASC"
        }]
      },
  "where": [
    {
      "path": "diseases.name",
      "op": "=",
      "value": "ZZZ",
      "code": "A"
    }
  ]
    },
    filterName: "Diseases"
  ]
}

[yochannah]

Tagging @AdrianBZG and @julie-sullivan for comments as I may have missed something

[yochannah]

We also need to consider whether different classes need different filters configured. I think they probably do.

[AdrianBZG]

@yochannah @julie-sullivan I was thinking about an idea relating this issue with #8 :

What if on the example JSON with the pathquery for each filter, we use the ""from": "Gene"," keys (from keys) to create dinamically the views buttons on the top, allowing the person configuring the service to add or remove classes just by creating an specific filter for such class. So it will work like this:

• By default, the same thing, we have 2 classes (Genes and Proteins) + the 4 default filters. This always like that.
• The user can add for instance a filter applied to Gene view in the Json, so the tool will just add that filter to the sidebar when the user is in that particular view.
• The user also can add a filter applied to Substitution (from: Substitution) in the Json, the tool will add to the top a Substitution view button, and when the user goes to that view, the 4 default filters plus this other filter will be shown.

What do you think?

[yochannah]

@AdrianBZG I think this sounds good (dynamically configured from json sounds about right lol) but I'm not entirely sure I understand. could you elaborate or provide another example? (sorry!)