Closed Bug 319714 Opened 19 years ago Closed 15 years ago

MAPI attachment bug causes MYOB Accounting Plus 15 to email incorrect PDF invoices/statements to customers

Categories

(MailNews Core :: Simple MAPI, defect)

Product:
MailNews Core
Component:
Simple MAPI
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 356808

People

(Reporter: sigurd, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/416.11 (KHTML, like Gecko) Safari/416.12
Build Identifier: v1.07

(First raised at http://forums.mozillazine.org/viewtopic.php?t=352017 but no replies :S )

I am using the MYOB Accounting Plus (v15) package with Thunderbird so that invoices and statements are sent out via MAPI. While it works better than Outlook Express in many regards (e.g. I can disable a constant confirmation that I want to allow the email client to send an email from MYOB), it acknowledged bugginess (http://kb.mozillazine.org/MAPI_Support) means I've had a couple of disasterious scenarios. I'd much prefer to keep Thunderbird as my default mail client, but while I do so, I am greatly limiting my ability to use MYOB.

If I use MYOB to send out multiple invoices or statements in a batch (which is much of the time), Thunderbird confuses which attachment goes with which email. Specifically, which ever attachment (i.e invoice or statement) is sent in the first email, becomes the attachment for all other emails. This means that the second and all further customers receives the wrong invoice or statement... terrible!

I am curious to learn whether this individual issue would be looked at and fixed now; or whether it would need to wait for an overhaul or extension to the MAPI support. It would obviously be wonderful it could be included in an imminent release, as currently it cannot really be claimed it "works" with MYOB.

Apparently is all that is needed for MYOB, is Simple MAPI, as I've been told this is all Outlook Express supports, and that client appears to work fine. 

As a side note: In the mean time, we should realise that the fact there is inconsistent support of MAPI, people like me will expect things work, and only find out it doesn't upon potentially disasterious circumstances. It could be useful, for example, that the prompt to confirm whether an email is going be sent through Thunderbird, that it is made obvious that MAPI support is not yet complete, and that the user ought to safely test what they want to do, before trying it in a commercial or other serious way. This would have saved me the embaressment of my customers being sent revealing information about other customers.

Reproducible: Always

Steps to Reproduce:
1. Ensure thunderbird configured to be default email client so that MAPI calls are sent to it
2. In MYOB, create an invoice and set delivery status to "Email" (don't actually email it now, just choose Email from the drop-down list)
3. Create two more invoices for different cards (customers) and set them also to delivered by Email
4. At the main sales window, go to "Print/email invoices", and go to the "Email" tab.
5. Tick beside each of the invoices to indicate you want to email all 3 invoices.
6. You may want to sent the email address to your own for all 3 cards (customers) for testing purposes
7. Click "Send Emails"
8. Thunderbird should promt you to confirm whether you wish to send the emails (unless you've prevented the confirmation in its configuration)
9. MYOB should revert back to the main sales page when done, with no real indication of success or failure. (I believe this is normal)
Actual Results:  
The three emails that were sent to each customer will have subject lines indicating the invoice number (e.g. "Invoice #1208; From CompanyName Ltd") . It will also have a small plain text message in the body which you can refine in step 5, but the problem lies in the ESale.pdf attachment. In all three emails, the attachment will be identical--the attachment always is the one from the initially sent invoice.

Expected Results:  
In the three emails the attached ESale.pdf ought to be different; they should match the invoice numbers indicated by the subject line. If you send one invoice (tick 1 invoice, click send, tick 1, send, tick 1, send etc) out at a time the correct PDF is attached, however this is a greatly inefficient process if you have dozens to send out.

This also effects the sending of statements. In the print/email statements area, tick 2 or more statements to send, and youll find the EStatement.PDF (I think it is) is the same attachment in every email.

The use of a differnet email client such as Outlook Express on my PC makes the problem dissapear. MYOB staff have also inspected my company file and set up and had no problems with Lotus Notes (this was on their PC).

It is possible that the attachment filename being the same in each email contributes to the issue.

I have replicated this on 2 different machines.
I can confirm this problem.

Our application has a similar functionality, and the problem is definitely the filename being the same on each attachment.

Our application uses the option to show the dialog before the message. On Outlook Express, and MS Outlook, the dialogs come up one at a time. ie the next message does not appear until the previous one has either been sent or cancelled. On Thunderbird, several the messages open up all at the same time.
(Not sure if making the message window modal would help the problem?)

It seems as though a copy of the Statement.pdf file attached is getting copied into C:\Documents and Settings\UserName\Local Settings\Temp\moz_mapi\ when the first email is created. When the next one is created, it simply overwrites the existing file.
After sending, the file is deleted from this folder.
Sending the next email results in an error that the attachment could not be found (although one of our users has reported that their messages are sent, but all recipients end up getting the same file)


This problem also applies to reports.  Reports cannot be emailled to clients.

I am an accountant and I want to use Thunderbird and Thunderbird is my default email.  When I try to email reports I continually get a message "an email session could not be started.  Please check your MAPI installation" 

If you could fix this problem it would be appreciated  
I just wanted to do a slight prod, given almost a year has passed and you haven't yet checked to see if it you can reproduce the bug at your end (let alone fixed it). While we wait, we need to use Outlook Express on the computer that has MYOB installed, which is reduces productivity.

I am happy to test the fix when you feel there is something resolved, or try and track down a trial copy of MYOB (presumeably with a limited usage time). (FYI, I have no connection with MYOB other than being a user/customer of it)
Version: unspecified → 1.5
> I am an accountant and I want to use Thunderbird and Thunderbird is my default
> email.  When I try to email reports I continually get a message "an email
> session could not be started.  Please check your MAPI installation" 

Hi "rcneems@swiftdsl.com.au"... "check MAPI installation" sounds like an different problem, which requires you to configure Thunderbird as your default email client. (If it is, then perhaps some registry settings are out of sync). 

Hi "sigurd@silverstripe.com",

"check MAPI installation" is not a different problem. Thunderbird is the default email client and if not already running it will even start up. But that is as far as it goes.  That message unfortunately appears to be the only one MYOB provides when it gets an MAPI error.

The problem "rcneems@swiftdsl.com.au" is seeing is the same one I am seeing.  The MAPI support in Thunderbird appears to have regressed.  I used to be able to use TB's 1.5.0.8 MAPI support with MYOB, then after the 1.5.0.9 release, this error started.  It still exists with TB 1.5.0.10.  Switching to Outlook as the default client, everything works seamlessly.

I still prefer TB as my email client so just have to send email the hard way when using MYOB.
Same problems here with Thunderbird 2.0.0.12 and another application that uses Simple MAPI.

It looks like this bug reemerged: 
https://bugzilla.mozilla.org/show_bug.cgi?id=257682

"If a mapi client does simultaneous mapi sends of messages with the same
attachment name, our temp file code won't handle the fact that we already have a
temp file with the same name. Because the mapi send call returns before we've
actually sent the message, the temp file could still exist from the first call
when we process the second call"
(In reply to comment #0)
> Specifically, which ever attachment (i.e invoice or statement) is sent in the
> first email, becomes the attachment for all other emails. This means that the
> second and all further customers receives the wrong invoice or statement...

Sounds Bug 356919 followed by Bug 356808.
When attached file is "Read Only", phenomenon of Bug 356919 occurs, then Bug 356808 always follows, if same file name(file name of the attached file is used in moz-mapi directory).

(In reply to comment #6)
> "If a mapi client does simultaneous mapi sends of messages with the same
> attachment name, our temp file code won't handle the fact that we already have
> a temp file with the same name.

It is a variation of phenomena by Bug 356808 - problem even when Bug 356919 doesn't occur.
  1. Attach file(version 1)
     => vesion 1 is kept in moz-mapi => Compose window-1(not send at this step)  
  2. Attach file(version 2)
     => vesion 2 is not written in moz-mapi, because version 1(same name) exists
     => Compose window-2 (not send at this step)
  3. Send at compose window-X (X==1 or 2) => file in moz-mapi is deleted
  4. Send at another compose window
     => error because file in moz-mapi is already deleted at step 3.
Assignee: mscott → nobody
I suppose the issue is still present in the 2.0 series and 3.0betas - can anyone confirm ?
Now that bug 356808 as been fixed can anyone having MYOB try Tb 3.0.3
Component: General → Simple MAPI
Product: Thunderbird → MailNews Core
QA Contact: general → simple-mapi
Version: 1.5 → Trunk
Problem exists with TB 2.0.0.23 and MYOB VER 18.5  for emailing payslips.

Randomly attaches the wrong PDF payslip to the wrong employee email address, or send the same payslip to several people, while some are ok.   No logical pattern.

Can we bump this one along, so many MYOB users just plain give up because MYOB support recommend using Outlook, so we MUST stop using TB completely.
(In reply to comment #11)
> Problem exists with TB 2.0.0.23 and MYOB VER 18.5  for emailing payslips.
...
> Can we bump this one along, so many MYOB users just plain give up because MYOB
> support recommend using Outlook, so we MUST stop using TB completely.

As has already been asked in Comment 11, please try Thunderbird 3.0.3 or later (available from http://getthunderbird.com/). That is likely to contain a fix for this issue and is highly unlikely to be back-ported to the Thunderbird 2 builds.
With latest MYOB and TB 3.0.3, MYOB now gives the error "Cannot load MAPI32.dll".  Please install MAPI.
(In reply to comment #13)
> With latest MYOB and TB 3.0.3, MYOB now gives the error "Cannot load
> MAPI32.dll".  Please install MAPI.

Thanks for testing. did you restart TB after the install ?
Yes.  I have been running TB 3.0.3 for a while.  Machine was rebooted as well (thanks to Windows updates :-(
Frank what should we be looking for here ?
There are 1000's of MYOB users that use email MAPI functions. You really can't assume that just because there are only few people like us posting comments that the majority of ordinary users dont have a terminal TB problem. Many MYOB users are bookkeepers that dont even know about forums. They just UNINSTALL it and say TB is useless, then use Outlook as recommended by MYOB support.

Back port should be done, as TB 2.0.x is faster on older machines using a profile over a network, ( aka fast free business email server )and TB MAPI 3.0 does not work either. TB 3.0 is slower to use over a network,as I think it builds an index file for preemptive searching ( much like google or exalead) and this is death over a small business network.

Hope you can see why I think it is important to a few thousand small business users. The vast silent majority just don't know any better.
I know that this is not the right forum, but just to verify the TB3.0 network problem see ( painfully slow, almost unusable )

http://getsatisfaction.com/mozilla_messaging/topics/thunderbird_on_a_home_network

So the TB3.0 option is no option for small business, which is the case with many MAPI users. : (
(In reply to comment #13 thru comment #18 by Paul Smith)

Paul Smith, please don't hi-jack original problem of this bug(dup of Bug 356808 which can be observed with MYOB) by problems you saw when you tried to check fix of Bug 356808 using Tb 3.0.3, MYOB, and MAPI by MYOB.

(Your problem-1) comment #13 :
> With latest MYOB and TB 3.0.3, MYOB now gives the error "Cannot load MAPI32.dll".  Please install MAPI.
Bug 526540 for Seamonkey may be same problem as yours. So, your case is better to be analyzed well.

(Your problem-2) comment #17 : performance related issues of Tb 3.0.x
 At least next issues are already known.
 a) Slowness of Tb 3.0.x for any people.
    Due to new features which consumes much resources(CPU,memory,disk space),
    which are enabled by default upon first use of Tb 3.0.x,
    problem is exposed to user who uses not so new/fast/big PC.
    Search well bugs relate to (i) Global Search and Indexer, (ii) auto-sync
    of all IMAP folders, via "Advanced Search" of "Search" of B/M.O, please.
 b) Slowness of Tb 3.0.x when remote directories/files is used.
    Due to inefficiency in file writing of Tb 3.0(bug),
    slowness is exposed to remote profile users.
    See bug 539389 for this issue.
 c) Slowness of Tb 3.0.x in some cases, if many mail folders are defined.
    If remote profile/remote mail folder is used, the slowness is very easily
    exposed to user. See bug 536873 and bug 545126 for this issue.

(In reply to comment #18)
> I know that this is not the right forum, (snip)

Please note "here is not forum, here is bugzilla.mozilla.org".
If you know, follow a rule of "one problem per a bug" of B.M.O, please.
Paul Smith, please open separe bug for your problem-1, for ease of problem analyis, with crispy problem description and steps to reproduce, with attaching sufficient data for diagnosis.
Blocks: 555667
(In reply to comment #19)
> (In reply to comment #13 thru comment #18 by Paul Smith)
> 
> Paul Smith, please don't hi-jack original problem of this bug(dup of Bug 356808
> which can be observed with MYOB) by problems you saw when you tried to check
> fix of Bug 356808 using Tb 3.0.3, MYOB, and MAPI by MYOB.
> 
> (Your problem-1) comment #13 :
> > With latest MYOB and TB 3.0.3, MYOB now gives the error "Cannot load MAPI32.dll".  Please install MAPI.

Raised bug https://bugzilla.mozilla.org/show_bug.cgi?id=555667 to track that. will close this one as a dup of
No longer blocks: 555667
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Options which I am considering for working around the MAPI problem in a remote profile access Tb server environment ( eg all profiles on central LAN PC + terminal server access too):

1. Use Outlook express on Tb server for MAPI functions, then send email back to Tb on same server . This will allow for remote access of MAPI emails in Tb, but will be located in Inbox instead.

2. Have found that sending one attachment at a time works in Tb. Tb MAPI only fails when automating multiple attachments.

3. Waiting for Tb 3.x bug fix for MAPI is useless without fixing remote profile access speed problems Bug 539389. Will then also need to disable global indexing and use CPU friendly third party indexing program and disable auto-sync of all IMAP folders to try and obtain a lean Tb 2.0.x speed.


I wish for MAPI fix for Tb 2.0.x

I will likely go with option 1. 



Any other suggestions?
(In reply to comment #21)
> 1. Use Outlook express on Tb server for MAPI functions,
>    then send email back to Tb on same server.

If you use IMAP, "sent mail copy in IMAP folder oy Outlook Express" is simplest/easiest way to share mal data sent via MYOB with Tb. If you can accept "all mails is read by Google's system as provider of mail service", and if you can access Gmail's IMAP server from inside of your company, you can use Gmail/Gmail IMAP(6GB is available for free Gmail account) as "shared mail repository" between Outlook Express and Thunderbird 2/3.

> 2. Have found that sending one attachment at a time works in Tb.
> Tb MAPI only fails when automating multiple attachments.

It souns that problem of "not deleted data in moz_mapi" fortunately doesn't occur in your case. 
Which does "automating multiple attachments" mean?
a) mutiple mails with an attachment at same time?
b) a mail with multiple attachments when you request to MYOB?
c) (a mail with multiple attachments) * N at same time?
If b), different problem may be involved in your problem, if MYOB uses same seed of file name with suffix. As Tb uses suffix(-NNN) for file name in many situations when dupication of file name happens, Tb may confuse if f-1.pdf, f-2.pdf, ..., f-11.pdf, f-12.pdf, ... are requested at same time.

> I will likely go with option 1. 

I also think "use other mailer than Tb if mail send using MYOB via MAPI" is currently available best choice in your environment.
Does MYOB support specific mailer for mail send? Or always uses default mailer? If former, I think there is no problem. However, if latter, you need to be torelant with mail compose window of Outlook Express upon click of mailto: link.
"automating multiple attachments" means:

a) multiple mails with an attachment at same time, in this case a list of email recipients in MYOB each with one attachment. ( MYOB payroll slip )


I think MYOB uses default email program, I will have a look if it can manually select
This bug was fixed 5 years ago. I no longer use Thunderbird nor MYOB. (I'm using Apple Mail and Xero.com accounting.) I'm sure people are keen to see this issue resolved, however please note I'm taking myself off email notifications for this bug tracker.
You need to log in before you can comment on or make changes to this bug.