View Issue Details

IDProjectCategoryView StatusLast Update
0018257MMW 5Main Panelpublic2023-04-12 09:26
Reporterlowlander Assigned To 
Status resolvedResolutionreopened 
Product Version5.0.2 
Target Version5.2Fixed in Version5.0.4 
Summary0018257: Filters persist when changing nodes
DescriptionWhen setting a Filter it persists when changing nodes within the Collection. This can be confusing as there is little feedback that the newly selected node is also being filtered.
Steps To ReproduceA) Keep current behavior where Filter is applied to any node within the Collection until user removes Filter, but have the Filter showing within the Filelisting itself. Currently it only shows in the Breadcrumbs that a Filter is active which is easily missed.

B) Have Filter disabled as soon as user navigates away from node that had Filter applied. This requires user to set Filter again in new node. The affect of this depends on how users use Filter. It may simply be used as a more advanced Contextual Search within the node and it is rarely used between different nodes.

C) Have it not applied to certain nodes when coming from a Filtered node. Perhaps it makes little sense to have Filters persist between Files to Edit nodes.
TagsNo tags attached.
Fixed in build2664


related to 0018909 closedLudek Recursive button on Toolbar is global (?) 
related to 0018494 feedbackrusty Return the ALL leaf to Folder and Location nodes 
related to 0019393 closedLudek Filters are not restored correctly when MM is closed on the second tab 



2021-10-12 16:58

administrator   ~0065131

Have any users complained about this? I find this useful (even across nodes). For instance:
- I'll set a filter for Rating > **** and then navigate across nodes
- I'll edit tracks for Rating is unknown OR Artist is unknown OR Album Artist is unknown
In both cases, I appreciate the filter persisting


2021-10-12 20:38

developer   ~0065141

No, I came across this when using Files to Edit and wondering why files are missing. For now solution A may be good enough (ie. make it more visible the view is filtered).


2022-04-21 22:27

administrator   ~0067667

I suspect that the root issue is that filter status isn't obvious is because it doesn't persist in a consistent manner which can result in user expectations not being met. More specifically:
- When switching nodes within a Collection, the filter persists
- When switching to the parent node of a Collection, the filter is disabled e.g. Collection A subnode (fliter) --> Collection A --> Collection A subnode results in the filter becoming disabled!
- When Switching from Collection A subnodes that have the filter enabled to Collection B subnodes that don't have it enabled and then back to Collection A subnodes, then the filter is disabled!

I'm not certain what the optimal behavior is, but it would seem that one of the following would probably make the most sense:
A) Always persist filter status within all subnodes of a Collection (i.e. switching to the Collection node or any other node shouldn't affect whether it persists for Collection A subnodes.
B) Always persist filter status within a Collection and its subnodes. This seems like the most obvious approach, except that filtering is disabled in top-level Collection nodes largely because they're intended to show all content.
C) Make filter persistence Global to all Collection subnodes. This would work similarly to the 'Recursive mode' toggle that's adjacent to it.
D) Never persist filters. I think that this would be unexpected.

I lean towards A) but would appreciate feedback.


2022-05-02 15:15

administrator   ~0067922

Note: In 0018909 the 'Recursive' functionality was set to persist on a per Tab basis. I'm still uncertain what the optimal behavior is, but I would suggest that persistent of Filters and Recursiveness should persist in the same manner. i.e. if recursiveness is persisted per Tab, the same approach should be taken for filters.


2022-06-06 20:13

developer   ~0068442

Last edited: 2022-06-06 20:18

OK, I think that there are different issues to address:

1) The LowLander's objection that after changing a node it is not obvious that filter is still active
=> it is indicated on the toolbar, but for first time user often not clear

2) There is inconsitency when the filter is discarded as currently different combinations of node+view supports (or doesn't support) the filtering.
e.g. changing from
Music > Albums [Grid] > Filter: Rating >= 3 stars
Music [List] > Filter: Rating >= 3 stars
keeps the filter (as List view supports filtering)
changing from
Music > Albums [Grid] > Filter: Rating >= 3 stars
Music [Browser]
discards the filter (as Browser view does not support filtering)

I see two possibilities:

Solution A)
Discard filter whenever a node is changed as Lowlnader originally suggested.
Pros: Solves item 1) above
Cons: User needs to use 'Recently used' filters to quickly re-enable it for the other node/view

Solution B)
Always keep the filter for all nodes and collections until it is manually discarded (probably per tab basic like the 'Recursive' option for consistency)
Pros: No need to re-enable the filter after node change
Cons: Does not solve 1) above, i.e. is unclear whether the filter is active and how to discard it
This could be solved by adding [^] button to the rules to hide them and keep the rules visible even after node change until user clicks [^] button to hide it manually.


2022-06-06 20:16

developer   ~0068443

FYI: By the [^] button I mean the "Hide editor" button that is currently available for auto-playlists:
image.png (11,334 bytes)   
image.png (11,334 bytes)   


2022-09-14 20:29

administrator   ~0069277

Solution B) seems cleanest to me.

In order to make it clearer that a filter is active & clearer how to close it, how about modifying breadcrumbs to:
Collection> Node A > ChildNode B ([filterIcon] Rating > 3 stars [x])

Same approach can be used with recursive functionality:
Location > Node A > ChildNode B (All [x])


2022-09-15 09:33

developer   ~0069283

Last edited: 2022-09-15 09:36

The discard button on the breadscrumbs is already there,
I guess that the confusion raised by LowLander was that changing the node auto-collapses the rules and user can easily overlook the filter indication on the breadscrumbs.
Therefore I suggested to add the new "collapse" button and the rules would not by auto-collapsed anymore (on node change), but remains visible until user manually collapses it.
This should eliminate the confusion raised by LowLander.
image-2.png (18,879 bytes)   
image-2.png (18,879 bytes)   


