Issue 121143 - emailing wizard: sending has behavior random
emailing wizard: sending has behavior random
Status: VERIFIED FIXED
Product: Writer
Classification: Application
Component: save-export
3.4.1
All Windows 7
: P3 normal with 4 votes (vote)
: 4.0.0
Assigned To: Oliver-Rainer Wittmann
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-01 10:05 UTC by oooforum
Modified: 2013-07-10 06:38 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---
jsc: 4.0.0_release_blocker+


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description oooforum 2012-10-01 10:05:46 UTC
Steps to reproduce: 
Use Base
- create an ODB with one table ID | Email
- input 20 records with one email of your choice
1 | your_name @ domain.com
2 | your_name @ domain.com
...
20 | your_name @ domain.com

Now, use Writer 
- attach your ODB with Edit > Exchange database
- run mailmerge wizard
- choose "e-mail message" (step 2)
- go to step 8 (Writer generated 20 documents)
- choose "send merged document as e-mail"
- select email item as "To" field
- input a subject
- leave "send all documents" option
- push "Send documents" button
Sending dialogbox appears
Expected behavior: 20 of 20 e-mails sent
Actual behavior: this number is random (only 14 or 15 max)
Comment 1 oooforum 2012-10-01 14:47:04 UTC
This problem occurs only with Windows system.
Tested with:
- XP SP3 > NOK
- 7 Pro x64 > NOK

The result is correct with Debian Squeeze 6.0.5
Comment 2 cabrat 2013-01-11 18:00:02 UTC
I have two software identical systems (same Win7 Same OO) which behave differently.  System with 2GHz Sempron and 2GB has trouble actually merging, best results obtained by quitting all other applications and waiting ten seconds, but it manages to send large numbers of emails.  New system with Windows performance index in the 7s and 8GB shows random email sending behaviour as this bug except I've never got it to send more than 6 emails.  Perhaps all this shows basic problem between mailmerge and Windows?  If I cannot send emails to a mailmerge list using OO then I have to find an alternative mass emailer, this is a fundamental business need in 2013 and therefore this bug NEEDS PRIORITY.  It is not difficult to reproduce, my simplest test case with ten records in OO spreadsheet shows the problem every time.
Comment 3 Ariel Constenla-Haile 2013-01-11 19:24:53 UTC
Confirmed on Windows XP

a) Data source:

* Create a spreadsheet with two columns: NAME - EMAIL
* In cell A2 type Name1, select the cell right bottom corner and drag it to cell A51 so that the column is filled with fifty records names Name1 - Name50
* In cell B2 enter a valid email address, and drag it to B51, so that all rows have the same mail adress

Save this spreadsheet and use it as data source for a mail merge in Writer.

b) Mail merge document:

* Insert a database field: select on "Type" - "Mail merge fields", and on "Database selection" select the NAME column from the spreadsheet described above
This way you can test which mails are sent and which not, because every mail will have a "NameN" on its body

* Select the mail merge wizard:

- step 1: Use the current document
- step 2: E-mail message
- step 8: Send merged document as E-mail

E-mail settings:

To: EMAIL  <== the srpeadsheet column
Subject: Dummy subject
Send as: HTML Message

Check "Send all documents"
Press the "Send document" push buttons.


Result
===================

The wizard displays it sent 38 out of 50 mails.

Checking in the mail box where all the mails were sent, the following mails are missing:

Name5, Name9, Name15, Name20, Name22, Name26, Name30, Name32, Name42, Name43, Name49, Name50

Unsent: 12
Total to send: 50
Sent: 38
Comment 4 Ariel Constenla-Haile 2013-01-21 14:33:01 UTC
The problem isn't in the mail service component (mailmerge.py), but in the application code.

On a non-pro build there is an assertion in sw/source/ui/dbui/mmoutputpage.cxx
http://svn.apache.org/viewvc/openoffice/trunk/main/sw/source/ui/dbui/mmoutputpage.cxx?revision=1413471&view=markup#l1340

The file is first exported, with writer8 filter, to sTargetTempURL, then for each merged file an HTML document is created (SfxStringItem aName). When creating an SfxMedium from this file, it has no input stream.

