Make it possible to use same index for several criteria and do this work together

[gbastien]

Hi @avoinea @alecghica

we have following use case :

• we use keywords (Subjects) for various semantic cases, for example "colour" and "size", so we have "red", "green", "orange", "big", "medium" and "small" as keywords available on an element, and this is indexed under "Subjects"
• to filter out this, we have 2 filters with custom vocabularies, one filter "colour" with "green/red/orange" as available check-boxes and one filter "size" with "big/medium/small" as available check-boxes

When doing this, it is possible to add such criteria in the interface, no problem, but when filtering, only last filter is taken into account, we can not get "red" elements "big", only "big" is taken into account because it uses same index "Subjects".

What I would like to adapt is in FacetedQueryHandler.criteria, instead updating the **query, if an index already exist in the **query, is to complete the **query with new values instead replacing existing values (and so do a AND between values).

Does that seem correct to you?

I would add documentation in the code and a test obviously.

Thank you!

Gauthier

[avoinea]

@gbastien This one is a more complex issue.

We have another use case of this, and this change will break it.
We use a hidden facet with default selected values in order to show by default only a subset of brains.
And then we add a visible facet for the same index and the user can filter more, but without being able to cross the boundaries.

[avoinea]

We still can find a solution for the visible facets. Thus you have:

c1: hidden
c2: visible
c3: visible

By default query c1
If c2 or c3 active: query c2 AND c3

[gbastien]

@avoinea

so today, when there are criteria for same index, hidden and not, the query is completed and the hidden criterion values are kept?

What I would like is to keep this for every visible or hidden criteria.

So we would have :

• hidden criteria query taken into account
• then visible criteria would come and complete the query, so you could not move out of boundaries as the query is completed and so "more precise".
  We have this behavior too of "base query" you can not get out of, then you complete it with other indexes.
  I think our usecases are the same.
  Gauthier