[Libreoffice-bugs] [Bug 89178] Mail merge does not change the merge fields in files (when saved as individual documents) to plain text

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=89178

--- Comment #25 from Jan-Marek Glogowski <glogow at fbihome.de> ---
(In reply to Ben Fleming from comment #24)
> (In reply to Jan-Marek Glogowski from comment #23)
> Thank you very much for your reply, it was really interesting to have the
> insight from someone who knows the code.
> 
> So if I understand you correctly, the MM process merely produces one doc
> with bookmarks and then it splits that document into individual files.

No. My description is just the MM wizard behavior and describes, why you see
differences between the wizard and UNO / your BASIC macro. I just had to check
the source code. LO MM wizard generates a document shell and a list of
bookmarks, which point into the document (see SwMailMergeConfigItem and
SwDocMergeInfo). I suggest to use https://opengrok.libreoffice.org/ to display
the C++ definitions.

There is also a README in
https://opengrok.libreoffice.org/xref/core/sw/source/uibase/dbui/. It describes
the MM behavior based on the members of SwMergeDescriptor, which describes how
to process the input. That descriptor also has more comments on its members.
Most members will directly match to UNO from what I remember.

> Is there any way to replicate this behaviour through the (BASIC) UNO API?
>
> When I generate a MM to a single document myself manually, I cannot see any
> bookmarks.

I think so. You need to do a MM of type MailMergeType.SHELL, not a document
MailMergeType.FILE. That will generate a LO internal document shell. And it
fills a list of SwDocMergeInfo with the UNO bookmarks into the merged document.
So the document itself doesn't contain the bookmarks. 

I know WollMux uses it to implement its MM (if you know Java see
https://github.com/WollMux/WollMux/blob/WollMux_18.2/core/src/main/java/de/muenchen/allg/itd51/wollmux/mailmerge/print/OOoBasedMailMerge.java),
so that should work with BASIC too.

> > This is all very non-obvious from the users POV.
> 
> This is the problem really, I suppose at least the front-end is behaving (at
> least in my testing) exactly as expected, although there are a lot of bugs
> open to suggest it doesn't for everyone?

See https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html:
12102 open bugs. And LO has probably 30-40 core developers, half of them mainly
working on LO Online (that is just a guess).

And a few bugs will be for mail merge. Problem is, most features don't have any
description of "expected behavior". One persons bug might literally be an other
persons feature, and that is not just an XKCD joke (https://xkcd.com/1172/). If
you have millions of users, there will be enough existing workflows, which
expect some behavior, even if it's actually a bug. I broke stuff this way a few
times.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210112/8f9081f4/attachment.htm>