This misbehavior is reproducible also when exporting the document as plain text mail body.

When attaching the document as PDF, some mails have a 0 bytes PDF, this might be a related bug.
Comment 5 cabrat 2013-01-21 17:31:04 UTC
(In reply to comment #4)
> The problem isn't in the mail service component (mailmerge.py), but in the
> application code.
> 
> On a non-pro build there is an assertion in
> sw/source/ui/dbui/mmoutputpage.cxx
> http://svn.apache.org/viewvc/openoffice/trunk/main/sw/source/ui/dbui/
> mmoutputpage.cxx?revision=1413471&view=markup#l1340
> 
> The file is first exported, with writer8 filter, to sTargetTempURL, then for
> each merged file an HTML document is created (SfxStringItem aName). When
> creating an SfxMedium from this file, it has no input stream.
> 
> This misbehavior is reproducible also when exporting the document as plain
> text mail body.
> 
> When attaching the document as PDF, some mails have a 0 bytes PDF, this
> might be a related bug.

Does this also explain failure to merge with incomplete display of mailmerge window?
Comment 6 Ariel Constenla-Haile 2013-01-21 19:07:15 UTC
(In reply to comment #5)
> Does this also explain failure to merge with incomplete display of mailmerge
> window?

this explains the error as described in comment 3

What do you mean by "incomplete display of mailmerge window"? Is the same as described in comment 3 or a different bug? The empty (0 bytes length) PDF attachments might be something different, for example.
Comment 7 cabrat 2013-01-21 20:06:33 UTC
Not same, on my old system I have had a repeatable fault whereby after clicking Mail Merge Wizard it displays only the frame of the mail merge menu window and usually hangs.  The workaround for this fault was to close all other applications and wait some seconds before initiating the merge.
Comment 8 oooforum 2013-06-04 09:31:13 UTC
Still occurs in 4.0 rev. 1488886
Comment 9 cabrat 2013-06-05 09:00:06 UTC
Recommend G-Lock Software EasyMail for mass emailing until this is fixed, the free version will probably do for most cases where one would want to use OpenOffice to merge and send emails.
Comment 10 oooforum 2013-06-06 13:44:30 UTC
G-Lock Software EasyMail is not free of charge. :-(
Very resticted: no Mac or Linux version is available.
Comment 11 cabrat 2013-06-06 15:37:55 UTC
(In reply to oooforum from comment #10)
> G-Lock Software EasyMail is not free of charge. :-(
> Very resticted: no Mac or Linux version is available.

There is a free version which meets my needs and probably those of other small users of mass emailing.  I understand this bug does not occur under Linux (not sure about Mac?) so absence of a Linux version is hardly an issue. But I'd much rather have OO email merge fixed.
Comment 12 jsc 2013-06-24 12:20:32 UTC
set showstopper flag
Comment 13 Oliver-Rainer Wittmann 2013-06-27 11:44:14 UTC
taking over to indicate that I will have a closer look
Comment 14 Oliver-Rainer Wittmann 2013-06-27 13:50:01 UTC
I have reproduced the defect on my Windows XP VM with recent snapshot build.

I also reproduced the defect on my Windows 7 machine with AOO 3.4.1 and the recent snapshot build.

But, I was not able to reproduce the defect according oooforum's or Ariel's description on my Windows 7 machine with my local non-pro build. Damn, how should I debug the problem now.
Comment 15 Oliver-Rainer Wittmann 2013-06-28 14:26:32 UTC
I found the root cause.

The documents created for each Mail Merge instance are using temporary file names. For storing file also temporary file names are used. As figured out, it could happen that the file name for Mail Merge instance collides with internally used temporary file name. In this case the document storing of the Mail Merge instances fails. It looks like that it happens when the machine is fast enough.

Working on a solution.
Comment 16 SVN Robot 2013-07-01 10:03:12 UTC
"orw" committed SVN revision 1498343 into trunk:
121143: SfxMedium - assure that name of internal used temporary file does not...
Comment 17 Oliver-Rainer Wittmann 2013-07-01 10:25:10 UTC
fixed on trunk for AOO 4.0
Comment 18 fanyuzhen 2013-07-10 06:38:57 UTC
It's verified fixed in revision 1499347