MDN:Switching identity should retain request for MDN receipt options

VERIFIED FIXED in mozilla1.0

Status

MailNews Core
Backend
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: Jeff Tsai, Assigned: Jeff Tsai)

Tracking

(Blocks: 1 bug)

Trunk
mozilla1.0
All
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3] [fixed in trunk])

Attachments

(1 attachment, 5 obsolete attachments)

(Assignee)

Description

16 years ago
If the user changed the default setting of MDN receipt request when switching
identity the setting should remain intact. However, if the setting hasn't been
changed then switching identity the setting should be set according to the new
identity.
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Depends on: 16241

Comment 1

16 years ago
I don't understand what's being said here.
Are you saying this:
- Assume 3 identities.
- identity 1 & 2 wants MDN receipts 
- identity 3 doesn't
- if the user, as identity 1, changes his settings to not request MDN's then the
setting for identity 2 is also changed

Will each identity have separate default MDN request settings? If so, they
should remain separate and a change to one identity should not affect any other
identity. If not, well, nevermind...
(Assignee)

Comment 2

16 years ago
I am sure not making it clearly stated. There will be global defaul preferences 
which are overridalbe per account. Also, per compose session the request for mdn 
receipt can be overrided too. The initial request settings were dictated by the 
initial identity/account. The confusion comes when switching the sender 
identity/account. Hope this explains.

Updated

16 years ago
QA Contact: esther → gchan

Comment 3

16 years ago
Should this be set to Platform/OS All?

This should probably be an adt3.  But I'm making it higher because this is a new
feature and given that we've gone to the trouble of supporting this for multiple
identities, we should make this work.
Keywords: nsbeta1+
Whiteboard: [adt2]
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 4

16 years ago
Yes, all platform.
Hardware: PC → All
(Assignee)

Comment 5

16 years ago
Created attachment 77418 [details] [diff] [review]
Patch ready for review and senior review

If request for return receipt option ever been changed it retains the changed
value. Otherwise, it changes to the identity's default setting when switching
identities. Please review and senior review.
(Assignee)

Comment 6

16 years ago
Created attachment 77419 [details] [diff] [review]
Patch ready for review and senior review

If request for return receipt option ever been changed it retains the changed
value. Otherwise, it changes to the identity's default setting when switching
identities. Please review and senior review.

Comment 7

16 years ago
why wouldn't this just be:

gReceiptOptionChanged = true;

+        if (!gReceiptOptionChanged)
+          gReceiptOptionChanged = true;
(Assignee)

Comment 8

16 years ago
Created attachment 77468 [details] [diff] [review]
Patch addresses David's comment

Yup, sounds good.
Attachment #77418 - Attachment is obsolete: true
Attachment #77419 - Attachment is obsolete: true

Comment 9

16 years ago
Comment on attachment 77468 [details] [diff] [review]
Patch addresses David's comment

r=bienvenu
Attachment #77468 - Flags: review+
(Assignee)

Comment 10

16 years ago
JF or Seth, could you sr this? Thanks,
Comment on attachment 77468 [details] [diff] [review]
Patch addresses David's comment

R=ducarroz. David, do you mind bumping your review to a super review?

Comment 12

16 years ago
Comment on attachment 77468 [details] [diff] [review]
Patch addresses David's comment

bumping r= to sr=bienvenu
Attachment #77468 - Flags: superreview+
(Assignee)

Comment 13

16 years ago
Fix checked in to the trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 14

16 years ago
putting on the adt list since this is a beta1+ bug which is now fixed on the trunk. 
Keywords: adt1.0.0

Comment 15

16 years ago
adt1.0.0-/[adt2 RTM].
Keywords: adt1.0.0 → adt1.0.0-
Whiteboard: [adt2] → [adt2 RTM]

Comment 16

16 years ago
Using commercial trunk builds
2002041603 on NT 4.0
2002041603 on Mac 10.1.3
2002041607 on linux 2.2


Jeff, I think I see something that might need to be addressed.
Hopefully you can follow:

1)Say you have global prefs with MDN off, I have 2 mail accounts
(imap/pop).Imap uses global mdn prefs & my pop uses customized
mdn prefs (mdn is turned on). I compose from imap (RR is off)
and I switch the 'From' to my pop account and RR is on (checkmark
i see in option file menu of compose window),I send a mesg to someone, 
they are prompted,and I get a RR back to my pop acnt. 

I next compose a mesg from my pop acnt(mdn is on), I switch the
'from part' to my imap(mdn off) act. I see RR is unchecked in the option
file menu. I send the mesg and no rr request to the sender is seen
and I dont get a RR back.

These 2 situations work. Everything ok. Correct? Expected behavior
right?

Now on to my 2nd scenario

