In mail merge with a simple document, even with only a merge field, if the document contains a table in the top of the page (before the fields) when you "Save merged documents" as individual documents, you obtain the exact number of output files, but the first and the second files are identical (in the content) and related to the first record of data. The last obtained file contains the merged content of the 2 last records of data. The behavior returns normal when the table is removed from the mail merge master document.
The same "tabled" document merged with Openoffice does not present this behavior.
Steps to Reproduce:
1. create a new empty writer document (odt);
2. with Tools -> "Mail Merge Wizard" select an "Address List" (a simple ods file with a field of data);
3. insert a table on the top of the page;
4. open "Data Sources" (CTRL+SHIFT+F4);
5. insert the field in the document with drag and drop after the table position;
6. on the "Mail Merge toolbar" select "Save merged documents" -> "Save as individual document" -> Save Documents;
7. select a name for merged individual files;
The number of the files obtained is correct (the same of the rows of data).
The first and the second file (name_0, name_1) have the same content, if the rows of data contains [1,2,3,..,n] the first and the second file refer to the same value of data "1". The last file name_n-1 contains 2 pages with value of n-1 and n rows data.
The first file contains the first data row.
The second file contains the second data row.
The last file contains the last data row.
User Profile Reset: No
If the table (on the top of the page) is deleted the behavior of mail merge becomes normal.
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Created attachment 132720 [details]
Example of db to test the bug
Simple db to test writer bug
Created attachment 132721 [details]
Example of mail merge odt (with table) to test the bug
Use this odt file with the db (other attachment) to test the behavior of writer
Didn't have time to test more, but not reproduced with a single test with master 6.0+.
Since you made really good bug report, please always also test with master.
In Windows, you may get http://tdf.io/siguiexe to easily get and run "parallel" LO in Windows (extract without installation).
If master also works for you, then it's WorksForMe.
Actually, I didn't reproduce on other example, but I did on yours.
Before confirming the bug, it should be clear why exactly.
So this generic title is not true.
Whatever the cause of this bug is, it still exists with 6.0+.
Looks like the cause is table before field, and even that only if document starts with the table. If there's line before, not reproduced.
I reproduced on yours and on the other example, like my data source. Repro with 4.4.0 so bibisect hopefully possible.
I change the generic title to point to table issue.
Thanks for the attention, now the bug's title is clearer. The bug is especially dangerous if you use the automatic sending of emails with custom attachments, a person's attachment might be sent to others with privacy issues.
Bibisected on Windows to range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=1964870db4ad1e4334e8fc5050795469dc1fb05e...64f186cfda29d3d92c0ebd9c4ee7992898a00134
of which https://cgit.freedesktop.org/libreoffice/core/commit/?id=c808802e94eba48dc23d7fca133ed35c17feb163 seems to be the cause
commit c808802e94eba48dc23d7fca133ed35c17feb163 (patch)
parent 8e174eab91acec0f1578af4dac23be76dce700af (diff)
MM: introduce SwDoc::Append helper function
This drops all the specialized, workaround code from MM, introduced
to use the SwFEShell::Paste function and additionally merges
and renames SwDoc::Paste into SwDoc::Append.
There is still a little common codepath, therefore this adds
comments to always update both functions.
Adding Jan-Marek to CC
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!