Created attachment 144965 [details]
sample ods file

Created attachment 144966 [details]
sample odt file

After removing the surrounding table, the correct data is used.

Reproduced.

You missed instructions: to match the fields to data source entries, double-click them (Vorname, asd, asd2) and pick the columns with the matching names.

Arch Linux 64-bit
Version: 6.1.1.2
Build ID: 6.1.1-1
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded

Created attachment 166250 [details]
Another minimal odt file

This bug exists for a long time, and still exists on the current master build.

The problem is, when the mail merge file (i.e., the odt file) contains a table, then the merged result would have the 1st record in the 1st result, but the 2nd result still contains the 1st record, the 3rd result contains the 2nd record, and so on, and finally the last record would contain both the last-1 and the last record in the same document.

The problem does not happen if the odt file does not contain a table.

Attached is a minimal odt file.

Steps to Reproduce:

1. Open the "Another minimal odt file", double-click on any of the two fields, then browse "Add database file", choose the "Another minimal ods file" attached to the next comment.

2. Update the two fields to use the datasource you have added in step 1. Save and reopen the odt file.
(LibreOffice 6.4.6.2 may crash at this step, but this may be a different issue and I will report in a separate report)

3. Enable Mail Merge toolbar (View -> Toolbars -> Mail Merge), click once the "Next Mail Merge Entry" (i.e., -> button in the Mail Merge toolbar). Then click "Save Merged Documents -> Save as Individual documents" on the same toolbar. Choose a location and save.

4. Open the merged individual odt files.
--> The 1st result correctly contains the 1st record ("Kevin Suo"). The 2nd result wrongly still contains the 1st record ("Kevin Suo"). The 3rd result wrongly contains both the 2nd record ("Xiujuan Liu") and the 3rd record ("Aixi Suo") in the same file on two different pages.

The expected result is, 1st record in the 1st result, 2nd record in the 2nd result, and 3rd record in the 3rd result.

Created attachment 166251 [details]
Another minimal ods file (datasource)

Created attachment 166252 [details]
merged result 7z from the minimal file

@Kevin Suo <suokunlong@126.com>: Thank you for your effectively minimized error report. I am suffering the same bug for many years. In good old days this used to work.

I am very sad that we don't have enough resources to kill this bug: Mail Merge fields in an array of an odt- document.

I have always used a header of all my letters with the 2x2 table with specific dimension to fit the envelope with the transparent "address-window".

I am suffering this bug for years. I am forced to write a bash script each time I make a significantly different Mail-Merge document to cut resulting one-PDF to individual letters, where I am forced to keep all copies of the same number of pages, ...

Unfortunately, I am a "complete newbie" in LibreOffice source code, but if I could get enough support, I might be able attack this bug myself or preferably in a group of co-sufferers.

@documentfoundation.org: Assignee: Not Assigned, really? 

Kevin Suo <suokunlong@126.com>, thanks again that I do not have to repeat the report, just quote it.

Currently there is no one working on this.

Yes, of course you can try to fix this by yourself. You can search the code on https://opengrok.libreoffice.org/, then set breakpoints to where you are interested, then it will not be difficult to find the reason, if you know some cpp.

(In reply to marjan from comment #10)
> @Kevin Suo <suokunlong@126.com>: Thank you for your effectively minimized
> error report. I am suffering the same bug for many years. In good old days
> this used to work.

If this used to work in the past, this is a regression and doing a bibisect could help finding out what change introduced the problem. Once that is known, finding the root cause and a potential fix is usually much easier.

See this wiki page:
https://wiki.documentfoundation.org/QA/Bibisect/

In case you want to take a look and debug into this yourself, I have taken those notes for potential starting points for mail merge a while ago:

> * Relevant code places:
> 
>     * `sw/inc/dbmgr.hxx`, `sw/source/uibase/dbui/dbmgr.cxx`, in particular the
>       whole method `MergeMailFiles()`
> 
>     * unit tests are in `sw/qa/extras/mailmerge/mailmerge.cxx` -> have a look
>       at existing ones in order to see how this works
> 
>     * implementation for mail merge related dialogs: `sw/source/ui/dbui/mmresultdialogs.cxx`
> 
>     * UNO API method implementations: `sw/source/uibase/uno/unomailmerge.cxx`
>

Could someone reproduce the crash following the steps I have mentioned in comment 7? I see it on master dbgutil build.

The crash may have related to this index-off issue, but we may need to fix the crash first before we see whether they are of the same cause.

Repro per Comment 7 in LO 6.4 and 7.3+, using ODT attachment 166250 [details]. If ODS attachment 166251 [details] is saved with original name, no need to "Add database file" or update fields.

Repro only with all this: using Mail Merge toolbar, "Next Mail Merge Entry", "Save Merged Documents -> Save as Individual documents". 
No repro without toolbar but with File-Print or with Mail Merge toolbar saving as Single document, regardless of "Next Mail Merge Entry" button. 

MM toolbar appeared in LO 5.2 but Next Entry worked in 5.3 and it's already wrong there. So I set implementationError.

With LO 7.3+, I just have reliable crash on LO exit after using MM. 
@Kevin: you may try to reset user profile and just use ODT from the same folder where you have ODS.

It might be that original report and bug 139072 are bug 106959 that is a regression, while I tested per Comment 7 something else that's related to using toolbar.

Bonjour

Le bogue existe toujours dans la dernière version de LibreOffice. 
Le publipostage fonctionne quand il se fait vers un fichier, mais est décalé quand il est vers des méls, lorsque que le .odt contient un tableau.

Dear brief,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug