Bug 76226

Summary: enhance documentation on mail merge fields
Product: LibreOffice Reporter: publicface
Component: WriterAssignee: Not Assigned <libreoffice-bugs>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: medium CC: gautier.sophie, iplaw67
Version: 4.1.5.3 release   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description publicface 2014-03-16 07:50:16 UTC
ubuntu 12.04

I created a google spreadsheet and downloaded it as a CSV file.
I used that as the source of my mailmerge data (presumably using "base" is the only way to use the CSV file, so that's what I did).

I then entered various Fields from this CSV file (now converted to a "base" file by the mail merge wizard) into my Writer document for purposes of mail merge.  The end result mail merge post processed document has the field names, no values.  The original document with the fields, does not act as if it has fields - in other words, it's just plain text, not the fields I inserted.

Example:  I inserted "Sellers Aggregate1.Sheet1.Owner's Street Address" (a real field) as a field into the doc, and instead of acting like a field, it acts like normal text.  Perhaps the spaces, periods, apostrophes and/or the length of the field name are causing the problem??

This is a critical problem for me; I suppose I can try one of the fields without spaces or apostrophes... and I guess I can edit the periods out of the downloaded CSV file google creates and see if that helps, but even _IF_ it works it's not a long term solution.

Thank you in advance.
Comment 1 publicface 2014-03-16 08:06:05 UTC
I just realized that one of my fields is "normal", in that there are no spaces or apostrophes.  I went into the CSV file, and it appears that there are no periods in any of the variable names... so I'm not sure where they're coming from, which means I can't remove the periods.  In fact, the CSV file appears completely normal in that it has simply (for example)  city,state,zip,county instead of what appears in the file as a field, such as: "Sellers Aggregate1.Sheet1.County".

"Sellers" is the name of the google file.  Aggregate1 is the name of the sheet in the file.  I just realized these names & periods are coming from the mail merge mechanism, so I guess it's not the periods.

Here's a portion of the CSV file: Owner's Street Address,Owner's City,Owner's State,Owner's Zip,
Comment 2 sophie 2014-03-17 16:46:45 UTC
Could you provide the .csv (without confidential data) and the .odt file in order to be able to reproduce your problem? thanks in advance.
Lowering the importance because it's not a MAB, set as Needinfo - Sophie
Comment 3 publicface 2014-03-19 02:38:12 UTC
The problem is apparently that I was starting from a .doc file, not .odt
I would suggest that a warning message be produced if someone tries to use fields with .doc format files and to simply disallow it, so that people don't waste their time like I did.  

I wasted over 10 hours on this.  Having to do that did not make me think so highly of the product.  Being forced to use .odt format in order to use fields does not endear me to the product, but knowing that's what is required is better than wasting all that time.  

Most people would have given up and dumped the product had they been required to go through what I went through.
Comment 4 sophie 2014-03-19 11:07:37 UTC
Hi, there is a lot of documentation in several languages on the wiki about mail merge feature, may be reading it will help not wasting your time. Note also that you can create a csv file from LibreOffice. 
Setting has enhancement, lowering priority - Sophie
Comment 5 Alex Thurgood 2014-03-19 16:37:47 UTC
Hi Sophie,

Unfortunately, even using a meta search engine like DuckDuckGo or Google brings the user no further. If I enter "libreoffice" "wiki" "mailmerge" with or without the extra "Word" expression, I get absolutely nothing that tells me that one has to base one's mailmerge on a Writer document.

The built-in help is completely silent on the matter.

The official documentation is also AWOL in this regard.

So definitely a valid enhancement request :-)


Alex
Comment 6 publicface 2014-03-19 17:02:08 UTC
Documenting it is good.  In addition, what I'm requesting is that the code be changed so that the user receives a warning - better, an error message, ideally with a link to that new documentation.  There's nothing worse than spinning your wheels on a feature that doesn't exist, but appears as if it does until the very last moment in time when you attempt to make use of your work.


Some other additions to the docs that I discovered by pain and error:

After running the mail merge, the fields appear to be overwritten with data.  I've found that the fields can be "reset" so the data is purged from the fields by Edit > Exchange Database.  Probably a side effect, but a useful one.

I've also found that if the fields are changed in the original (now new) CSV file then this seems to be what's required:

First delete the old database file registration:

Tools > Options > Base > Databases > Select > Delete (/home/username/path/to/db/DB.odb) > Yes > OK


File > New > Database > Connect Existing > Text > (/home/username/path/to/CSVfile/) > Select > CSV > Next > Register > Finish > DB.odb


where DB is the filename you choose, and path is your desired path (obviously?).

Here is what appears to be a nice tutorial on how to mail merge. https://beginlinux.com/blog/2013/03/mailmerge-on-openoffice-and-libreoffice/
I can't vouch for it as I didn't really read it, I simply grabbed one piece of info out of the middle, but the pictures look accurate based on the 3 seconds I spent looking at them.

Maybe this will help someone else and maybe someone will incorporate some of this info. into the help files.  This represents hours of trial & error and research and painful head banging, hair ripping, teeth gnashing and cussing and screaming.
Comment 7 Alex Thurgood 2015-01-03 17:39:04 UTC
Adding self to CC if not already on

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.