Some users here asked for a button to clear all current filters, which I guess is related to the feature you proposed, although much simpler.

Yes. I think keeping last filter is also useful, usually users don't want to list all case items in table, but see results of last filter applied.

A pin filter feature should help a lot too now with "clear all filters" button.

What would be the requirements for this?
There are many UI elements that add filters to result set. So one of the requirements, I imagine, is to show all these filters in a centralized location.
Additionally,

1. this manager must implement some way to add other kind of filters?
   1.1) What kind of additional filters? Query based I think would be one, and what others more? JavaScript based?
2. This manager must implement some way to save/persist these filters configuration?

I have some thoughts about item 2 to discuss: One could say that when you create a bookmark with the filtered items, the filter doesn't need to be persisted any more.

a) But saving the filters can help in understanding how that selection was made, beyond being useful to apply the same filter in other similar cases.
b) This saved filter could be exported and configured to automatically create bookmarks in other cases at processing time.

We can break down 2.a) and 2.b) in other 2 enhancement issues, and let them to latter roadmap than 4.2.

Hi @patrickdalla sorry for the delay here, I was busy with other things and I have a meeting soon...

There are many UI elements that add filters to result set. So one of the requirements, I imagine, is to show all these filters in a centralized location.

Yes that is the idea. To avoid memory usage issues, we should use BitSets. For Multicases, we could use a Map<caseID, BitSet> to save the filters for each case, since the item IDs will be repeated. ItemID class uses a lot of memory and I think should be avoided.

1. I think the manager could be used just to store last filters results and reaply/disable them, not to create new ones, for that user can use the existing FilterCombobox (for those Query based) and other UI components. So Javascript filter definition would be another different feature...
2. If it is used just to store last filter results, as I thought initially, this wouldn't be a need, but we can store filter results to appear if user close and reopens the case, but I think this is not a must, but would help.
   a) Hum, I see... But saving the Filter definition rule can be a bit difficult for some of them, like those from Metadata filtering panel, from the MapTab, GraphTab, TimelineTab...
   b) I we manage to save the filter definition rule for all kind of filters (they can be even case specific if they use fields or values - From/To for exemple in Graph - that exists just in the case), they may not work in other cases...

So I think we could start with just filter results management. Allow the user to apply set operations on the tracked BitSets results (union, intersection, subtraction) at first. Then we may improve to track the Filter definition rule later, what do you think?

A non trivial point is: when user reapply the Filter results using the Manager, should it be reflected in the original panel used to create the Filter? Maybe that would need the Filter definition rule... Or maybe not, Filter Manager saved "filters" could be seen as another different filter (that remember last filters results) and could be combined with current Filters applied in other panels... Or should the UI workflow be totally refactored so applied Filters are shown just in the filter Manager and current UI filtering components stop being painted as RED to warn a filter is being applied? Any more possible UI interaction approaches?

I think that restored filters should be reflected on the original panel.
I think that a some level of refactor is very useful and not so difficult.
We can define 2 upper level interfaces IFilterer(A UI component that creates filters) and IFilter. FilterManager would register IFilterer instances, which informs all defined filters.
When the saved filters state is restored, the corresponding filterers would be informed about the respective IFilter instances to be internally reflected also.

There are mainly 2 kinds of Filterers: one that provides a query to be added to the final query, and other kind the filters the resultset after it is returned by the lucene search.
Question: Should these differences be reflected to the user? Or should they be transparent?
I think that the description of the query filter should be the corresponding query text, what would already be a distinction point to the user.
I have not found any reason to evidence this difference in UI, but maybe you can think different.

As an initial stub: Would it be anything much different than this?

Question: Should these differences be reflected to the user? Or should they be transparent?
I think that the description of the query filter should be the corresponding query text, what would already be a distinction point to the user.
I have not found any reason to evidence this difference in UI, but maybe you can think different.

I think they ideally could be transparent to the user, but shouldn't cause any warm if the difference is noticed.

As an initial stub: Would it be anything much different than this?

Very cool!

A feature that, in my opinion, would be very useful is allowing the user to specify the boolean operator to combine current filters. Today AND is always used, but user may want to use OR, or maybe do some custom combination of existing filters results.

@lfcnassif , all of the filter panels does no expose the resulting bitset for now, right? So we need implement to make them expose these bitsets. Or am I missing something?

Althought for AND (intersection) filtering bitsets weren't needed, they seems to be important for OR (union).

@lfcnassif , all of the filter panels does no expose the resulting bitset for now, right? So we need implement to make them expose these bitsets. Or am I missing something?

Yes, I think some of them are not exposing the results, those Query based are not for sure. Actually we don't use BitSets yet to store filter results, we use arrays of ItemId, but I think we should switch to BitSets (or SparseBitSets) to avoid excessive memory usage. Because ids can repeat in multicases, possible we would need a Map<CaseId, BitSet> to store results, this would need some refactorings...

As I understood from above video, we could save different filter results coming from the same Filterer panel, very nice! This was a feature I thought a long ago, but forgot to say, so we are having similar ideas :-)

Some open questions to all devs: should each filter result be automatically saved? Or should we limit to last X filters to avoid memory issues? Or perhaps do not save automatically and expose some "Save Filter" button?

Let me know if I'm in the right way: Would it be the right sequence of filtering?

1. A UI Filterer element would "register" a filter.
   1.1) That specific filter would be applied to Match All Docs query, to create the corresponding "bitset".

2. When showing the resultset, it would be filtered against all registered and enabled filter bitsets

Is it?

Let me know if I'm in the right way: Would it be the right sequence of filtering?

1. A UI Filterer element would "register" a filter.
   1.1) That specific filter would be applied to Match All Docs query, to create the corresponding "bitset".
2. When showing the resultset, it would be filtered against all registered and enabled filter bitsets

Is it?

Makes sense. But I think it would change behavior at least of Metadata filter tab, since its results/filters today take into account just the result set currently being displayed, after all other filters were applied, not all case data (MatchAllDocsQuery). I have discussed this before with @tc-wleite in another issue, I think we didn't come up to a conclusion. I'll arrive at work after lunch and I can search for the discussion...

Maybe, to avoid methods to "register" the filter, it could be somewhat diferent:

1. A UI Filterer element would create internally an filter.

2. When showing the resultset, it would be filtered against all cached and enabled filter bitsets
   2.1) A specific filter would be applied to Match All Docs query, to create the corresponding "bitset", in its first usage.
   2.2) This bitset would be saved in a cache, for latter reuse.

Related issue: #1184

But with this feature, it won't be needed.

I have discussed this before with @tc-wleite in another issue

I didn't find it, maybe it was a private conversation. The idea was to change Metadata Filter behavior so it would always behave globally, on all case items, not just on current result set after applying other filters. Aggregating filters BitSets using AND would give the same result on main table. But the values for the selected property and counts in Metadata filter panel would change if we change its behavior, I'm not sure what behavior is better, maybe both have pros/cons.

I'm closing this since it is already integrated on master and will be released anyway in 4.2.0.