Bug 68024

Actually, even <text:variable-set> in a cell of type void is evaluated.

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

Lionel - Who should address this bug?

(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 / ...?

(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!

(Removing NeedAdvice tag)

Lionel - Please feel free to set the status of these regressions directly to NEW.

(This is an automated message.)

It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.)

Thus setting keyword "bisected".

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.

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 :(

(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.

(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>

(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 :-|

Adding bibisected to whiteboard as bisected keyword is a subset of bibisected whiteboard.

Thanks!