2)I have global MDN prefs on. I have 2 mail acnts (imap/pop).
Imap uses Global mdn prefs (so MDN is on), my pop uses customize
mdn (and I uncheck the pref 'When sending mesgs,always request
a return receipt'). So MDN is off for my pop acnt.

I compose a mesg from imap (mdn on) acnt. I change the 'from'
to my pop acnt (mdn off) but I notice Option menu still has
a checkmark next to RR in compose window. I send the mesg
and the sender is prompted for a rr and a rr gets sent back
to my pop acnt.

I compose a mesg from pop (mdn off) acnt. I change the 'from'
to my imap (mdn on) but I notice option menu still has
no checkmark next to RR in compose window. I send the mesg
and the sender is not prompted to send a RR.

So I think my 2nd scenario is a bug, correct? Does this
bug cover BOTH Situations or just one? And if one, which one?

thanks.

(Assignee)

Comment 17

16 years ago
Gary, you are right. And I checked in the wrong patch. Me bad. I was checking 
the the second patch instead of the third one. Sorry. I'll check in the correct 
one now.
(Assignee)

Comment 18

16 years ago
Let me reopen it and have the patch for David and JF to review it again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 19

16 years ago
Created attachment 79941 [details] [diff] [review]
Diffs between 2nd and 3rd. Please r & sr.

David & JF, I checked in the wrong patch. Could you give a review and super
review again? Thanks,
Comment on attachment 79941 [details] [diff] [review]
Diffs between 2nd and 3rd. Please r & sr.

R=ducarroz
Attachment #79941 - Flags: review+

Comment 21

16 years ago
Comment on attachment 79941 [details] [diff] [review]
Diffs between 2nd and 3rd. Please r & sr.

how could this patch make any difference? if it's already true, we don't *need*
to set it to true - I just had you remove that line because the check isn't
neccessary. But I don't think it does any harm...

Updated

16 years ago
Summary: Switching identity should retain request for MDN receipt options → MDN:Switching identity should retain request for MDN receipt options
(Assignee)

Comment 22

16 years ago
I am resolving this to worksforme. The problem seems went away now. Gary could
you test with most recent commercial trunk build again? Thanks,
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 23

16 years ago
I see the exact same results in the current
trunk as I did couple of weeks ago.

And I noticed the current branch builds fail both of
my test cases (unlike the trunk builds only fail 1 test)

Using my test cases as outlined in comment 16:

Test1 -global mdn off
       imap - global mdn
       pop  - acnt based mdn (mdn on)

Test2 - global mdn on
        imap - global mdn
        pop - acnt based mdn (mdn off)

2002050206 commercial branch nt 4.0
2002050314 commercial branch mac 9.2.2

Test1 - fails. When I switch identies, return receipts fails to update.
It keeps the previous/old identity settings.

Test2 - fails as expected. When I switch identies, return receipts fails to 
update. It keeps the previous/old identity settings.

2002050310 commercial trunk linux 2.2
2002050303 commercial trunk mac 9.2.2

Test1 - passes. when you switch identies, return receipts updates to
new identity.

Test2 - fails as expected. When I switch identies, return receipts fails to 
update. It keeps the previous/old identity settings.

Did something change?

Reopening bug. If i'm mistaken please correct me.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 24

16 years ago
Created attachment 82341 [details] [diff] [review]
Proposed fix

Please review and super review. Thanks,
Comment on attachment 82341 [details] [diff] [review]
Proposed fix

Looks good. R=ducarroz
Attachment #82341 - Flags: review+

Comment 26

16 years ago
+nsMsgIdentity::GetRequestReturnReceipt(PRBool *val)
should be aVal

+nsMsgIdentity::GetReceiptHeaderType(PRInt32 *type)
should be aType

Fix those things, and sr=bienvenu (with a question: what's this
"use_custom_prefs" pref?)
(Assignee)

Comment 27

16 years ago
Created attachment 82593 [details] [diff] [review]
Final patches address David's comments

Changed pass-in args prefixed with a*. There is an overall return receipts in
Edit|Preferences as we had in 4.x. use_custom_prefs pref is used to indicate
whether to use per account overrides or the default return receipt prefs.
Attachment #77468 - Attachment is obsolete: true
Attachment #79941 - Attachment is obsolete: true
Attachment #82341 - Attachment is obsolete: true

Comment 28

16 years ago
I don't think this will be a common case, so I think we can live without this
for Mach V.  We should still get this patch on the trunk.
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt2 RTM] → [adt3]
(Assignee)

Comment 29

16 years ago
Fixed checked in to the trunk.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Whiteboard: [adt3] → [adt3] [fixed in trunk]

Comment 30

16 years ago
using commercial trunk
2002-05-29-08-trunk/ nt 4.0, linux 2.2, mac 10.1.4
2002-05-29-11-trunk/  mac 9.2.2

verified that when you swith senders in the compose
window, the return receipt option switches depending
on which account. Used the test case in comment 16 to
test this and it passed.

But before I mark it verified, I am seeing some 'weirdness'
with the pref 'When a receipt arrives move it to my sent folder'
and this happens only in the trunk.

When I have this pref set, i *think* imap only, that return receipt
still goes to inbox. This works fine in the branch. Not sure why
this seems to work fine with pop accounts but not imap.
So I'm not sure if a recent fix in the trunk broke this??
I'll investigate further. I filed a bug about this problem: see 
bug 146935

If the problem I see is totally unrelated to this bug, I'll mark
this as verified.

Comment 31

16 years ago
Marking verified based on comment 30 as I found
out what the problem was for sent folder on trunk,
see bug 146935 for details. 

verified on trunk.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.