Closed Bug 148939 Opened 22 years ago Closed 22 years ago

Changing list entry doesn't change the list entry but appears so!

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P1)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: mjacob, Assigned: srilatha)

References

Details

(Whiteboard: [adt2 rtm], [eta 06/22])

Attachments

(1 file, 2 obsolete files)

I wanted to change a list entry in my address book, because one email was wrong.
First I selected the list name on the left, so the addresses were displayed on
the right. Then I chose the entry from the right panel with double-click and
changed the entry to the correct address. The correct address is displayed when
I select the list name again. As I sent a mail to the list it went again to one
wrong mail address!
So: The address ist listed correct in the right frame of the address book but
when I double-click the list name on the left the mail address is shown
_unchanged_ in the popup!
Branch build 2002-06-10: WinMe
Reproduced

Retyping the steps in step-by-step format:
1. Create a list with 2 addresses (i.e. user1@test.com, user2@test.com)
2. Select the list in the directory pane and the two email addresses appear in
the results pane (to the right)
3. Select an email address and edit the card to change it to a different email
address (i.e. change user2@test.com to user3@test.com)
4. close the mailing list dialog
5. With the list selected in the dir pane the correct email address appear in
the results pane (user1@test.com and user3@test.com)
6. Send a message to the list

Actual Results: The message is sent to the original email addresses (user1 and
user2) instead of using the edited list (user1 and user3).

Select the parent address book, select the list and below it displays the
original email addresses (user1 and user2). Interesting that viewing the list
when the parent address book is selected is different than with the list
selected from the dir pane.

Marking nsbeta1 because this is very misleading. The user could easily send a
message to an unintended person!
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1
Additional Information:
If the mailing list dialog is open and a change is made then this data is saved
correctly. 
reassigning to srilatha.  Can you look into this?
Assignee: racham → srilatha
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1 rtm]
Srilatha, can you add an eta to this?
I think I know why this is happening
nsIAbDirectory.addresslists is not getting updated when we edit the card.
This is the list we look at when we do compose on a maillist and also when we 
open the mailList dialog. I am trying figure out how we can update the list when 
we change the e-mail address on the card.
I am hoping to have patch by the monday afternoon.
Status: NEW → ASSIGNED
Whiteboard: [adt1 rtm] → [adt1 rtm], eta 6/18
Attached patch proposed patch v1 (obsolete) — Splinter Review
In this patch, I added code to update the addressLists when we edit a card and
save it.
This patch wont work when the card is in multiple mailing lists, since we are 
breaking out of the loop once we find the card in a mailing list. I will post a 
new patch where we search through all the mailing lists for the card and update 
it. Also if we are editing the card from a mailing list, we do need to go to the 
parent directory and search through all the mailing lists. Will post a new patch 
.
Updated the patch so that we search all the mailing lists in the addressbook.
Attachment #87752 - Attachment is obsolete: true
OS: Windows NT → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.0.1
lowering impact to adt2 rtm per ADT.
Whiteboard: [adt1 rtm], eta 6/18 → [adt2 rtm], [eta 06/21]
Comment on attachment 88223 [details] [diff] [review]
updated patch to handle multiple mailing lists

Looks ok to me; fix the tabs and thanks for looking into the multiple mail list
scenario. 
r=varada
For later releases we should look into having attributes on the card which
reflect their belonging to a maillist, array of lists.
Attachment #88223 - Flags: review+
I don't know for sure what this address list thing is, but it sounds like it's a
list of the addresses in a mailing list - it should be recalculated whenever
it's used from the underlying mailing list table. Then we wouldn't have this
problem, and we wouldn't be duplicating all this information in memory. The
problem is the address book design is goofy, not that we don't know if a card is
in a list or not. But obviously, that's much too large a problem to fix for the
next release.

+    var card = directory.addressLists.GetElementAt(i);
+    card = card.QueryInterface(Components.interfaces.nsIAbCard);

can't you use QueryElementAt directly here?

same thing here (and whereever else this is done)
:
+    var subdirectory = directory.addressLists.GetElementAt(i);
+    subdirectory =
subdirectory.QueryInterface(Component.interfaces.nsIAbDirectory);

other than that, looks ok...
For a mailing list, the addresslists is a list of cards that are in the mailing 
list. For a addressbook, the addresslists is a list of mailing lists in the 
addressbook. 
I can use QueryElementAt instead of the GetElementAt and doing a QueryInterface.
New patch coming up.
Updated the patch to use QueryElementAt. Also fixed the tabs
Attachment #88223 - Attachment is obsolete: true
Comment on attachment 88388 [details] [diff] [review]
updated patch using QueryElementAt

sr=bienvenu
Attachment #88388 - Flags: superreview+
Comment on attachment 88388 [details] [diff] [review]
updated patch using QueryElementAt

carrying forward r=varada from the previous patch
Attachment #88388 - Flags: review+
Fix checked into the trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
nbaca - can you pls verify this fix on the trunk? thanks!
Keywords: approval
Attachment #88388 - Flags: approval+
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Trunk build 2002-06-20: WinMe
Trunk build 2002-06-21: Linux RH 7.1, Mac 10.1.3
Verified Fixed.

Scenarios used when verifying this bug:

1. Setup 
a. Create 2 cards (user1@ns.com, user2@ns.com)
b. Create a list (list1)
c. Create a second list (list2)

Items 2-5 retain the changes. When sending the message it uses the latest changes:
2. With the PAB selected, edit one of the cards (i.e. user1@ns.com to user11@ns.com)
a. With the PAB selected, is the change reflected in the results pane for the card?
b. Select list1 from the results pane, is the change reflected?
c. Select list2 from the results pane, is the change reflected?
d. With list1 selected in the dir pane, is the change reflected in the results pane?
e. With the list1 selected in the dir pane, open the list dialog, is the change
reflected?
f. With list2 selected in the dir pane, is the change reflected in the results pane?
g. With the list2 selected in the dir pane, open the list dialog, is the change
reflected?

3. With a list selected in the dir pane, edit one of the cards in the results
pane (i.e. user1 to user12)
Check items 2a-2g

4. With the PAB selected, double-click a list so the mailing list dialog
appears, edit an address (i.e. user1 to user13)
Check items 2a-2g

5. With the list selected in the dir pane, double-click a list so the mailing
list dialog appears, edit an address (i.e. user1 to user14)
Check items 2a-2g

Items 6-7 also retain changes and there is no apparent change in the amount of
time it takes to edit and close a card.
6. Edit a card in results pane with the parent address book selected
7. Edit a card in the results pane with a list selected


Will check the branch when it's ready.
Status: RESOLVED → VERIFIED
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check
this in asap, then add the "fixed1.0.1" keyword.
Blocks: 143047
Keywords: adt1.0.1adt1.0.1+
Whiteboard: [adt2 rtm], [eta 06/21] → [adt2 rtm], [eta 06/22]
Fix checked into the branch
Branch 2002-04-26: WinMe, Linux RH 7.1, Mac 9.1, Mac X
verified1.0.1, using scenarios in comment# 19.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: