303310 - "Reply with template" filter always uses default identity instead of per X-Account-Key

Status: NEW

(MailNews Core :: Filters, defect)

Description

[Miguel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

If you create a "Reply with template" filter, the reply is sent from the main
identity instead of using the identity to wich the mail was sent.

Reproducible: Always




Build: 20050803

Comment 1

[Miguel]

Steps to reproduce it:

1.- Configure a "Reply with template" filter to reply some type of mail.
1.- Send a mail to an account with multiple identities configured.
2.- Mail must be sent to some secondary identity for that account, *NOT* to the
main one.
3.- "Reply with template" filter will sent the automated reply but using the
main identity, not the identity which the mail was sent to.

The fix may be using here the same logic that's already been developed when
replying mails.

Comment 2

[Scott MacGregor]

getting rid of some keywords. it's been a long time since we used those.

To fix this bug, I think we need to add a method to nsIMsgComposeService called
bestIdentity which returns the best identity to use for a server and nsIMsgDBHdr
pair. The implementation would then convert our JS method: getBestIdentity in
mailCommands.js and turn it into C++. That'll be a bit of a pain because most of
the operations that routine does are a lot easier in JS.

Then we should convert our JS code and the reply with template code to all use
this method.

Comment 3

[David :Bienvenu]

yes, that's what I was thinking when I saw this bug come by.

Comment 4

[Magnus Melin [:mkmelin]]

-> new

Comment 5

[Scott MacGregor]

I lose track of bugs that don't show up in my thunderbird queries too easily. This could be an interesting bug to fix.

Comment 6

[Scott MacGregor]

Moving off bugs that didn't make the deadline for Thunderbird 2. 

Comment 8

[Magnus Melin [:mkmelin]]

My patch in bug 904478 solves this i think.

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #8)

My patch in bug 904478 solves this i think.

Dan, can you reproduce?

Comment 10

[Dan Pernokis]

Actually, the bug seems to have morphed -- I get an automatic reply ONLY from the main account AND ONLY when that account is the recipient.

I have two "dannyfox" addresses (identities) in my Danny Fox account -- one at my company domain ("[e-mail]") and one at my ISP's domain. The ISP address is main, and the company address is secondary (as it might change if it ever gets spammed up) -- but see caveat below.

When I send to the main address, I do successfully get an auto-reply -- it shows in SENT as "Auto: this is a test template message (was: <original subject>)" and the auto'd message arrives in my INBOX. If I send to the secondary address, there is no reply at all -- nothing in SENT, nothing received back. FYI, manual REPLY does correctly & always reply from the address to which an inbound message is sent -- but again, see caveat.

CAVEAT: The two valid addresses (identities) on this account are actually second and third, as I generally use a non-functional "!" as the primary (first) address -- to prevent accidental responses from the wrong account. This was done long ago as a workaround to one of my earliest bugs where REPLY used to always go to the primary (first) address. Manual reply now seems to grab (reply from) the appropriate address, perhaps because the first address -- the actual main address -- is invalid (blank) and can't be used. The automated template reply successfully skips the first address and ALWAYS replies to the second, which we've called "main" in this bug as it is the first valid (usable) address.

It might be that my original bug -- always replying to main -- is in fact THIS current auto-reply bug manifested in manual reply mode.

Comment 11

[Dan Pernokis]

BTW, I'm running TB 78.6.0 (latest standard public release) on Windows 7/32 Pro.