Bug 102010 - MAILMERGE: Output Filename changed using CLI_UNO
Summary: MAILMERGE: Output Filename changed using CLI_UNO
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.4.0 target:5.3.0.1 target:5.2.5
Keywords: bisected, patch, regression
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
 
Reported: 2016-09-09 07:18 UTC by PAlex
Modified: 2016-12-07 08:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
bisect log for this bug (2.27 KB, text/x-log)
2016-10-14 14:12 UTC, Alex Kempshall
Details
git diff patch for bug 102010 (876 bytes, patch)
2016-11-07 10:58 UTC, Alex Kempshall
Details

Note You need to log in before you can comment on or make changes to this bug.
Description PAlex 2016-09-09 07:18:03 UTC
Hello,

Until LO5.1.2.2 when we merge a "test.odt" file, output mailmerge files were called "test.odt0.odt" (and "test.odt1.odt" for the next time, and so on). They were having a good extension and preserved overwrite.

With LO5.2.0.4, we just have a "test.odt.updated" file. No "odt" final extension and file is now overwritten for each merge.
Comment 1 PAlex 2016-09-09 07:33:21 UTC
LO5.2.1.2 has the same behaviors as LO5.2.0.4.
Comment 2 Jan-Marek Glogowski 2016-10-03 08:13:49 UTC
I did a lot of changes to MM in January, and I have the feeling, that

commit e637b6743a506ef74c93ccbe15ab6642f3baa34f
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date:   Thu Mar 24 13:43:46 2016 +0100

    MM: move email subject and address into descriptor

broke your setup.

From the subject I guess you call MM via .NET on Windows, which I don't have, but quite probably also don't need.

