Bug 120316 - Calc changes the validity parameters in contigous cells.
Summary: Calc changes the validity parameters in contigous cells.
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.6.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-04 15:22 UTC by Jerzy Moruś
Modified: 2019-06-05 11:31 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
visualization of the problem in the swf file (479.04 KB, video/swf)
2018-10-04 18:45 UTC, Jerzy Moruś
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jerzy Moruś 2018-10-04 15:22:20 UTC
Malfunctioning of Calc when contigous cells are assigned data validation. I can not determine the rule that generates this erroneous behavior, but after entering the data into the cells, the data validation rules move to the neighboring cell, changing its original rule. The changes occur once in the left or right cell, but I can not determine what determines which cell will change.
Steps.
1. For A1 cell Assign Data → Validity ...  → Whole Numbers, not equal 0.
2. For B1 cell Assign Data → Validity... → Decimal, greater than or equal 0.
3. Enter the number into cell A1
4. Enter the number into cell B1
5. Return to cell A1. Validity properties have been changed to what they are in B1
For everything to function correctly, one empty cell should be inserted between neighboring cells.
Comment 1 Oliver Brinzing 2018-10-04 17:12:46 UTC
i tried with lo 6.0.6.1 and lo 6.1.2.1 and can not confirm this behaviour.
Comment 2 Jerzy Moruś 2018-10-04 18:45:41 UTC
Created attachment 145396 [details]
visualization of the problem in the swf file
Comment 3 raal 2018-10-05 08:02:16 UTC
no repro Version: 6.2.0.0.alpha0+
Build ID: 75a48e37b260c145297261d0e0ab5720894404f1
CPU threads: 4; OS: Windows 6.1; UI render: default;
Comment 4 Oliver Brinzing 2018-10-06 08:48:39 UTC
no repro Version: 6.1.2.1 (x64)
Build-ID: 65905a128db06ba48db947242809d14d3f9a93fe
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc:
Comment 5 Xisco Faulí 2018-11-08 13:22:51 UTC
Dear Jerzy,
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 6 Jerzy Moruś 2018-11-09 10:54:45 UTC
In version 6.1.3.2, the error still occurs.
Comment 7 Jerzy Moruś 2018-11-10 12:35:16 UTC
An important attention.
The problems I wrote about appear in the 64-bit version of LibreOffice.
In computer with a 32 bit edition this programm, this problem does not occur.
Comment 8 Xisco Faulí 2019-05-16 11:52:08 UTC
Hello Jerzy Moruś,
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 9 Jerzy Moruś 2019-06-05 11:16:57 UTC
I am a conservative LibreOffice user. In version 6.1.6 (64 bits), the problem is fixed. Thank you.
Comment 10 Xisco Faulí 2019-06-05 11:31:42 UTC
(In reply to Jerzy Moruś from comment #9)
> I am a conservative LibreOffice user. In version 6.1.6 (64 bits), the
> problem is fixed. Thank you.

Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.