Bug Hunting Session
Bug 80905 - FILEOPEN: RTF or DOCX repeated merge fields not imported
Summary: FILEOPEN: RTF or DOCX repeated merge fields not imported
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium major
Assignee: Miklos Vajna
URL:
Whiteboard: target:4.4.0 target:4.3.1
Keywords: regression
Depends on:
Blocks:
 
Reported: 2014-07-04 09:08 UTC by Gergely Rácz
Modified: 2014-07-14 11:40 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Steps 1-7 (34.18 KB, application/x-zip)
2014-07-04 09:08 UTC, Gergely Rácz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gergely Rácz 2014-07-04 09:08:51 UTC
Created attachment 102261 [details]
Steps 1-7

Situation:
Users have thousands of RTF files which are used as main document in mail
merge, having the fields filled from a text file (txt).

Issue:
Repeated fields are shown as plain text (except the first one).

Steps to reproduce(or use the attached document: test.rtf or test.docx).:
1. Create a Word document with MS Office.
2. Insert two MergeField field with the same Field name (eg. TEST).
3. Save the file in RTF or/and DOCX format.
4. Open the file with LibO.

Result:
- First field is shown as a field, but the second field is shown as a plain text.

Further steps (or use the attached document: test2.rtf or test2.docx):
5. Open the file with MS Office. 
6. Insert a new MergeField field before the fields with the same field name and save it. 
7. Open the file with LibO.

Result:
- The first field is shown as a field but the second and the third are shown as plain text.

Expected result:
- all of the fields should be shown as fields (with grey background).
- If you create a .doc file instead of .rtf or .docx, it works fine.
Comment 1 Cor Nouws 2014-07-05 17:55:19 UTC
Hi Gergely,

Thanks for the issue.
In 3.5.x to 4.0.0 I see no fields at all, only text.
In 3.3.x and 3.4.x all the fields are shown.

regards,
Cor

(searching for duplicates and related issues appreciated)
Comment 2 Commit Notification 2014-07-13 16:36:41 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

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

fdo#80905 SwXTextFieldMasters::hasByName(): sync with SwXFieldMaster



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 3 Miklos Vajna 2014-07-13 16:38:15 UTC
This is a bug in the UNO API impl, and in <= 3.4.x the RTF import used the internal API, so it wasn't affected. In >= 3.5.x, it uses the UNO API, so the existing problem can be easily noticed.
Comment 4 Miklos Vajna 2014-07-13 18:48:27 UTC
-4-3 review: https://gerrit.libreoffice.org/10269
Comment 5 Commit Notification 2014-07-14 11:40:54 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4fd1b2eafcc49486cb6a360d792f779659b68e2&h=libreoffice-4-3

fdo#80905 SwXTextFieldMasters::hasByName(): sync with SwXFieldMaster


It will be available in LibreOffice 4.3.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.