works OK in 2.4.0 > Regression
plus, iirc, cmc has to be in cc - sone

'sone' = 'done', of course :-\

In the mean time I doubt if this has to do with the mail merge wizard.
I see that the mail settings (Tools|Options|Writer|Mail Merge E-mail) that work
in 2.4.0, do not work in 300m14.
Maybe different (sub-)component?

Reassigned to HI.

HI->cmc: Should be double to 85388.

Does it bother anyone at all that the code wasn't touched in all the time frame
from where it "worked" to where it "didn't work", or is this just a dumping exercise

What platform is this ?

@Caolan: Win XP SP2
 ( And that the code wasn't touched, does not necessarily mean that there is
nothing in it, that interacts with a change on another place. Might be
hypothetical, but nevertheless.. ;-) )

Well this will have to be reproducable on linux for me to do anything about it
as I've no windows

Hi Caolan,

Managed ;-) to install 3.0 Beta on SUSE.
The bug does not occur on that OS, so we must find another way to find out what
is happening.
Is a mail to dev@framework.OOo appropriate??
Thanks - Cor

It's only a fairly simple python script itself. I wonder if under windows the
stderr stuff works, e.g. find mailmerge py in the program dir and with a
texteditor change dbg = False to dbg = True and run office from a cmd window and
see does it say anything at all

I've tested as suggested, but noticed no difference.
Do I have to give a certain argument when starting soffice.exe from the cmd window?

So I installed the OOo beta under windows xp under qemu and test "test settings"
appeared to work for me.

So can you take the attached mailmerge.py and copy it over the original
mailmerge.py with it, you should find it in c:\Program
Files\OpenOffice.org\Basis 3.0\Program (please check to make sure it is already
there, just to double check anything unusual that might be relevant) 

Then do the test settings and a file should be created as 

c:\mailmerge.log

attach that file here then and that might give us some debugging information to
check against. I'll attach my own one for reference

Created attachment 54087 [details]
sample replacement. Copy the old one somewhere safe

Created attachment 54088 [details]
and what my log looked like

*** Issue 85388 has been marked as a duplicate of this issue. ***

any change you could try the replacement debugging script and see what gets logged ?

*** Issue 90709 has been marked as a duplicate of this issue. ***

cmc->tml: As our resident windows hacker, any chance you can reproduce this
windows problem, and see if the replacement .py is able to capture any information ?

@cmc: a pity that the things we tried/ discussed (by mail) didn't help so far
@tml: if any info of what/how I tested can be of help, pls let me know

I see this same problem on Ubuntu in OOO 2.4.1

Hi Tim,
I could not reproduce with 2.4.x / 3.0Dev on Linux.
Which OOo vesion do you have? The official build from Sun, or the one shipped
with Ubuntu?

I have the version from Ubuntu, probably hardy-updates.
not only is the "test settings" option broken, but the email sending of mail
merge also fails. It just stops. No progress in sendin mails. So this bug is
more serious than it seems, because the entire fuctionality of email merge is
broken.

I am encouraged that you can't reproduce this. I thought that it must be an SMTP
server problem.However, in Evolution I can configure my SMTP server as port 25
with no security, and it happily sends mail. Openoffice mail merge fails. No
error messages, it just hangs. I assume you realise that this is different to
sending mail in OpenOffice writer from the  File menu, because the mail-merge
feature attempts to connect directly with an SMTP server. From google I see that
many people are reporting the same problem as me. So I am puzzled that you can't
reproduce it. Could you give some more details of your settings? Which port,
what type of server authentication did you set up?

The advice on
http://documentation.openoffice.org/HOW_TO/word_processing/Email_mailmerge.pdf
seems to help.

I used the command

sudo unopkg add --shared /usr/lib/openoffice/program/mailmerge.py

that being the path to mailmerge.py. After doing this OO was able to connect to
the smtp server.

However, I still could not send the emails. I got the following error:

<class 'smtplib.SMTPServerDisconnected'>: Connection unexpectedly closed,
traceback follows
  /usr/lib/python2.5/smtplib.py:355 in function getreply() [raise
SMTPServerDisconnected("Connection unexpectedly closed")]
  /usr/lib/python2.5/smtplib.py:378 in function docmd() [return self.getreply()]

Ubuntu Hardy KDE OO v2.4.1

Also broken Debian/sid. I filed a bug report there.

In Ubuntu 8.04

sudo unopkg add --shared /usr/lib/openoffice/program/mailmerge.py

fixed the problem. I can connect to the server and send email, even with SSL
connection security enabled.

for sake of completeness, the workaround fixes Debian/Sid as well.
Opinion of the Debian maintainer is that this is an upstream problem.

Running OO 2.4.1 if have been able to get it to start the merge then it freezes
locking the whole program. Running on Hardy 8.04 I think it may have something
to do with the Writer.xcu file, not sure though as I have played with the true
and false on all the options

This issue has no target set but is considered a OOo 3.0 Final blocker... 
Can someone please sort out if this a reproducible problem (in DEV300...) that
affects users in large scale AND that can be fixed with agreeable amount of risk
before OOo 3.0 final?
Put Jacqueline on CC.

I'm sorry, I can't reproduce this problem. Tried with BEA300 m2, DEV300 m19 and
DEV300 m25 - Win XP. Sending E-Mails via Mail Merge works fine here.

Made enthusiastic ;) by Jacqueline's test result, I tested again on Win XP.
This time with Dev300_m23. And everything works OK there.
So seems solved for me, but without anyone knowing how.. Also in the mean time
there are quite some others that reported the problem. So I'm a bit cautious.

SBA: Since the initial submitter can not reproduce this, I set this one to
"Worksforme".
Set Target to OOo 3.1. Remove link to show stopper issue.

Feel free to submit a new issue if you can offer a clear reliable reproduction
in DEV300_m26 or younger and name the ID in here. Having this issue "mutate
further" makes not much sense.

I h*te this kind of bugs that cost me hours to test, not finding a soluting and
just disappearing in the mist :-(  (Sorry, had to relieve my feelings)
But of course I agree with target 3.1. 
My intention is to close this issue, if I do not find the bug in any of the next
builds before 3.0-final.

SBA->Cor: I agree to close this one. I was just waiting for you to propose it :-)

I understand that nailing down an issue sometimes can cost time. Without a
"valuable outcome" in terms of "a real issue to fix" this might be unsatisfying.
But on the other hand... How often is the reproduction two- or three-clicks, but
for the developer days to riddle and fix... Yes I also prefer those, too. But
counting in larger numbers, they do co-exist with the vanishing ones like this.
Recent examples for "the easier part for the tester" are 91928 and 91643... :-)

*** Issue 85454 has been marked as a duplicate of this issue. ***