Bug 68024 - table: evaluates <text:variable-set> in body of float and void cells, but not of string cells
Summary: table: evaluates <text:variable-set> in body of float and void cells, but not...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: odf
Keywords: bibisected, bisected, regression
Depends on:
Blocks: 68020 67930
  Show dependency treegraph
 
Reported: 2013-08-12 14:24 UTC by Lionel Elie Mamane
Modified: 2024-02-09 03:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2013-08-12 14:24:02 UTC
Consider attachment 83968 [details]

In the first three rows, the body is always displayed (in these cases,
the office:value attributes properly overrides the child text:p),
but it is always *treated* in some way. In particular, <text:variable-set>
tags are treated. See that variables (foo|bar)Apr(Pri|Sec) as well as
(foo|bar)AugPri are set, and displayed in the page footer:
 f41-b41,f42-b42,f81-b81

On the other hand, for cells with office:value-type="string"
(rows August Secundo and August Tertio), as soon as there is
an office:string-value (that is, the second column), the
<text:variable-set> in the body are not evaluated; the variables
fooAug(Sec|Ter) stay at "0". This is what causes bug 67930. In the
absence of an office:string-value, however, the body is displayed
and executed, and the barAug(Sec|Ter) variables do get set.

It should be coherent, and *always* evaluate <text:p> within
each body.
Comment 1 Lionel Elie Mamane 2013-08-12 14:28:04 UTC
Actually, even <text:variable-set> in a cell of type void is evaluated.
Comment 2 Lionel Elie Mamane 2013-08-12 14:55:29 UTC
This is a regression compared to 3.5.4.2; most probably introduced by the fix to bug 60842:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b5839f49c07beb6fbde6c7370a5636d22f9ab77

fdo#60842: sw ODF import: support value-type="string" on cells
Comment 3 Robinson Tryon (qubit) 2014-01-16 15:19:59 UTC
Lionel - Who should address this bug?
Comment 4 Lionel Elie Mamane 2014-01-16 15:41:20 UTC
(In reply to comment #3)
> Lionel - Who should address this bug?

I hoped that Michael Stahl would address it, since he addresses similar / related bugs. Failing that, some other Writer hacker / expert / ...?
Comment 5 Robinson Tryon (qubit) 2014-02-03 19:00:09 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Lionel - Who should address this bug?
> 
> I hoped that Michael Stahl would address it, since he addresses similar /
> related bugs. Failing that, some other Writer hacker / expert / ...?

Sounds good.

In general, QA has been using the 'NeedAdvice' tag to mark bugs that need to be escalated up for a dev to evaluate. I'd like to see bugs be addressed by a dev within perhaps a month of being tagged -- having bugs sit in this state for months at a time makes it harder for us to filter on this tag and get a list of actionable bugs.

I'd appreciate it if anyone who tags a bug as NeedAdvice makes sure to follow-up on the bug at least once a month and see what they can do to spur our existing devs to comment on the results. If a bug really isn't actionable for a while, I'd be open to introducing a new tag 'NeedAdviceInTheFuture' to separate-out these particular outliers.

Thanks!
Comment 6 Robinson Tryon (qubit) 2014-07-03 20:29:57 UTC
(Removing NeedAdvice tag)

Lionel - Please feel free to set the status of these regressions directly to NEW.
Comment 7 Björn Michaelsen 2014-10-16 14:59:03 UTC Comment hidden (obsolete)
Comment 8 Michael Stahl (allotropia) 2014-12-12 15:40:48 UTC
sigh... retyping comment since bugzilla ate it...

that we import the field for value-type="float" or value-type="void"
sounds like a bug to me.

ODF 1.2 19.385 office:value-type is quite clear that the value 
from office:string-value takes precedence over the element content.

the value of the table cell would include any fields or other
formatting in the element text, which obviously can't be
encoded in an XML attribute.

so from that it doesn't make sense to add an office:value-type
attribute on a cell that has content that isn't just plain text.

another point of view would be that the ODF spec has a bug here
and that office:string-value should not take precedence over the
element content.

office:value-type="string" already differs from the other types
in that for the other types the *-value attribute is mandatory and
the element content is merely a "preview" text rendering for "dumb"
consumers with some particular # of digits etc.,
which is not a concern if the type is string.
Comment 9 Michael Stahl (allotropia) 2014-12-12 16:24:33 UTC
was wondering why the office:string-value exists at all;
Eike said that you can create a number format like this:
@ "foo"
and it will append "foo" to the text in the cell.

Calc implements this well, in Writer you can do this
in the UI but if you look at the exported ODF file it's
quite some nonsense :(
Comment 10 Michael Stahl (allotropia) 2014-12-12 16:27:39 UTC
(In reply to Michael Stahl from comment #8)
> so from that it doesn't make sense to add an office:value-type
> attribute on a cell that has content that isn't just plain text.

of course i meant "office:string-value" here.
Comment 11 Lionel Elie Mamane 2014-12-17 07:40:22 UTC
(In reply to Michael Stahl from comment #9)
> was wondering why the office:string-value exists at all;
> Eike said that you can create a number format like this:
> @ "foo"
> and it will append "foo" to the text in the cell.

And then, if there were no office:string-value, the original value (pre-formatting) would be "lost" (or, let's say, unduly hard to retrieve), since only the post-formatting result would be stored in the file.

This works only for non-formatted strings; this is obvious from the POV of the file format, but IMHO quite surprising for the "naive" user. <shrug>
Comment 12 Lionel Elie Mamane 2014-12-17 09:51:10 UTC
(In reply to Michael Stahl from comment #8)

> that we import the field for value-type="float" or value-type="void"
> sounds like a bug to me.

<big sigh> Report Builder relies on it :-|
Comment 13 Joel Madero 2015-01-05 17:16:29 UTC
Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.

Thanks!
Comment 14 Michael Stahl (allotropia) 2015-02-03 09:33:13 UTC
about the handling of "float" fields, see my comment on bug 68022
Comment 15 Robinson Tryon (qubit) 2015-12-14 05:06:28 UTC Comment hidden (obsolete)
Comment 16 Xisco Faulí 2016-09-26 15:21:17 UTC
Adding Cc: to Michael Stahl
Comment 17 Xisco Faulí 2017-07-13 09:52:13 UTC
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Comment 18 QA Administrators 2018-07-14 02:45:37 UTC Comment hidden (obsolete)
Comment 19 QA Administrators 2020-07-16 03:44:27 UTC Comment hidden (obsolete, spam)
Comment 20 QA Administrators 2024-02-09 03:13:40 UTC
Dear Lionel Elie Mamane,

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