Created attachment 113181 [details]
Numbers of processes
The files generated by Mail Merge does not allow editing of merged fields. Appears the contents of the field, but are as mail merge fields and does not change.
Thanks for reporting this.
I updated the summary. That is what you want to say?
As far as I remember, this has always been the case. Fields remain the fields.
You may copy the fields and paste special as text only...
I think there also is an issue to request to make it easier to replace field contents by the text only. I think that would help you?
Hi Corn, this is already the merged file, the result should not appear as a field, but only text.
Sorry that I had the wrong idea.
However, I cannot reproduce the problem..
Is this with any document you try, or just with the document you attached?
(It is from 2011, reading the file properties).
Created attachment 113232 [details]
Make a simple mail merge with name, address and city, enter the fields in the main file and send to print single or individual files.
Open the generated file and try changing the merged content. The content appears as field and does not change unless you delete the field.
See the .doc file and compare as .odt file. The odt file content should be equal to .doc.
Thanks for the explanation and the test files.
I do not see the problem. I test on Ubuntu 32 bits. And you?
Cor (no 'n' at the end of my first name. N is the start of my family name ;) )
Created attachment 117212 [details]
Testing mail merge
After printing mail merge, this is result:
Individual files in .ODT
NAME: Ana Maria Braga
DEPTO: Pró-Reitora de Graduação
CIVIL STATUS: Solteira
The fields can not be edited.
You need print mail merge in format .DOC for edit.
Individual files in .DOC
NAME: Ana Maria Braga
DEPTO: Pró-Reitora de Graduação
CIVIL STATUS: Solteira
(In reply to Valdir Barbosa from comment #4)
> Created attachment 113232 [details]
> mailmerge ex.
Could not reproduce with FORM.odt using Database.ods as address source.
No fields appear in the merged document.
Are you using LibreOffice 5.0? Please test with it, if not.
Win 7 Pro 64-bit, Version: 188.8.131.52 (32-bit)
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: fi-FI (fi_FI)
Actually this bug mixes up multiple problems. Beware I'm writing this from my heart without a test, so feel free to prove me wrong :-)
1. As long as you _don't_ mail merge the result into a single file, the DB form fields will be preserved in the resulting _ODT_ documents! Another exception is _PDF_, where ConvertFieldsToText is enforced.
AFAIK this has never been different. Internally it's a speed optimization, because you don't need to copy the document, as currently "ConvertFieldsToText" can't be undone. So we just change the field content and save as an individual document. For others this might not be a bug, but a feature - who knows...
So from the users POV this is inconsistent, as MM produces files with and without form fields, depending on the output.
And these form fields aren't editable, as the content is from a DB. This is intentional too!
BTW - we're talking internal representation here. When saving we face the 2nd problem.
2. Microsoft Word formats have no equivalent to LO DB form fields used for LO mail merge.
We're just talking about the form field type for MM here! I don't know how MS does their mail merge, but obviously different. So when saving to DOC, the current exporter - at some point - converts these fileds to text.
I remember a bug, where someone complained he couldn't use a DOC for MM. Same reason.
And I was told there is nothing we can do about it.
So please validate my information and test them ;-)
And probably close this bug.
Jan-Marek : spot on 8 You hit the nail on the head :-)
I confirmed a duplicate report of the same behaviour this morning, where I noted this inconsistency in behaviour between single file mailmerge to ODT and multiple file mailmerge to ODT.
Confirming, as I reproduced this behaviour this morning in response to another bug report (now to find it and mark it as DUP).
*** Bug 100375 has been marked as a duplicate of this bug. ***
(In reply to Alex Thurgood from comment #11)
> Confirming, as I reproduced this behaviour this morning in response to
> another bug report (now to find it and mark it as DUP).
So if I understand it correct, the issue is that when saved as individual documents, the fields remain fields.. Hmm :)
Changing summary accordingly then.
Thanks for clarifying this!
(In reply to Cor Nouws from comment #13)
> So if I understand it correct, the issue is that when saved as individual
> documents, the fields remain fields.. Hmm :)
> Changing summary accordingly then.
> Thanks for clarifying this!
Yes, thanks Cor, that is exactly it.
Apologies Valdir that I didn't understand the problem earlier!
Great!!! Now the problem will be resolved \o/
Since there were some private mails regarding this bug, I'll add an additional comment.
The problem of this "fix" is not the implementation, MM wise. That would be rather trivial, in regards to the MM code (just extending two if conditionals is my guess, to switch the behavior).
But my concern is the speed of the whole MM process. We spend a lot of time (and money) to speed-optimize MM, so the previous hour long work is now down to minutes for us. While this is probably insignificant for < 500 documents, we use MM to create 10.000+ documents.
And now it becomes a problem: exchanging fields with text additionally forces to create internal copies for every document, as form=>text can't be undone and instead of just updating the fields and saving the document. But even if someone implemented the undo, it would still be additional work costing time, but probably less significant.
I don't see why the current behavior is a bug. Forms are not printed as fields and even removed when generating PDF. I don't see a need to sacrifice speed for consistency here.
The original bug claimed it is a change in LO 4.0, Cor changed it into "inherited from OOo", so from my POV it should be an enhancement and not a regression. I didn't check older versions, when I wrote comment #10, that's why I wrote: please prove me wrong (and set the regression tag).
= Implementation suggestion =
So IMHO, in the end a fix would be to create a new option, like "Force replacement of fields with text", with a sensible description for the users regarding speed and probably even extend the UNO interface for MM.
I can supply some code pointers, if needed.
Created attachment 134947 [details]
This test will generate a file as single Document and as individual Documents in mail merge
This test will generate a file as single Document and as individual Documents.
(In reply to Jan-Marek Glogowski from comment #17)
I suppose that having an export option that would allow to convert fields to their text *on saving*, in filter, would allow to get the desired result without sacrificing the speed. A filter option that would convert *some* (visible) fields, keeping bookmarks and the like?
(In reply to Mike Kaganski from comment #19)
> (In reply to Jan-Marek Glogowski from comment #17)
> I suppose that having an export option that would allow to convert fields to
> their text *on saving*, in filter, would allow to get the desired result
> without sacrificing the speed. A filter option that would convert *some*
> (visible) fields, keeping bookmarks and the like?
Then you would have to implement this feature in all filters, instead of the internal document model. I guess your suggestion would work, but it's a lot of work.
Eventually implementing an undo for "fields => text" would be better. That would be nice to have generally.
An other idea would be a "node only" internal document copy for mail merge, which shares all the meta data, like defaults, styles etc. Currently the SwDoc::CreateCopy creates an individual document with new styles, which has to update all references in the nodes and also re-validates all the document data. It's currently more or less the same then a "copy and paste" between documents.
If bug 80786 would be implemented, that could make life here a bit easier maybe.