I have some ideas about your parameters, but since MM is quite complex with many options and I don't want to test all variants, please provide the exact UNO argument list you use in your call of the MM job execute function.
Comment 3 PAlex 2016-10-03 13:19:26 UTC
(In reply to Jan-Marek Glogowski from comment #2)

Indeed, we use .NET on Windows.
Our parameters weren't changed :
We use a "DataSourceName", a "Command" as table name and a "CommandType" set on a unoidl.com.sun.star.sdb.CommandType.TABLE (0).

For output, we're targeting a path :
"OutputType" as unoidl.com.sun.star.text.MailMergeType.FILE (2)
"OutputURL", for example "file:///D:/LO52/"
"SaveAsSingleFile" set as true.

Finally our ready-to-merge document :
"DocumentURL", for example "file:///D:/LO52/test.odt.updated.odt"

Under LO5.2.0.4, MM execute produces "D:\LO52\test.odt.updated"

Thanks !
Comment 4 Alex Kempshall 2016-10-05 06:55:20 UTC
I'm seeing this problem in 5.2.2.2 and in 5.3.0.0.alpha0+ Master, when running a basic macro in Base which is expected to produce a merged file from a dataset pulled from MariaDB. 

What I get is a file called CompanyMerged when I'm expecting a file called CompanyMerged0.odt

This problem wasn't present in 5.1.5.2 when I get the expected file CompanyMerged0.odt 

I've also replicated the problem using a macro in Writer using the following code. In this code I've changed the FileNamePrefix so the file won't get overwritten each time.


	Dim oMailMerge as Object
	Dim DirectoryName as String

    DirectoryName = DirectoryNameoutofPath(ThisComponent.getURL(), "/") & "/"
    
	If (Not GlobalScope.BasicLibraries.isLibraryLoaded("Tools")) Then
	   GlobalScope.BasicLibraries.LoadLibrary("Tools")
	End If
	
	oMailMerge = CreateUnoService("com.sun.star.text.MailMerge")
	oMailMerge.DataSourceName =  "CompanySeed"
	oMailMerge.DocumentURL =  ConvertToUrl(DirectoryName & "CompanySeed.odt")
	oMailMerge.CommandType = 0
	oMailMerge.Command = "CompanySeed"
	oMailMerge.OutputType = com.sun.star.text.MailMergeType.FILE
	oMailMerge.OutputUrl = ConvertToUrl(DirectoryName)
	oMailMerge.FileNamePrefix = "Merged-" &  Format(Now, "yyyymmddHHMMSS") & "-"
	oMailMerge.SaveAsSingleFile=True
	oMailMerge.FileNameFromColumn=False
	oMailMerge.Filter=""
	
	oMailMerge.execute(Array())
	
	oMailMerge.dispose()


The above code needs the data and the starting file setting up first. I'm finding it easier to create these using the Mail Merge Wizard. 

Alex
Comment 5 Alex Kempshall 2016-10-05 07:35:41 UTC
In the code above the lines 

DirectoryName = DirectoryNameoutofPath(ThisComponent.getURL(), "/") & "/"
    
If (Not GlobalScope.BasicLibraries.isLibraryLoaded("Tools")) Then
   GlobalScope.BasicLibraries.LoadLibrary("Tools")
End If



should be swapped to read

  
If (Not GlobalScope.BasicLibraries.isLibraryLoaded("Tools")) Then
   GlobalScope.BasicLibraries.LoadLibrary("Tools")
End If

DirectoryName = DirectoryNameoutofPath(ThisComponent.getURL(), "/") & "/"



Alex
Comment 6 Alex Kempshall 2016-10-14 14:12:11 UTC
Created attachment 128011 [details]
bisect log for this bug
Comment 7 Xisco Faulí 2016-10-14 20:16:35 UTC
Changing it to NEW as the problematic commit has been identified.
Comment 8 Alex Kempshall 2016-11-07 10:58:08 UTC
Created attachment 128544 [details]
git diff patch for bug 102010
Comment 9 Alex Kempshall 2016-11-07 11:02:46 UTC
I've attached a proposed patch for bug 102010. It works for me!

Though it does make a nonsense of the conditional statement as now both legs are the same. 

           if( rMergeDescriptor.sPath.isEmpty() )
                aTempFileURL.SetURL( aTempFile->GetURL() );
            else
                aTempFileURL.SetURL( aTempFile->GetURL() );


So clearly I need to clarify my understanding of what this condition statement is supposed to achieve.
Comment 10 Xisco Faulí 2016-11-07 12:51:21 UTC
Hi Alex,
Thanks for submitting the patch. Could you please submit it to gerrit directly?
More info: https://wiki.documentfoundation.org/Development/gerrit/SubmitPatch
Comment 11 Alex Kempshall 2016-11-24 16:52:30 UTC
 Jan-Marek Glogowski has supplied a private patch which I've tested these tests successfully -

1. Saving as multiple files with prefix - Success
2. Saving as multiple files with no prefix - Success
3. Saving as a single file with prefix - Success
4. Saving as a single file with no prefix - Success

Alex
Comment 12 Commit Notification 2016-11-25 15:29:53 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bbf246e40c7814bfc4038d456d388d1f90048287

tdf#102010 Never overwrite MM files via UNO

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Commit Notification 2016-11-28 08:47:33 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b4b60b2d81452c79ece99c51f63199b7dcf4b1d&h=libreoffice-5-3

tdf#102010 Never overwrite MM files via UNO

It will be available in 5.3.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Alex Kempshall 2016-11-30 14:08:56 UTC
I've done a git pull on master and tested got the expected results. So tick in the box here.

Can't find a daily build for 5.3.0.1 so can't test this. Can someone advise?
Comment 15 Jan-Marek Glogowski 2016-12-01 10:30:40 UTC
There is now a libreoffice-5-3 build available @ http://dev-builds.libreoffice.org/daily/libreoffice-5-3/
Comment 16 Alex Kempshall 2016-12-05 08:01:28 UTC
Downloaded daily build and tested successfully

Version: 5.3.0.0.beta1+
Build ID: c7e7a634cf5941fffd97102fe4252aee7445e36b
Comment 17 Commit Notification 2016-12-07 08:58:28 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c2dae8259bf666d906b4d0c1ccd64aa14c6500c&h=libreoffice-5-2

tdf#102010 Never overwrite MM files via UNO

It will be available in 5.2.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.