Created attachment 118175 [details] Misfiltering file I have a file with a list in varios merged cells, and when a try to filter, it ask for the name to use, and is ok, but when you display the filter list, only show the "Empty" and the value of a cell out of the range with the merged cell. It may be very more symple in the attached file.
Created attachment 118180 [details] Sample modified Hi @Emerson, thanks for reporting. Taking a look, the filter button is for the last column in the merged range. You can see better selecting Standard filter where you can select the proper column for the filter. I'm not sure really a bug, because all columns are part of the filter. Perhaps it could be a request for enhancement, that in merged cells the filter of the left cell was showed. But then it also must be dependant of the language, LTR or RTL. I have done a little modification in your file. Adding a new row just below the header filter row. Copying the titles and set up this new row as filter header. Group the row with [F12] Menu/Data/Group and outline, so clicking on the minis it can be hide or when is hide clicking on the plus can be showed, if you can see it there is an option in View Calc options. So it's possible to select as you can, avoiding to print the filter row. And adding a blank row before subtotals row, we can avoid the filter including it.
Helo, may be I can not show my point. In the file "Misfiltering file", I hope that when I click on each column it show me the list whit the elements in the column, but the filter only work whit the last one of the Columns. If you select "All items" in the last column, the other filter don't show all the elements in the respective column, then you only can filter the range by the last one. I hope the filter work in every column as it work when you don't have merged cells.
Now I watch your modification and it is exactly what suppose not to do, why you have to use unmerged cells to filter a range whit merged cells? I really think it is a bug, and unfortunately (for me) I'm only a user and can not help the team to fix it.
Change to unconfirmed, so other person can test it.
Created attachment 118298 [details] Filtering Cells but in rows The past two files was with merged cells between 2 or more columns, but in this new file, the merged cells are in the same column. Indeed, if you merged cells in the same column and then apply the filter and you select to hide one group of merged cell, identifies with a number in the file, Column "A", it only hide the first row of the group. Win 8.1 LO 5.0.0.5; Ubuntu 14.04 LO 5.0.0.5
I think it has no relation, because in the sample merged cells are data cells no title cells.
(In reply to m.a.riosv from comment #6) > I think it has no relation, because in the sample merged cells are data > cells no title cells. Hello, please, can you explain just a little more your point, cause precisely, the problem is with the data cells when they are merged, does not matter if are titles or not. 1. The first files are whit cells merged between columns, titler or not, if you want to filter, all data are bad shown. 2. The second is whit cells merged in the same column (only rows), the data are well shown, but when you select a value to filter, only show or hide (it depends what you select) the very first row of the merged range, and the other rows that share the merged value are still shown by the filter. Please apologies for my poor English, it is not my native language, It is the beautiful Spanish ;)
Created attachment 118736 [details] simple test case Reproducible with 5.0.1.2 ID build: 81898c9f5c0d43f3473ba111d7b351050be20261, win7 Works as reporter wants in Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89), regression
not bibisectable with bibisect-win32-5.0. git checkout oldest: Version: 4.5.0.0.alpha0+ Build ID: 57d6b92b69a31260dea0d84fcd1fc5866ada7adb contains the bug
reproducible with bibisect-44max$ git checkout oldest Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
(In reply to raal from comment #8) > Created attachment 118736 [details] > simple test case > bibisect-43all: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=a1ac2538e9b287444500618ab4d2f0f06c25cf34..19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 /bibisect-43all$ git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327 # bad: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e git bisect bad 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02 # good: [51b63dca7427db64929ae1885d7cf1cc7eb0ba28] source-hash-806d18ae7b8c241fe90e49d3d370306769c50a10 git bisect good 51b63dca7427db64929ae1885d7cf1cc7eb0ba28 # bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019 # bad: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73 git bisect bad 79e02001f27d33b3b478324ab6fba5683413b4d9 # good: [183a576d94de9a9439d580c8b81f335ab57cdbdc] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef git bisect good 183a576d94de9a9439d580c8b81f335ab57cdbdc # bad: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7 git bisect bad a67b874d60de1f1a44bef57a53a7b8a84db0ba58 # good: [7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189] source-hash-a1ac2538e9b287444500618ab4d2f0f06c25cf34 git bisect good 7fd8bdb3b18f50ea0adbc0a5e611f6a844b23189 # first bad commit: [a67b874d60de1f1a44bef57a53a7b8a84db0ba58] source-hash-19f4ebd8a54da0ae03b9cc8481613e5cd20ee1e7
Migrating Whiteboard tags to Keywords: (bibisected)
Regression introduced by author Jian Fang Zhang <zhangjf@apache.org> 2012-06-21 07:19:34 (GMT) committer Fridrich Štrba <fridrich.strba@bluewin.ch> 2013-03-12 04:36:59 (GMT) commit aaab3a79dfd762a64fa4c1d19dd29ae46c0b9dd0 (patch) tree 188563cd703994526098978c754392dbfc95de51 parent 3545b0398ef3516278c8ac7d55283ffdb7cc28b6 (diff) Resolves: #i120017, filter button is not shown in merged cell Patch by: zhao shao zhi, aoo.zhaoshzh@gmail.com Found by: Yan Ji,<yanji.yj@gmail.com> Review by: zhangjf (cherry picked from commit bcf01fd794ec169aaf2a3f8b86f986ec60e5beb8) Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 146540 [details] example of filter on vertical merged cells
Filters on orizzontally merged cells seems to work. Filters on vertically merged cells does not work. So the bug is still present. This is because the hidden cell(s) continues to maintain the hidden value. And this could be correct and useful in some use cases. IMO the best way to solve the problem is to add a forth option in the "Merge cells" window, letting the user to apply the content of the first cell to the hidden cell. Version: 6.1.3.2 Build ID: 1:6.1.3~rc2-0ubuntu0.18.10.1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Dear Emersson Augusto Suarez Ortiz, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Hi for the LO team. This bugs is still present in version 6.4.
Created attachment 171180 [details] attachment 118298 [details] in Calc and in Excel 19 > 2. The second is whit cells merged in the same column (only rows), the data > are well shown, but when you select a value to filter, only show or hide (it > depends what you select) the very first row of the merged range, and the > other rows that share the merged value are still shown by the filter. > I gave this file a try also after saving as XLSX and opening that in Excel. If I select in Column A to hide the value 1, both Calc and Excel hides the second row but not the others. So while this may look strange, at least Calc's behavior is consistent with Excel in case of filtering vertically merged cells.
Created attachment 171181 [details] attachment 146540 [details] in Excel and Calc after filtering for value 999 (In reply to mt from comment #16) > Filters on vertically merged cells does not work. > So the bug is still present. > > This is because the hidden cell(s) continues to maintain the hidden value. > And this could be correct and useful in some use cases. I gave try to the attachment #146540 [details] in Calc also after saving to XLSX in Excel. The behavior of Calc is consistent with Excel: as the example file says, filtering for the value 999 shows the row 13 with value "data 10" in B-D columns, and filtering for (empty) value shows the row 5 with value "data 5" in B-D columns in both software.
Tünde Tóth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b7d8ee083230964de2e1580c4639ee4cd307207f tdf#93664 sc: fix filtering clicking on cells merged horizontally It will be available in 7.2.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.
Verified in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 93bb5fcba9e58eeeaaed9521c3bb4eecf9b91ac1 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Tünde Tóth, thanks for fixing this issue!!
Tünde Tóth committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/77da04eb2ff83fe79e3ed8d79bc4f5f81af9119f tdf#93664 sc: fix filtering clicking on cells merged horizontally It will be available in 7.1.4. 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.