In bug 109120, Mailmerge for individual documents was fixed to start filenames from 1 (one), not 0 (zero), for using Mail Merge toolbar.
Same problem with another approach, using simple File-Print.
1. make a merge document or use ODT attachment 166250 [details] from bug 119942
2. save ODS attachment 166251 [details] to the same folder
3. open ODT and File-Print
4. Yes to Do you want to print a form letter.
5. Output: File - Save as individual documents, turn off "Generate file name..".
Reproduced: name0, name1....
Expected: name_1, name_2.....
Apart from fixing 0, there should be underscore just to be consistent with toolbar approach.
Note: I didn't check previous versions, but I doubt this is a regression, rather Inherited.
Created attachment 174948 [details]
The example document and the result of a former generation in the Save dialog
Version: 126.96.36.199.alpha0+ (x64) / LibreOffice Community
Build ID: c7b5e6566d9b24a0a996c739a945004d9aadee2f
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Leaving the Generate name from database option turned off asks for a custom file name, which gets numbered starting from 0 and no underscore between the entered name and the number.
This numbering comes from dbmgr.cxx
aTempFile.reset( new utl::TempFile(sLeading, sColumnData.isEmpty(), &sExt, &sPrefix, true) );
where sColumnData.isEmpty() /*which means this is not a generated name*/ provides _bStartWithZero.
So to do this, we need to extend TempFile and SequentialTokens to accept provided starting values instead of automatically starting with 0. (Well, on the other hand we could just start EVERY use of the general utility TempFile at 1, but that is not a very targeted case and may break many assumptions...)
Another easier option would be to always set _bStartWithZero to false.
In this case it would export
But I don't think that would be terribly helpful because then 1 is actually the second record. Yeah - that really isn't different from the zero case except that we don't have an explicit zero. So bad idea.
P.S. CppunitTest_sw_mailmerge fails if starting m_value(1) instead of zero.
proposed fix http://gerrit.libreoffice.org/c/core/+/122489 tdf#144215 mailmerge: start individual document at 1, not 0
Adding the _ can be added separately.
Adding the _ is probably too tricky to be worth it since a simple attempt to do so breaks lots of unit tests.
At the time of defining the filename, it cannot be known whether a number will be used or not. So really it would require adding another variable to TempFile to allow for an optional a numberPrefix. That kind of complexity would require a more compelling reason.
Justin, thanks for looking into this. If numbers are ok, underscore can be disregarded (while not clear how it works in bug 109120).
Please see discussion at bug 14448 and if you think that there should be a single code for mail merge.
(In reply to Timur from comment #5)
> Please see discussion at bug 14448
The mail merge wizard seems to design a name without worrying about whether it will trample over existing files. This wizard very carefully makes sure it creates a unique file. So you are NOT guaranteed that the first record will be file1.odt. It could be file17.odt if 1-16 already existed.
So this is a completely different (and very generic) code path we are dealing with.
(In reply to Justin L from comment #6)
> (In reply to Timur from comment #5)
> > Please see discussion at bug 14448
> bug what?
Sorry, bug 144483.
Based on review "Last time I did something like this, some people complained about failing scripts via UNO MM. You'll probably get new bugs as a regression." I abandoned https://gerrit.libreoffice.org/c/core/+/122489.