Specialized filters for portals

[robyngit]

In the query builder, a different value input is displayed depending on the filter type and the metadata field selected. For example, if authoritativeMN is selected, then the input for the search term value is a dropdown with a list of member nodes with logos:

See these issues for a list of other inputs that have been or will be implemented. We should use the same "special inputs" for the custom portal search filters.

Adapting the special inputs for use as custom portal search filters

The interfaces will need to be modified for use in the portal search filters. In the query builder, a user can keep adding search terms to the input:

But as a search filter, each time a user enters some text, it should be added to the list of "applied filters" instead:

We will also need to think about how to display each of these special inputs in the filter editor:

For example, for the annotation filter, we may want to display a preview of the tree widget, with an option to change the ontology or ontology sub-tree (see #1654).

Specifying which filter properties correspond to which interface

Which interface belongs to which filter type / field combo is configured for the query builder in the QueryRuleView:

https://github.com/NCEAS/metacatui/blob/504ba5d5b66fa22f052ebe4b4bb9a116910b2bd3/src/js/views/queryBuilder/QueryRuleView.js#L395-L510

For the custom search filters and filter editor, the FilterGroupView uses a switch statement to decide which interface should be used for a given filter type:

https://github.com/NCEAS/metacatui/blob/504ba5d5b66fa22f052ebe4b4bb9a116910b2bd3/src/js/views/filters/FilterGroupView.js#L98-L135

The filter properties that correspond to each interface should be specified in just one location in MetacatUI. One way to do this would be to create a view that selects and renders the right interface given a filter model and a context (query builder, catalog search, etc).

Related issues

This issue is closely related to #1653, #1687, and #1664