Bug 45681 - [Calc] [AutoFilter] Inconsistent meaning of Check Box "All"
Summary: [Calc] [AutoFilter] Inconsistent meaning of Check Box "All"
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.1.2 release
Hardware: Other Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-06 02:51 UTC by Michel Rudelle
Modified: 2015-12-23 19:21 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Follow the described procedure with this spreadsheet (11.87 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-02-06 02:51 UTC, Michel Rudelle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Rudelle 2012-02-06 02:51:00 UTC
Created attachment 56654 [details]
Follow the described procedure with this spreadsheet

Hi, please use the joined example:
Filter column A : select 01/12/2011 and 02/12/2011
Activate the filter column B: Check Box "All" is activated, that’s ok
 - inactivate Check Box "All"
 - then select 1 and 2, now Check Box "All" is still activated, that’s not what you are expecting because you just want to display 1 and 2 and not all the column.
The expected result should display the Check Box "All" shaded

So we have there two problems:
 1) a logical one: two different meanings for "All": all the column or all the list in the box
 2) the impossibility to select all the items of the list and only those

LibO 3.5.0 rc3 / Windows 7
Comment 1 john.pratt 2012-09-02 10:50:54 UTC
Confirmed - the meaning of the 'All' checkbox varies depending on whether there is filtering in another column or not.

I agree that it is logically inconsistent to show the 'All' box ticked when it only means all of the things which are currently visible after other filters are applied.

Ideas for solution:
 * 'All' should be shaded in this situation.
 * all items still show in the box even when a filter is applied elsewhere, meaning they are not actually visible, but ones which are hidden (e.g. '3's in the example) are moved to the bottom of the list and written in grey type to make it clear they are not currently visible below.
 * add a tab to the dropdown to allow working with currently visible data or all data
Comment 2 Mirosław Zalewski 2013-08-14 15:23:33 UTC
I don't think this is a bug, really.

What mentioned checkbox actually does, is changing state of checkboxes on the list above, all at once. It does it consistently, independent of settings in other windows.

So, one can think that "All" is just short form for "Check/uncheck all entries above".

And since main list is populated with *visible* values from column (that is, it takes other filter criteria into account), Calc behavior is desirable - checking all entries on list turns "All" checkbox on.

I can agree that this wording might be a bit unfortunate, but:
1. There is really little place, so it must be kept short.
2. It is right by two buttons that does change state of boxes above. User might think of these three items as related somehow and easily deduce their true meaning.
3. As fallback, we have documentation (built-in help and PDF files on the web) that should explain how this option work.

I believe that this bug should be closed; another one should be created, requesting help toolbox for this option (as there are these for accompanying buttons).

Changing state to NEEDINFO for now, as it will automatically close bug report after some months of inactivity.
Please do NOT change state of report until consensus is reached.
Comment 3 Michel Rudelle 2013-08-21 17:10:19 UTC
I commented bug 57431 where I tried to explain why it is not a misunderstanding nor a problem of documentation.
These 2 issues are in my mind duplicates, though bug 57431 presents also another issue you reported as bug 68113.
Regards,
Comment 4 Mirosław Zalewski 2013-08-21 22:29:14 UTC
OK, after your use-case from Bug 57431, let me put it this way:
This bug shows correct conclusions, but based on false assumptions.
Use-case provided here might be interpreted from other point of view, which makes actual results expected. And if result got is expected, it is not really a bug.

To make it clear for programmers, I have created Bug 68406, which goes to the same conclusions, but also provides valid (in my understanding) use-case.

Also, please read <https://bugs.freedesktop.org/show_bug.cgi?id=57431#c8> which shows how I understand these different bug reports. Feel free to disagree.
Comment 5 QA Administrators 2014-05-17 00:34:27 UTC
Dear Bug Submitter,

Please read the entire message before proceeding.

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team
Comment 6 QA Administrators 2014-06-01 20:30:23 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO
Comment 7 Michel Rudelle 2015-12-23 19:21:23 UTC
Hi,
This bug is fixed by adding the box "empty", thank you.
Tested with LibO  5.0.3.2
Best regards