Created attachment 157746 [details] Test documents using plain text data resp. data in a User Field I'm trying to use a User Field for some calculations in a table. This works fine for plain numbers, but fails to work for time formatted entries. Document "Test-field.odt" shows the intended use: the left column holds entries that represent some time (given in hours and minutes, using time format string "[H]:MM" resp. "876613:37"), the middle column has some hourly rate, and the right column calculates the amount. This works fine here. In document "Test-field.od" the time entry in the last line has been replaced by a User Field. The name is "var_time", format is Time, time format string again "[H]:MM" resp. "876613:37", value is 6:30. However, the document displays not the expected "6:30", but "0:00" instead. Also, the calculation does not give the expected result. I think the input format "6:30" for the value is not recognized as a valid number. When I change the value for the field to a plain number, say 6, the following happens: if I click the green checkmark, the value in the table changes into "6"; but as soon as I clock OK, it changes into "144:00". Apparently the number is counting in days here. I can try confirm this by entering a float number 0,270833333 as value for the field. clicking on the green checkmark, it shows the float number as entered as value for the field, but when clicking OK it shows "6:30", and the computation gives the expected result. However, when I select a "[H]:MM" time format, I should also be able to enter data in that format. I wonder if the resulting declaration of the field in the XML file is correct; it reads: <text:user-field-decl office:value-type="float" office:value="0" text:name="var_time"/> Using plain numbers, I see this is represented as something like ...office:value-type="time" office:time-value="PT06H30M00S"...
(In reply to Wolfgang Denk from comment #0) > I think the input format "6:30" for the value is not recognized as a valid > number. When I change the value for the field to a plain number, say 6, the > following happens: if I click the green checkmark, the value in the table > changes into "6"; but as soon as I clock OK, it changes into "144:00". > Apparently the number is counting in days here. I can try confirm this by > entering a float number 0,270833333 as value for the field. clicking on the > green checkmark, it shows the float number as entered as value for the > field, but when clicking OK it shows "6:30", and the computation gives the > expected result. confirming, it seems only decimal values are accepted Version: 7.0.0.0.alpha0+ (x64) Build ID: e6341e0f613237020fef9e2028e123022ff2ce38 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded
How does this continue? For more than two months nobody bothered to do anything about this bug - it has not even been assigned to anybody yet?
Dear Wolfgang Denk, 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
The bug is still present in LibreOffice Version: 7.2.6.2 Environment: CPUthreads: 24; OS: Linux 5.16 User Interface: UI render: default; VCL: x11 Locale: de-DE (C.UTF-8); UI: en-US Misc: Calc: threaded
I reproduced in OOo 3.3, so the issue in inherited.
(In reply to Wolfgang Denk from comment #0) > I wonder if the resulting declaration of the field in the XML file is > correct; it reads: > > <text:user-field-decl office:value-type="float" office:value="0" > text:name="var_time"/> The float 0 is a result of the input not being accepted. (In reply to Wolfgang Denk from comment #2) > How does this continue? For more than two months nobody bothered to do > anything about this bug - it has not even been assigned to anybody yet? We don't assign bugs to anyone. If developers pick a bug to work on they'll assign the bug to themselves.
This has been fixed with the fix for bug 154218.