Download it now!
Bug 133459 - FILEOPEN: User defined number format not applied to fields inside header or footer
Summary: FILEOPEN: User defined number format not applied to fields inside header or f...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.3.2 release
Hardware: All All
: high major
Assignee: Maxim Monastirsky
URL:
Whiteboard: target:7.1.0 target:7.0.0.1 target:6.4.6
Keywords: bibisected, bisected, regression
: 133130 133617 134230 (view as bug list)
Depends on:
Blocks: Writer-Header-Footer Fields
  Show dependency treegraph
 
Reported: 2020-05-27 17:43 UTC by Wolfgang Jäger
Modified: 2020-06-24 15:39 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
example file made with V6.4.3.2 (16.87 KB, application/vnd.oasis.opendocument.text)
2020-05-27 17:43 UTC, Wolfgang Jäger
Details
number style in <office:styles> (11.34 KB, application/vnd.oasis.opendocument.text)
2020-06-03 12:29 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Jäger 2020-05-27 17:43:27 UTC
Created attachment 161351 [details]
example file made with V6.4.3.2

(In pursuit of https://ask.libreoffice.org/en/question/246102/)

A TextField of type DateTime inserted into the Header or Footer of a PageStyle in a text document does not (at least not always) retain a user-defined NumberFormat when saved. In examples the format was changed to a default related to the document language. That the error occurred on save is the conclusion from a glance into the content.xml


This is a regression the latest older version I tested with was V6.2.5. It did not show the issue.

V7.0.0.0.alpha1 also has the bug.
Comment 1 Wolfgang Jäger 2020-05-28 10:24:38 UTC
I only reported the bug concernig TextField of type DateTime.  
Since, however, I found that also a numeric TextField.User was afflicted in the respective way. 
In addition: The created master had 3 dependent TextField_s, two of them in the TextBody. Only the NumberFormat of the dependent field in the Header was changed without permission.
Comment 2 ajlittoz 2020-05-28 10:26:56 UTC
Maybe another AskLO question https://ask.libreoffice.org/en/question/246102/why-doesnt-writer-remember-my-custom-formatted-date-field/ could be affected by the same bug.
Comment 3 Wolfgang Jäger 2020-05-28 20:02:58 UTC
(In reply to ajlittoz from comment #2)
> Maybe another AskLO question
> https://ask.libreoffice.org/en/question/246102/why-doesnt-writer-remember-my-
> custom-formatted-date-field/ could be affected by the same bug.

This was the ask.libreoffice question I had linked to anyway ("in pursuit of..."). 
Why did you remove the keyword "regression"?
Comment 4 Dieter 2020-06-01 06:31:56 UTC
I confirm it with

Version: 7.0.0.0.beta1 (x64)
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

but not with

Version: 6.1.6.3 (x64)
Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: group threaded
Comment 5 Xisco Faulí 2020-06-03 09:17:35 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=59ace23c367f83491a37e844d16f7d716eff6346

author	Maxim Monastirsky <momonasmon@gmail.com>	2020-02-21 02:35:55 +0200
committer	Michael Stahl <michael.stahl@cib.de>	2020-02-27 19:04:33 +0100
commit	59ace23c367f83491a37e844d16f7d716eff6346 (patch)
tree	af47d9b808037e3af045678b60b73e47b6f1121f
parent	5352d45dd4a04f8f02cf7f6ad4169126d3b3586a (diff)
tdf#101710 Fix invalid style:data-style-name attribute

Bisected with: bibisect-linux64-6.5

Adding Cc: to Maxim Monastirsky
Comment 6 Regina Henschel 2020-06-03 12:29:08 UTC
Created attachment 161573 [details]
number style in <office:styles>

I don't think, that the mentioned commit is the whole problem. But it might have uncovered the underlying cause.

If the <number:date-style> is in <office:styles> and not in <office:automatic-styles>, then the field in the header does not find the style. That problem is inherit from OOo.

But because it is a user-defined date style, I think, that <office:styles> is the correct place for it.
Comment 7 Maxim Monastirsky 2020-06-03 15:25:30 UTC
This is very odd. It seems to me that this happens only with odt files, but not with fodt files (in both cases the date style is under <office:styles>). Can someone else confirm this observation?
Comment 8 Dieter 2020-06-03 17:47:02 UTC
*** Bug 133617 has been marked as a duplicate of this bug. ***
Comment 9 Dieter 2020-06-03 17:52:02 UTC
(In reply to Maxim Monastirsky from comment #7)
> Can someone else confirm this observation?

Yes, I can confirm it with

Version: 7.0.0.0.beta1 (x64)
Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 10 Maxim Monastirsky 2020-06-03 20:22:16 UTC
What I found so far: The field code indeed seems to use automatic styles, with one exception: During the import of <office:automatic-styles>, there is a special code in the SvXMLImport::SetAutoStyles method that inserts already existing number styles into automatic styles as well. But for this to happen, the mnImportFlags member must include the SvXMLImportFlags::CONTENT flag.

For the fodt import, this method is called just once with mnImportFlags == SvXMLImportFlags::ALL. That's when the number style from <office:styles> is inserted into automatic styles, and later consumed from there by the header field.

But for odt, this method is called twice, because there is <office:automatic-styles> in both styles.xml and content.xml:

- For styles.xml, it's called with mnImportFlags == (SvXMLImportFlags::STYLES | SvXMLImportFlags::MASTERSTYLES | SvXMLImportFlags::AUTOSTYLES | SvXMLImportFlags::FONTDECLS), so the number style isn't inserted into automatic styles, and later can't be found by the header.

- For content.xml, it's finally called with mnImportFlags == (SvXMLImportFlags::AUTOSTYLES | SvXMLImportFlags::CONTENT | SvXMLImportFlags::SCRIPTS | SvXMLImportFlags::FONTDECLS). But while the number style is inserted, it has no use here, as the header is defined in styles.xml, and was processed already.
Comment 11 Wolfgang Jäger 2020-06-04 09:28:51 UTC
(In reply to Regina Henschel from comment #6)
> Created attachment 161573 [details]
> number style in <office:styles>
> 
> I don't think, that the mentioned commit is the whole problem. But it might
> have uncovered the underlying cause.
> 
> If the <number:date-style> is in <office:styles> and not in
> <office:automatic-styles>, then the field in the header does not find the
> style. That problem is inherit from OOo.
> 
> But because it is a user-defined date style, I think, that <office:styles>
> is the correct place for it.

Based on just a faint hope to understand better: 
In what way should the bug's "underlying cause" have been covered by versions where it was present in but did not become manifest?
Comment 12 Regina Henschel 2020-06-04 10:33:30 UTC
(In reply to Wolfgang Jäger from comment #11)
> (In reply to Regina Henschel from comment #6)
> Based on just a faint hope to understand better: 
> In what way should the bug's "underlying cause" have been covered by
> versions where it was present in but did not become manifest?

Older versions have written the user-defined number format to <office:automatic-styles> in styles.xml. So it was not detected, that the field in header/footer could not use a number format, that was in <office:styles>. But newer versions write the user-defined number format to <office:styles> and now the error becomes visible.
Comment 13 Maxim Monastirsky 2020-06-05 15:58:15 UTC
I think this will solve the file open problem:

https://gerrit.libreoffice.org/c/core/+/95612/
Comment 14 Maxim Monastirsky 2020-06-10 06:36:28 UTC
Turns out not only headers and footers are affected. Document fields indeed keep the number format itself, but lose the language setting. If I won't find a solution in a few days, guess I'll just revert the export part of bug 101710 for now.
Comment 15 Commit Notification 2020-06-11 21:08:26 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/cd0dc1bc592d7952c36659da33d99ab964fe2e93

tdf#133459 Fix import of fields with user defined number formats

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 16 Commit Notification 2020-06-13 21:27:31 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/30096602870e80d13158c32d82a34002e65374ef

tdf#133459 Fix import of fields with user defined number formats

It will be available in 7.0.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Commit Notification 2020-06-14 09:37:31 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/2c2820b98c62e8de0806fd79c34b5fcf37f00c7e

tdf#133459 Fix import of fields with user defined number formats

It will be available in 6.4.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Xisco Faulí 2020-06-16 11:05:34 UTC
Verified in

Version: 7.1.0.0.alpha0+
Build ID: 11d21b3c1f7754b5d13ae9ea88da562ec74366ff
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Maxim. thanks for fixing this issue!!
Comment 19 Maxim Monastirsky 2020-06-24 07:28:37 UTC
*** Bug 134230 has been marked as a duplicate of this bug. ***
Comment 20 Maxim Monastirsky 2020-06-24 15:39:25 UTC
*** Bug 133130 has been marked as a duplicate of this bug. ***