Closed Bug 150632 Opened 22 years ago Closed 15 years ago

Collecting addresses should not overwrite existing entries

Categories

(MailNews Core :: Address Book, defect)

x86
All
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Erich.Iseli, Unassigned)

References

Details

(Keywords: dataloss)

Until bug 58769 isn't fixed, it's IMHO useless to use other ABs than the
"Collected Addresses" one. Therefore I'm adding more contact infos to the cards
in the CAB but every time I get an e-mail from the person, some data gets
overwritten. This is especially true if the person didn't specify any Name and I
added the name manually. => DATALOSS

Probably there's an easy way to back out the code that checks whether some info
changed in an already existing card in the CAB. This can be checked in again
only when collecting addresses correctly sees all addresses from all ABs.
Adding dep and putting Severity to critical, because of dataloss.
Severity: normal → critical
Depends on: 56821
How to reproduce this bug:
1) make sure you are collecting addresses from incoming e-mail.
2) go to the Collected Addresses and locate somebody recorded with no clear
name, but the part before the @ in his e-mail address. For example, if the
address is "my234email@domain.com", you should see the name listed as "my234email"
3) Get the properties of this card and set first name, last name and display
name to be the real name of the person.
4) wait until you get a new e-mail by this person
5) go back to the address book and you will see that the first name and the
display name were set to noting (empty, null) while funnily the last name is
still there.
Sorry for the spam, I'm still experimenting...

Another way to reproduce is if the person provides a name different than the one
you've set. Imagine someone has the name set to "Big Brother" or any other
nickname, and you want to have his real name, say "John Smith", it will always
get overwritten with "Big Brother".

I can imagine that this is no bug _provided_ the collecting works OK (which
isn't now because of bug 58769). In fact, if somebody changes his name, I'd be
happy to see the change happen in the collected addresses, and the cards which I
don't want to be changed, should be in the PAB or any other AB.
Handy for reproducing this bug, instead of waiting for the person sending you
another e-mail, just open one of those e-mails (with the "broken" name).
Can someone please add "dataloss" to the keyword list?  Thanks
Keywords: dataloss
Depends on: 35837
No longer depends on: 56821
mass re-assign.
Assignee: racham → sspitzer
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Removing an incorrect dependency on bug 35837 - I can't see why these got 
linked in the first place.
No longer depends on: 35837
*** Bug 168952 has been marked as a duplicate of this bug. ***
I agree with [the implication of] comment #3, that the action should be on bug
58769 and not the present one.

In which case, "should not" should be removed from the present Summary.
Component: Address Book → MailNews: Address Book
OS: Linux → All
Product: Mozilla Application Suite → Core
*** Bug 320689 has been marked as a duplicate of this bug. ***
Assignee: mail → nobody
QA Contact: nbaca → addressbook
Product: Core → MailNews Core
dupe to bug 58769?
I fixed this in bug 409608 - we don't change the card if a name is already specified, or the email we received didn't have a display name. As its not a dupe of that bug, marking fixed as a result of bug 409608.
Status: NEW → RESOLVED
Closed: 15 years ago
Depends on: 409608
Resolution: --- → FIXED
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.