Bug 53430 - FILTER: Contain/Does not contain etc Filter does not work on cell with numbers only, if cell format was changed to text after inputting the numbers
Summary: FILTER: Contain/Does not contain etc Filter does not work on cell with number...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Data-Filter
  Show dependency tree / graph
 
Reported: 2012-08-13 08:38 UTC by joe
Modified: 2021-06-19 14:55 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
screenshot (180.60 KB, image/jpeg)
2012-08-13 09:03 UTC, joe 		Details
File in which the problem occurs (7.57 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-12-26 20:23 UTC, Sören 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description joe 2012-08-13 08:38:22 UTC 
If cell contains numbers only
e.g. Cell A2 with value "12345" and format as text (Format code: @) or general (Format code: general)
if I select Data->Filter->Standard Filter
with condition "begins with" or "contains", and enter "1" in value 
Cell A2 will be hidden, which is not expected
Comment 1 joe 2012-08-13 09:03:12 UTC 
Created attachment 65492 [details]
screenshot
Comment 2 leo.moons 2012-12-16 22:59:13 UTC 
To me, the bug is not in the filter function but in teh formatting of cells: when a number is entered and later the format is changed to "text", nothing is happening. One can still make some calculation with the content of the cell.

On the other hand: if the format is changed before anything is entered in the cell, the entered number will be recognised as text and filter will work OK, as well as any other text related functions.

Best regards

Leo
Comment 3 Sören 2012-12-26 20:23:04 UTC 
Created attachment 72145 [details]
File in which the problem occurs
Comment 4 Sören 2012-12-26 20:26:36 UTC 
I reproduced the problem in
Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0)
on Ubuntu 12.04 (x86)

In the attached file, choosing
*Data -> Filter -> Standard Filter
*Field Name = Column A, Condition = Begins With, Value = 34
*Ok

Only row 2 and 3 (entered as '345 and ' inserted manually) are filtered, row 5 (marked as text by rightclicking -> Format Cells -> Category = Text) isn't filtered out correctly
Comment 5 QA Administrators 2015-04-19 03:22:51 UTC Comment hidden (obsolete)
Comment 6 Buovjaga 2015-06-18 15:41:01 UTC 
(In reply to Sören from comment #4)
> I reproduced the problem in
> Version 4.0.0.0.beta2 (Build ID: 4104d660979c57e1160b5135634f732918460a0)
> on Ubuntu 12.04 (x86)
> 
> In the attached file, choosing
> *Data -> Filter -> Standard Filter
> *Field Name = Column A, Condition = Begins With, Value = 34
> *Ok
> 
> Only row 2 and 3 (entered as '345 and ' inserted manually) are filtered, row
> 5 (marked as text by rightclicking -> Format Cells -> Category = Text) isn't
> filtered out correctly

Repro.

Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+
Build ID: 437210d58f32177ef1829d704f7f4d2f1bbfbfdd
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-18_07:21:56
Locale: fi-FI (fi_FI)
Comment 7 QA Administrators 2016-09-20 10:11:03 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2019-12-03 14:04:50 UTC Comment hidden (obsolete)
Comment 9 Buovjaga 2020-06-03 17:28:43 UTC 
Still repro. Also with 3.3.0

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: 2bccbd2ba6c90d5e02285629c2b079c35260c08b
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 3 June 2020
Comment 10 b. 2020-09-04 16:47:56 UTC 
yes, behaviour repro in ver. 7.1, 

no, not a 'bug', 

the behaviour - NOT! - to apply format changes to the data until the next input into / edit of the cells content, see comment #2 good seen by @leo.moons, - as wrong! as i find it - is! intentional, :-( 

the 'idea' is to not accidentally disturb users constructions by reformatting, 

'the developers' - esp. @Mike Kaganski - are really harsh in that question, 

counterarguments are: 

- the disturbance avoided now will likely come up later, and nobody will understand, 
- such behaviour is 'user trapping', 
- the content is! shown left aligned saying 'text' for simple minded users', 
- formatting is, as well as keying in something, an expression of the intention of the user, why should one block that? 
- sheets should be 'responsive', will say react to users will, 
- immediately after applying a format a user can see faults, and understand the context of the problem, lateron not, 
- immediately ... the user has ctrl-z at hand and can correct faults, lateron not, 
- you burden a lot of work on a user who wishes to reformat some 10k cells if you require to enter every single one and perform a 'non changing edit' to get the format applied, 
- while preserving the old construtions you much more disturb users ongoing work, 
- and plenty more, 

imho the behaviour is idiotic, but as our friend ex$el does the same shit (ver. 2010 winx64) ... there is very very very! little chance for a change ... 

and without a change of that behaviour this 'bug' isn't solveable ... 

i suggest changing to enhancement and force a re-thinking of the precedence of formerly applied format-data-connections over users will ...
Comment 11 Buovjaga 2020-09-09 07:11:33 UTC 
(In reply to b. from comment #10)
> yes, behaviour repro in ver. 7.1, 
> 
> no, not a 'bug', 
> 
> the behaviour - NOT! - to apply format changes to the data until the next
> input into / edit of the cells content, see comment #2 good seen by
> @leo.moons, - as wrong! as i find it - is! intentional, :-( 

I asked Mike K. and he commented: 'the question if "begins with" should or should not work with numbers is orthogonal to the question if changing format should change data type'. So let's keep this report as it was originally.
Comment 12 Stéphane Guillou (stragu) 2021-06-19 13:48:21 UTC 
Using the steps in Comment 4, this is a WORKSFORME with:

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 94d552f94b427f884c004dba5d4619ecf729d605
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-06-18_13:30:27
Calc: threaded

and

Version: 7.2.0.0.beta1 / LibreOffice Community
Build ID: c6974f7afec4cd5195617ae48c6ef9aacfe85ddd
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

This must have been fixed in the 7.2 branch as I can reproduce as described in 7.1.4 (only the two rows with "'345" are shown).
Comment 13 BogdanB 2021-06-19 14:55:24 UTC 
Indeed it's working well.
Retested on
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 51754ca5349d7bf655d57ded37381188d0bc4bcf
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded