Created attachment 152179 [details] Sample XLSX Open the attached spreadsheet, created in Excel. In the B column, next to the description validation criteria is set with "equal to" setting that refers to the cell itself. This means only the basic criteria is taken into account (whole number, decimal, date, time), and any such entry can be entered. Enter values like: - 645789 - -1956.56 - 1999-08-31 - 23:59 These are all allowed in Excel, but none of them is allowed in Calc. Note that in Excel the value criteria can be a cell reference, however Calc shows cell references as values (eg. "B1" instead of "=B1"), and doesn't allow selecting a referenced cell. Observed using LO 6.4.0.0.alpha0+ (95462a02a3aee1e3e7f9aa8fc50ba25fee3fa592), 4.0.0.3 / Windows 7.
What seems a bug to me it's accepting a value different than the value in the referenced cell, not complying the criteria.
Created attachment 154728 [details] Example file from Calc Reproduced in Calc, without involving an XLSX file: Version: 6.4.0.0.alpha0+ (x86) Build ID: c45d477b0a0038d9c25176cf7cff299e5ddf3a7a CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-09-30_05:06:55 Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL It is possible in the editor to refer to the same cell and it does not work. This is set here in column B. The same validity condition works if it refers to a different cell. This is set in column D, referring to column C.
Confirming and removing xlsx-related meta/keyword.
Confirming what, what is the bug?. Sure there is something that I miss, here. Change the value of a cell doesn't validate against itself, what it's wrong?, the opposite works as if no validation, so for what is needed the validation, in such case?. I don't see the bug assigned, the way it's other person confirm the bug, not the reporter.
(In reply to NISZ LibreOffice Team from comment #2) > Reproduced in Calc, without involving an XLSX file: Indeed, I was thinking the whole thing was unsupported in Calc, but since the cell reference works, there's no reason why self-reference shouldn't work. (In reply to m.a.riosv from comment #4) > Change the value of a cell doesn't validate against itself, what it's > wrong?, the opposite works as if no validation, so for what is needed the > validation, in such case?. The point of self-referring the cell is that you only want to allow the entry of a specific type of data (ie. whole numbers, decimals etc.), but want to put no further restriction on it. There's no such option in the "Data" dropdown, so it can't be done in a different way AFAIK. And even if there's another way, this is an interop issue between Excel and Calc, because Excel accepts any entries in a cell with self-referencing validity criteria, as long as it conforms to the selected type of data. You can enter data in such cell in Excel, but not in Calc, what is that if not an issue?
I don't understand the reasons, and only compatibility it's no one for me.
Please read both of my previous explanations: (In reply to Aron Budea from comment #0) > "equal to" setting that refers to the cell itself. This means only the basic > criteria is taken into account (whole number, decimal, date, time), and any > such entry can be entered. (In reply to Aron Budea from comment #5) > The point of self-referring the cell is that you only want to allow the > entry of a specific type of data (ie. whole numbers, decimals etc.), but > want to put no further restriction on it. There's no such option in the > "Data" dropdown, so it can't be done in a different way AFAIK. Trying once again with an explanation. If you set it to eg. whole number this way, only a whole number can be entered in the cell. It's a way to only allow certain type of data to be entered, without having to specify further, unnecessary restrictions.
@m.a.riosv: does the issue require further clarification?
Sorry, I can't agree this is a bug, but if it is for you, don't worry, mark it as new.
Dear Aron Budea, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug