Created attachment 97389 [details] The example document. After sorting some lines in a spreadsheet which has a autofilter set, the autofilter gets lost. The expected behaviour is, that sorting lines should *not* affect the autofilters. Steps to reproduce: 1. Open the attached document with a set of data and a autofilter applied on the captions. 2. Select some (or all) of the example data records. 3. Select "Data" -> "Sort..." on the menu. 4. The autofilter arrows already disappear when the sorting-options-dialog is opened. If you now click "OK", the filters are lost. If you click "Cancel" the autofilters re-appear. (see screenshots attached) Tested with LO 3.4.5, 4.2.2 and 4.3.3 on Windows XP, Server 2003 and Windows 7 with always the same behaviour.
Created attachment 97390 [details] A screenshot of the autofilters *before* sorting.
Created attachment 97391 [details] A screenshot of the autofilters while the dialog is shown.
Created attachment 97392 [details] A screenshot of the autofilters *after* sorting.
Hi, why do you want to apply the Sort function when it's already part of the Autofilter function. You use the first one to only sort and the second one to sort and filter, for me it works as it is supposed to. Set as worksforme - Sophie
Hi Sophie, > why do you want to apply the Sort function when it's already part of the > Autofilter function. You use the first one to only sort and the second one > to sort and filter, for me it works as it is supposed to. Set as worksforme What you describe is a workaround that prevents the error from occuring by changing the way to operate the data. This is not a solution to the described problem. Why your suggestion is NOT the same as the intended workflow: 1. imagine a list of lets say 10.000 lines that are not sorted (or may be sorted a special way you dont know) 2. the unaffected rows (the ones that are not selected by the filter) must stay at their positions How would you meet these requirements with your strategy? Can you reproduce the reported behaviour with the workflow described (filter first, sort second)? Do you think that the current behaviour is expected by the user and should remain unchanged?
Does scrolling out and scrolling back in to refresh painting make the autofilter buttons re-appear? I don't see this on Linux. Perhaps this is Windows only problem.
(In reply to comment #6) > Does scrolling out and scrolling back in to refresh painting make the > autofilter buttons re-appear? No. Still after scrolling the Autofilter is missing. > I don't see this on Linux. Perhaps this is Windows only problem. It seems as if the filter is completely deleted - not only a display problem.
Created attachment 98574 [details] Screenshot without the issue I can't reproduce the issue with: Win7x64Ultimate Version: 4.2.3.3 Build ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0 I think it's needed test resetting the user profile, to discard it. https://wiki.documentfoundation.org/UserProfile#Windows
Can not reproduce. Windows 7 sp1, 64-bit en-US Open the sample .ODS document with: Version: 4.1.5.2 Build ID: a02f36998a4af5e2f9fbec2b7e9f70a8b0bc934 Version: 4.2.2.1 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f Version: 4.3.0.0.alpha1+ Build ID: 0b03f7ed575838f90e6b1ebec3538a3a214f81fb TinderBox: Win-x86@39, Branch:master, Time: 2014-04-30_01:30:46 In all versions--the Autofilter column attributes as set DO NOT DISAPPEAR when the Data -> Sort menu selection is made. Also if on the Options tab of the Sort panel, the "Range contains column labels" is unchecked, the C1 - C5 columns are included in the sort--but their AutoFilter setting remains unchanged. I do notice though that in the attached screen clip--attachment 97391 [details]--with the Sort dialog open (and AutoFilter arrow button missing from the columns) that the Sort key 1 (Sortierschussel 1) is showing Column A (Spalte A). That could be an issue of some sort, because with all builds I've tested the Sort dialog shows the expected "Sort key 1" as "C1" the column label. Only if I deselect the "Range contains column labels" on the option tab will it show the "Column A" but the resulting sort moves the C1 - C5 row down adjacent to the row starting with "c".
On the screenshots 97390,97391 a 97392, one can see that rows 2:6 are selected. I can reproduce the bug with 4.1.5.3 and Version: 4.3.0.0.alpha0+ Build ID: 73ecb924379b8e665ee94235a353403c5d29eae6 TinderBox: Win-x86@39, Branch:master, Time: 2014-04-13_14:09:42 In both case, autofilter disappear when openning the Data > Sort dialog. But only when selecting an area/range who don't meet the Autofilter area. (A1:E6) Not reproduce while selecting A1:E6 (with mouse or Ctrl+*) or without any selection (focus on a cell of the area).
OK, now I can appreciate the issue. Issue is the selection being filtered and sorted. Missed it because the default sort applies to occupied rows of cells on the entire sheet, including the row of column labels that holds the AutoFilter buttons. It works correctly if the entire table is selected for sort. But, if using AutoFilter to hide rows, if a sort is then applied against only selected rows that are showing, the rows hidden by AutoFilter action stay hidden but during the sort the AutoFilter button for each colunm is turned off including the marker (blue) identifying which columns AutoFilter has been applied. Losing that filter state, while rows/columns are still hidden, can not be recovered. So you must re-enable the AutoFilter and select the All check box on any column to bring up all records and get back to a known state with all records (post sort) showing. The hidden data is sorted, as the sort applies to the entire selected range including rows that are hidden, but with AutoFilter state details being cleared--you can not selectively expose the hidden rows. Disruptive of works flows. That is what is wrong, losing the state of the applied AutoFilter(s). Rather it should be retained and restored for use after the sort operation completes. Confirming and setting to NEW.
Also affecting in 3.6 builds. It is handled a bit different in AOO builds, so believe there has been some LO work on the AutoFilter functionality that is resulting in clearing the button state for the filters.
*** Bug 80502 has been marked as a duplicate of this bug. ***
still reproducible under Win8.1 x64 using 4.5.0.0.alpha0+ Build ID: 6b096f273ac9d7bbe93d2cb083958b3a04866d73 TinderBox: Win-x86@42, Branch:master, Time: 2014-12-04_22:57:23 moving this to mab4.3 list since 4.2.x is EOL
Note that this happens only if only the data excluding the header row with the Autofilter buttons is selected, or if only part of the data or an entire column is selected (which brings up the Sort Range extension dialog), not if nothing or the entire data range including the header row is selected.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8eadeb91cde9709f006e8c5e19e98bff44dbd177 Resolves: tdf#77479 do not reset AutoFilter range for temporary operations It will be available in 5.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e0ca73123afdfa0a6891971de1b714273a889bfd uitest for bug tdf#77479 It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The test exist, set status to Verified.