Description: 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; Actual Results: 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. Expected Results: The first file contains the first data row. The second file contains the second data row. .... The last file contains the last data row. Reproducible: Always User Profile Reset: No Additional Info: 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) tree 8faaf4dfaec9a046137d57eb084d0d74f9afca66 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. Change-Id: I704b3ef3257dd977dac95e16e25049ff8ade97ed Reviewed-on: https://gerrit.libreoffice.org/10967 Adding Jan-Marek to CC
Dear Braciolo, 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! Warm Regards, QA Team MassPing-UntouchedBug
Still happens in Version: 7.0.0.0.alpha0+ (x64) Build ID: a40455528c4ec2c079444f320a02d1946e1d8ac9 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL
*** Bug 139072 has been marked as a duplicate of this bug. ***
Got similar issue when use MailMerge and XMailMergeListener to fill text fields. When I use individual document text field stores Content and Value property from previous row. If I use merged document issue doesn't occur.
For some reason I cannot reproduce anymore with old LO that I could before.
*** Bug 150885 has been marked as a duplicate of this bug. ***
So, thanks to Mike, it's more clear now. Bug is: MAILMERGE wrong if document starts with table when output saved as individual documents using Mail Merge toolbar (Data Sources toolbar and it's Mail Merge icon in older LO). Bug no repro if mailmerge used via Print. With original attachment 132721 [details], after table is the fields, so error is that the second document is identical to the first one. With 3-page ODT attachment from duplicate bug 150885, after table there's paragraph and then field, error is that 1st result ODT is 2 pages, 2nd ODT is then 3 wrong pages, last ODT is 4 pages. While we can use Print, some users will go to MM toolbar and this is already bibisected regression, so I find it justified to set High.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eb30df9b8e86f756ebc66be86ae2eb345fafc850 tdf#106959: use table's first content node for cursor cleanup It will be available in 7.5.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.
Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: eab9015d1e17950ee5a49f93a6ad40e7726f5050 CPU threads: 1; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US Calc: threaded Mail Merge works fine.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/87f17803a907c29a121fcb84588da98a51cca543 tdf#106959: use table's first content node for cursor cleanup It will be available in 7.4.2. 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.
> Mail Merge works fine. So Verified. Great. This was sneaky bug, as it's common to start mail merge document with company logo in table.