Bug 144215 - MAILMERGE: if saved as individual documents - filenames should start from 1 (one), not 0 (zero), also for Print
Summary: MAILMERGE: if saved as individual documents - filenames should start from 1 (...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
 
Reported: 2021-08-31 11:58 UTC by Timur
Modified: 2022-09-15 09:34 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
The example document and the result of a former generation in the Save dialog (110.63 KB, image/png)
2021-09-10 09:11 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2021-08-31 11:58:33 UTC
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.
Comment 1 NISZ LibreOffice Team 2021-09-10 09:11:40 UTC
Created attachment 174948 [details]
The example document and the result of a former generation in the Save dialog

Confirming with:

Version: 7.3.0.0.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
Calc: CL

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.
Comment 2 Justin L 2021-09-22 11:16:54 UTC
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...)
Comment 3 Justin L 2021-09-22 19:13:52 UTC
Another easier option would be to always set _bStartWithZero to false.

In this case it would export
file.odt
file1.odt
file2.odt
...

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.
Comment 4 Justin L 2021-09-23 10:00:57 UTC
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.
Comment 5 Timur 2021-09-23 11:34:52 UTC
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.
Comment 6 Justin L 2021-09-23 11:45:06 UTC
(In reply to Timur from comment #5)
> Please see discussion at bug 14448 
bug what?

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.
Comment 7 Timur 2021-09-23 13:41:35 UTC
(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.
Comment 8 Justin L 2021-10-01 17:57:45 UTC
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.
Comment 9 Timur 2022-09-14 09:16:44 UTC
I think we should proceed with this. 
Whoever complains will adjust a script, and we will get it unified and logical.
Comment 10 Mike Kaganski 2022-09-15 09:34:35 UTC
Note that it's actually likely that at some point, we would get rid of the separate processing happening in SwMMResultSaveDialog::SaveOutputHdl_Impl (and other handlers there), that makes the mail merge toolbar buttons results different from doing the same things from the form letter dialog (that is called when you "print") - see commit message at https://gerrit.libreoffice.org/c/core/+/139973. This would, incidentally, also undo the fix for bug 109120, and will also make these two functions "unified" (indeed, "logical" is subjective).

MailMerge Service [1] does not specify a specific scheme how the suffix is generated from OutputURL when SaveAsSingleFile is false, so the change would not be an API change; but indeed, this would likely to break lots of user code, and create lots of complaints ... I'd say, WONTFIX for safety (but indeed, if anyone is ready to take all the blame, go ahead ;)).

[1] https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1text_1_1MailMerge.html