Additional advanced search options

[pwalsh]

Description

There are several useful search options that could be exposed to users of the UI. Some that have come up in user feedback include:

• filter by "ongoing"
• filter by "completed"
• filter by "has pubmed matches"
• filter by "has risk of bias data"
• filter by "has contributed documents (e.g. CSRs, PISs etc)"
• filter by "has X or more/less data sources" (quantity of data sources may be a useful indicator of the quality of trial info, and therefore useful to filter by data "richness")
• box the query by a date range, which is forcibly applied to add date fields
• filter by choosing from list of data sources (default is all data sources)

Tasks

• [ ] TBD

[pwalsh]

@benmeg @jessflem please add any other easy search options for the UI that you can think of.

[vitorbaptista]

Make sure those filters are useful for regular users, and not only ourselves. For instance, I don't see a use case for someone wanting to find trials with risk of bias data (in a smaller sense, the same could be argued for the trials with publications filter).

Each filter we add increases the UI complexity, so we should keep them to a minimum in my opinion.

[jessflem]

it would be great to be able to filter for trials by register if possible, and select/deselect unregistered trials (ones just found in pubmed).

[pwalsh]

@jessflem added as "filter by choosing from list of data sources (default is all data sources)"

[georgiana-b]

@pwalsh What do you mean by:

• filter by "has pubmed matches"

Wouldn't this be covered by filter by choosing from list of data sources (default is all data sources) by choosing pubmed?

Please also explain what you mean by:

• box the query by a date range, which is forcibly applied to add date fields

[pwalsh]

@georgiana-b

on point one, I guess it would be covered, it was added after (https://github.com/opentrials/opentrials/issues/589#issuecomment-265364565)

on point two - allow the user to enter a date range, and have it apply to any and all date fields in the records being queried.

[vitorbaptista]

@pwalsh What's the use case of this date range behaviour? It sounds like it'll be difficult to communicate what this filter does.

[georgiana-b]

Besides lack of consensus on the specs, this requires some changes to the index that depend on the outcome of #647 so I'll block this until #647 gets sorted.

It's worth mentioning that almost all of these queries can easily be done without additional logic in the UI if we enable query strings in the Explorer [#288]. Therefore, I think it would be more practical to leave this aside until #288 is solved and then add functionality in the UI only for the queries requested here that are not covered by query strings.

[pwalsh]

@vitorbaptista use case for dates comes from @Bengoldacre

[pwalsh]

@vitorbaptista why is this in blocked?

[vitorbaptista]

@pwalsh the block explanation is on https://github.com/opentrials/opentrials/issues/589#issuecomment-274270156. I disagree that it should be blocked on #647, as we can query the data even if it wasn't explicitly included in the ElasticSearch mappings, so I'm unblocking this.

My main concern with this task is to avoid having too many filters, as it can get messy with our current search UI. Some of the queries feel very specific to our use case (like "has risk of bias data"), and could be done when we enable query strings (#288), so I'd rather not add those explicitly to the UI.

This is something that should come out of the analysis of this task.