2022-09-15 14:41

administrator   ~0069291

Agreed--adding a '^' to collapse the filter editing would make it easier to understand how to hide the filter editing controls. It's not perfect since the controls are unrelated--windowing controls should somehow be distinguished from functional controls (we have another example of this when an auto-playlist is edited and '^' 'x' displays). Perhaps moving the '+' to the row below?

The issues that the proposal at 0018257:0069277 addresses are that:
- It's not clear when a filter is enabled ( in A > B > C > D , 'D' just looks like another node. The proposal is to make filters look different and more representative of what they are).
- It's not clear how to disable a filter (most users don't realize that the filter icon with an 'x' can be used to close the filter--it just looks like all the other A > B > C > D breadcrumb nodes)
- It unifies the mechanisms for enabling/disabling filters/recursive modes


2022-09-19 19:47

developer   ~0069376

OK, I added the collapse button on the right in order to not mix with the (+) button on the left.

=> fixed in


2022-09-22 23:17

developer   ~0069493

Verified 2664

Pleas eclose after confirm Ui placement


2022-09-22 23:17

developer   ~0069494

image-3.png (12,199 bytes)   
image-3.png (12,199 bytes)   


2022-09-23 01:49

administrator   ~0069497

The 'Collapse' button works well, and positioning seems fine. BUT:
a) should the filter button continue to display once a filter is enabled?
b) clicking the Collection node still disables the filter. Is that intentional (that wasn't discussed in solution B), but perhaps you decided it's preferred to have this exception)?

Test note: The current fix doesn't address the following related but different issues and should be documented elsewhere before the bug is closed:
- It's not clear when a filter is enabled ( in A > B > C > D , 'D' just looks like another node).
- It's not clear how to disable a filter (most users don't realize that the filter icon with an 'x' can be used to close the filter since it just looks like all the other A > B > C > D breadcrumb nodes)
- Recursive mode is a similar type of function, but works differently (via a Toggle). It would make sense that it works similarly to Filters.

Possible approach that addresses these issues:
Filters: Collection> Node A > ChildNode B ([filterIcon] Rating > 3 stars [x])
Recursive mode: Location > Node A > ChildNode B (All [x])


2022-09-23 19:04

developer   ~0069513

Last edited: 2022-09-23 19:26

a) I think that yes, it should continue to display because just enabling the filter adds no rules, so the filter is still empty and clicking it again hides the filter editor.
i.e. it has always been a toggle and disappearing the filter icon upon clicking would rather looks like a bug/regression.
EDIT: See my comments section [ANOTHER IDEA] below...

b) Yes, changing from
Music > Albums [Grid] > Filter: Rating >= 3 stars
Music [Browser]
discards the filter (as Browser view does not support filtering)
=> this has been always the case and the filter has been always active just for the selected collection (as originally suggested elsewhere in Mantis)

We could either solve by introducing solution A (rather than B) -- 0018257:0068442
or leave it as is (espacially as it is more obvious whether the filter is active or not dur to solution B)

- It's not clear when a filter is enabled ( in A > B > C > D , 'D' just looks like another node).
=> I don't understand, what's unclear here? I think that the funnel icon and the rules next to the icon are clear enough to indicate that the filter is active?
EDIT: See my comments section [ANOTHER IDEA] below...

It's not clear how to disable a filter (most users don't realize that the filter icon with an 'x' can be used to close the filter since it just looks like all the other A > B > C > D breadcrumb nodes)
I think that the current discard filter icon is quite clear and it has the "Cancel filter" tooltip.
We could change it to '[filterIcon] Rating > 3 stars [x]' but the problem is that once there are more rules then the rules text gets long and the [x] button would get way much on the right...
EDIT: I think the [ANOTHER IDEA] below could solve it together with item a)

[ANOTHER IDEA] : Currently the funnel icon on the toolbar is toggle between [show editor / hide editor].
What about chaning the toggle to [show editor / discard filter] ?
The rationale is that we have introduced the collapse [^] button for hiding the editor already in 5.0.4


2022-09-23 19:31

developer   ~0069517

Last edited: 2022-09-23 19:31

We just might want to move the collapse button below the discard button toggle like this:
image-4.png (10,418 bytes)   
image-4.png (10,418 bytes)   


2022-09-23 21:25

administrator   ~0069521

Re. a) and b): OK (no additional changes needed).

Re. the following items (which aren't urgent--ie. they're post 5.0.4):
i) It's not clear when a filter (or recursion) is enabled: what I mean is that all breadcrumbs entries represent nodes in the tree, except for filters and recursion which are different--but the breadcrumb doesn't display them any differently. So at first glance, when looking at the breadcrumbs, it's not obvious that either of these are enabled.
ii) It's not clear how to disable a filter: what I mean is that as described above, filter breadcrumb icons 'look' like they would take the user to a node. Yes, it has an 'x' next to the filter icon, but it's tiny and not obviously different than other breadcrumb nodes.

Re. the 'Another idea': That approach makes filters and recursion work similarly, which is good, and addresses issue ii) . On the other hand:
- it doesn't address issue i)
- It would make it unclear how to edit a filter that's enabled (i.e. when a filter is enabled users need to be able to edit it and/or disable it and iiuc this substitutes one for the other).


2023-04-12 09:25

developer   ~0071489

Last edited: 2023-04-12 09:26

I think that with the current implementation (with the rules editor staying open until collapsed by user) it is clear enough how to discard/disable the rules (or close the editor)...

So I would just leave it as is...