Description: Autofilter enables deselect items automatically when typing a search Steps to Reproduce: 1. Open attachment 147829 [details] 2. Select the drop down filter for column b 3. Deselect all (checkbox) 4. Search Meta -> all items will be checked again Actual Results: All unchecked checkboxes checked after search Expected Results: Probably not Reproducible: Always User Profile Reset: No Additional Info: Found in 7.1 and in 6.0
Please do not report when you yourself are not sure if a bug, this is not. Use Ask LO, as I already asked you.
I disagree. If something - even if working as designed - causes some inconvenience in its behaviour, it's OK to file it as a usability issue. Personally I second the idea that the filter probably should not change selection. But even if it's decided to not be an issue, it should be described why is it not, or pointed to another place with explanation. I don't see how AskLibO could help here: it's intended to answer the questions like "how do I ..."; this one is rather for UX team.
Because: if you type "border" it will filter 8 items, if you type "meta" it will select all because all are with "meta". So this works as it should. I close, but feel free to set New if there's an explanation what exactly is expected.
This is either very trivial and reporter didn't make a second check with different search, or I don't see something here.
Created attachment 162358 [details] Example file
Case 1 1. Open the attached file 2. Expand the filter 3. Uncheck all 4. Type B -> B selected 5. Hit backspace in the search field -> All selected Case 2 1. Deselect All 2. Check G (which you want the filter 3. Assume a very very long list. Search for B (which you want to check to; not the rest) Case 3 (the opposite 1. Deselect nothing 2. Assume a long list: Search G 3. Deselect G 4. Backspace the search field 5. Search B -> you want to deselect that one too So I still object against working as intended or being a triviality; it not how it should be, IMHO.. but lets wait for the opinion of the UX-department
Previous comment didn't say what's expected differently. I still do not see a bug on a pre-UX level, nor a point in asking for UX.
Filter is a means to shorten the list, not to select something. It's reasonable to use partial filter to only select part of what's visible; it's reasonable to filter several times to search for a(lise), then b(ob), then c(larice) to only check those three items from a long list. But each time you enter anything, your selection is destroyed. It's unusable in all but the simplest case when you type your filter precisely to only see what you want to select; even if you type one non-specific filtering, the selection it creates does not help, since user will still need to de-select items, so it could just as well not select anything.
So in short: using the filter must not modify any chechboxes in the list: neither in filtered away items, nor in the rest that is shown. What was checked before pressing a key, must be kept cheched; what was unchecked, must stay unchecked, no matter if it's shown or not. User may use buttons to select/unselect all; if needed, the buttons may have sisters to allow select/unselect all *visible* or all *everywhere*.
Comment 9 provides reasonable arguments for this change, nothing to add from UX POV. Search should limit the number of items in the checkbox list but not change any selection. We should also consider bug 55398 requesting a temporary on/off feature.
@Caolán Me in opportunistic mood : * As you're in the area anyhow for bug 134270 * It's a ui thing, and probably/ hopefully "easy" to solve (for people who know where too look) * Autofilter search being a part of the release notes already (speed improvement), but it still hard to use with this flaw around. So bit of bummer, as far i'm concerned. Of course, feel free to skip
Can this be added to https://bugs.documentfoundation.org/show_bug.cgi?id=133492 and duplicated?
(In reply to Timur from comment #12) > Can this be added to bug 133492 and duplicated? Sounds like a different topic. * this bug requests to remove the automatic per checkbox on/off function on search * bug 133492 requests some kind of Refresh interaction after data have changed * bug 55398 requests some kind of global on/off feature (without loosing the checkbox configuration)
re comment #11, not one for me. But a brief competitive comparison suggests that making the filter not auto-toggle on/off and instead require an explicit enter/return/activate in the search box to toggle on/off the shown rows (which would mean that enter in that search box no longer closes the dialog) is a plausible alternative implementation sc/source/ui/cctrl/checklistmenu.cxx "EdActivateHdl" is the activate handler for the search box, "EdModifyHdl" is the modify handler. A quick looks suggests that the ShowCheckEntry calls in there are toggling the rows on/off automatically if they match/don't match the filter. There is a complicated date mode too which needs to be tested if someone takes this on.
(In reply to Caolán McNamara from comment #14) Great - thanks Caolán! Would be a nice easy hack. > But a brief competitive comparison suggests > that making the filter not auto-toggle on/off and instead require an > explicit enter/return/activate in the search box to toggle on/off the shown > rows (which would mean that enter in that search box no longer closes the > dialog) is a plausible alternative implementation I suppose that it's useful to keep the best of the two worlds: the changes proposed in this issue do not exclude a special handling of Enter when typing the filter, so that in this specific case, *Enter pressed in the filter box* would reset it all, not the fact of typing characters into the box.
The current behaviour is perfect, so please do not change this - as a extensive spreadsheet user I am strongly against the proposed behaviour propsed by comment 0. Al an alternative, MSO has an option of "adding (the serached result) to the current selection" and "remove from current selection" which might be what you want, but anyway please do not change the default behaviour, please!
(In reply to Kevin Suo from comment #16) > The current behaviour is perfect, so please do not change this - as a > extensive spreadsheet user I am strongly against the proposed behaviour > propsed by comment 0. > > Al an alternative, MSO has an option of "adding (the serached result) to the > current selection" and "remove from current selection" which might be what > you want, but anyway please do not change the default behaviour, please! Happily to admit not being a heavy Calc user ;-). And surely not proper picture how they auto filter being used by everybody. Naive me: I want to select 5 items in a list of 200.. So opt for deselect all & selecting the required. Prefer of course also a counter example; which makes it easier to grasp why they current approach hitting they sweet spot.
You can customize the filter by clicking "Standard Filter..." in the drop down menu, which lets you add multiple items which you can join (e.g. "Summary->Contains->Triage" + OR + "Summary->Contains->3D") but limits you to 8 entries. Is this the behavior that is requested, and if so is it still a bug? Should there be a new bug to increase the "Standard Filter" number of entries?
As mentioned in another report recently, you don't use needinfo status like this.
(In reply to Kevin Suo from comment #16) > The current behaviour is perfect, so please do not change this - as a > extensive spreadsheet user I am strongly against the proposed behaviour > propsed by comment 0. > > Al an alternative, MSO has an option of "adding (the serached result) to the > current selection" and "remove from current selection" which might be what > you want, but anyway please do not change the default behaviour, please! I agree with Kevin here. When you write anything in filter field Autofilter select all corresponding items and it's a great behavior! If you want decrease a list of items then just write some more symbols in filter field
I am working on this one. Can I get a document with dates and autofilter, as Caolán said, there is some date handling, Having a document would be helpful.
(In reply to Sahil Gautam from comment #21) > I am working on this one. Please *carefully* read _all_ prior comments. I don't see an agreement about what should be the preferred solution, and in fact there are opposite POVs here. IMO, until a solution is clearly defined, the auto-filter behavior regarding the search box should not be modified, as any modification will disrupt usage (especially for older/experienced spreadsheet users).
Canceling easy hack status for now.
What I understood from reading the comments above is: * One group wants Autofilter to be the same, which is, You search something in the Searchbox, then you get a list, and in that list you select or deselect some items, and press OK. So that list will show up. (not the issue) * Other group says Autofilter doesn't remember which ones I selected or deselected, and clears the selection when the Searchbox is cleared. (*the problem*) We can have these both together. Current behaviour + Autofilter remembering any explicit checking/unchecking, even if the searchbox is cleared. (Current Behaviour + no automatic deselect/select)
(In reply to Sahil Gautam from comment #24) > We can have these both together. You cannot have the current behavior and a different behavior simultaneously. The details (such as what the [ENTER] key does, or where exactly the default focus is located when opening the autofilter) are key factors, especially for experienced users. The only way to provide such dual behavior would be to offer some kind of UX artifact for users to choose, or alternatively the effect of the [ENTER] key on the search box should have a specific (but clear) effect. There are different advantages in each of the behaviors (current vs. suggested), depending on the scenario / usage. As examples of the potential conflict, see comments 14, 15, 16. So, let's see if I got this correctly: when typing within the search box, if [ENTER] is pressed then the current (auto-selection) behavior is used; but if [ENTER] is not pressed then the selection of check boxes would be manual (and not automatically overridden by changing the content of the search box)? What would happen with the current behavior during the typing-in? Currently, the resulting items are auto-selected (or deselected) according to the evolution of the content of the search box, so the resulting list is modified while typing; it is not clear to me what would happen during the typing-in in the suggested "best of both worlds" behavior. I am just trying to make the desired result clear before introducing "surprising" changes.
We briefly discussed the patch in the design meeting. One option is to change "All" into "All Selected" with the downside of an additional click. The other is a checkbox "[x] Auto Select", making the UI a bit more heavy but provides most flexibility (and to keep the current workflow). The option is necessary if the search should combine <foo> AND <bar> - you search for <foo>, select all foo and search for <bar> and add-select the items.
Patch at https://gerrit.libreoffice.org/c/core/+/159737 Ady, what do you think of changing "All" to "All Shown" in the autofilter widget? Currently we autoselect the items that match the search term let's say, which makes searching for A AND additionally B impossible.
(In reply to Heiko Tietze from comment #27) > Patch at https://gerrit.libreoffice.org/c/core/+/159737 > > Ady, what do you think of changing "All" to "All Shown" in the autofilter > widget? Currently we autoselect the items that match the search term let's > say, which makes searching for A AND additionally B impossible. Regarding changing "All" to "All Shown", although I don't consider it really necessary, I would not oppose. It is also a more accurate description, because the autofilter list has a limit (IIRC) in the amount of shown values, whereas the actual amount of values could be higher. Regarding the modified behavior, I still have my serious doubts (and probably Kevin Suo has too, as per his comment 16), but I have not tested it yet. We (users) have to admit and acknowledge that the AutoFilter feature is aimed at relatively simplistic, intuitive and fast filtering, whereas there is a "real" Standard Filter feature for more complex filtering rules. Expecting the AutoFilter feature to answer to more (and more) complex filtering rules might (now/eventually) affect its core purpose in negative ways, although I indeed understand the appeal. I guess I'll have to wait and see how exactly this change affects my personal use of AutoFilter. Experienced/older users will notice it, one way or another – I hope it will be for the better.
I still have my doubts with the proposed solution. Currently we have a tri-state checkbox with auto-select on input. Typing "lorem" shows all content with this keyword, the checkbox "All" is indetermined allowing to select all or nothing. The UI is clear and easy to understand, yet lacks on the ability to combine search terms. If we change the control to "[/] Add Visible", typing "ipsum" could auto-add the result to the previous "lorem" but unchecking would probably apply to all items. This is not clear enough. The idea with a checkbox "[ ] Auto select" before the search term still fails here (and requires additional clicks). Turning it into "[ ] Add" ends up in a strange workflow where one has to select the checkbox first to get the intended result - otherwise all previous input would be lost. I can imagine some Google-ish/RegEx-like input where "lorem +ipsum" returns a combination (or one needs to quote to get the exact result). Question is whether users can deal with this flexibility. We may show the first results separately, maybe underneath the current. But in the end as control is missing to combine searches. Don't see how we get there without plastering the UI with more controls. Any good idea?
(In reply to Heiko Tietze from comment #29) > Turning it into "[ ] Add" ends up in a strange workflow where one > has to select the checkbox first to get the intended result - otherwise all > previous input would be lost. Having "[ ] Add" (or some alternative nomenclature) is at least respectful of the current behavior and workflow. A tooltip on it would add some clarity and allow for users to discover it and try/test its effect. Such setting would have to be remembered until the specific autofilter is canceled and it should be independent for each column/field of the whole autofilter set. To be clear, this is just a comment about it; I am not saying I am 100% convinced. Some brainstorming, not having thought about the following thoroughly-enough... A possible alternative would be to have an additional checkbox on the left of each value (OFF by default), located to the left of the current one: setting the additional check box ON [x] would "fix" the current status of the already-available check box on that value (leaving it grayed out), whether it would be ON or OFF. The new additional check box on each value would also remain independent of the current "All" and independent of the search box. The new additional check box would be cleared by a new upper ("Fix all" or equivalent) check box located to the left side of the current "All" filter. This is similar to the aforementioned "[ ] Add", but per-value. I guess both of these could be implemented. This provides additional flexibility for the possible different results of the filter, at the cost of more UI artifacts, screen area, and also (potentially) additional clicks for the new behavior (but not for the current behavior). This all is only a *brainstorming* idea (not having thought about it thoroughly-enough), not a suggestion. Clearly it would make the AutoFilter UI heavier and wider. I'm not sure it would be intuitive "as-is" - I'd have to see the resulting UI. Tooltips are essential. The default status and behavior should remain as the current one. Maybe the new additional check boxes (or whichever other alternative) should also remain hidden (or not included) in the Autofilter feature, only to be shown by some new additional new "Complex Autofilter" alternative, leaving the current Autofilter feature without these changes. Both should share the basic characteristics, in order to avoid branching code (with the maintenance consequences). Again, brainstorming only.
We discussed it again yesterday and the idea was born to go with a "sticky" workflow. We add a toggle button next to the "[/] All" checkbox that makes the current selection sticky (indicated by a disabled state and ideally also separated with a horizontal ruler). Those items wont be affected by any search. Everything else remains as it is. Workflow would be to search for "lor", which filters the list to "lorem, lorum, lorim" and have them checked, to press the sticky button which makes these items disabled, search for "ips" returning in addition to the sticky and disabled items "ipsum, ipsen, ipsan", all checked. It should be possible to untoogle the sticky button, which keeps the current result but enables all items. User could then deselect "lorim, ipsan", toggle sticky on again, and search for "dolor". Sounds flexible and easy to understand as well as simple to implement.
(In reply to Heiko Tietze from comment #31) Sigh. Could amyone please describe, how this convoluted workflow should be usable? And what would be wrong with a simple "filtering changes selection" checkbox instead?
Created attachment 191330 [details] old behaviour demonstration
Created attachment 191331 [details] Comparing the old behaviour to the new behaviour
Sahil committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d4c34206bcf64b94eac4f0761aeacc285e08af55 tdf#133836 Autofilter allow adding up members to the current selection It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Please review carefully the new functionality.