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 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.
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 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.
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 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.
(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.
I think we should proceed with this. Whoever complains will adjust a script, and we will get it unified and logical.
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
Dear Timur, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug