Open Bug 303542 Opened 19 years ago Updated 2 years ago

Duplicate account(same hostname/userName) can be created when realhostname/realuserName is set for already defined account (duplicated accounts are; not shown by Tb 2, shown as duplicates by Tb 3)

Categories

(MailNews Core :: Account Manager, defect)

defect

Tracking

(Not tracked)

People

(Reporter: pamparara4, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7.10) Gecko/20050717 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7.10) Gecko/20050717 Firefox/1.0.6 problem appeared after adding another account with the same email adress. I've needed to check if my settings for account are ok (after win reinstall). Old messages was imported and I wanted them to stay, so I've changed username and server for account, after that I've added account again (leaving old with wrong settings, but the same email name) The result was new account didn't appeared in folder pane and even was not visible in Tools->account config, but - interesting - information was written "somwhere", becouse I could not reverse settings in "old" account (TB said there is such account already). Anyway, only "old" account was visible, there was no way to find/change settings for newly created one. The only solution I've found (have no time for bugs;-) was to delete "old" account (losing mails); then "new" account appeared. this bug seems to be similiar to: https://bugzilla.mozilla.org/show_bug.cgi?id=238006 Reproducible: Always Steps to Reproduce: 1. create email account and retrieve mails 2. change username and server leaving email name untouched 3. add account again Actual Results: new account will not be shown in folder pane and in Tools->Account config, only old account is visible. you cannot neither change setting for old account nor change / delete new (it's hidden). it means you cannot reverse setings in old account and use it. you can only delete old account loosing your mails. Expected Results: Old and new accounts should be visible in TB folder pane and tools->Acoount config menu.
*** Bug 303543 has been marked as a duplicate of this bug. ***
QA Contact: account-manager
I can confirm. Thunderbird version 2.0.0.16 (20080708) Reproducible: Always Steps to Reproduce: 1. create email account 2. change server hostname, close account dialog 3. add account again Problem: When you change the hostname mail.server.server#.realhostname is set to new hostname and mail.server.server#.hostname is left to old value. Workaround: Setting mail.server.server#.hostname to be equal to mail.server.server#.realhostname makes both accounts appear. Questions: Why is there a hostname and realhostname? Are they supposed to be different?
Assignee: mscott → nobody
(I think reporter is gone)
(In reply to comment #2) > Questions: > Why is there a hostname and realhostname? Are they supposed to be different? Yes. See Bug 376001 Comment #3. > Problem: > When you change the hostname mail.server.server#.realhostname is set to > new hostname and mail.server.server#.hostname is left to old value. It can't be say as "real problem", I think. hostname/userName is used internally in many places and current implementation can not handle hostname/userName value change. So realhostname/realuserName was introduced in case of host name change/user name change after initial account definition. I think problem is in dulplicate check. Account-1 : Initially defined with Host1/User1, then changed to HostX/UserX hostname =Host1 / userName =User1 realhostname=HostX / realuserName=UserX Account-2 : Defined with Host1/User1 => hostname=Host1/userName=User1 is used => Duplicate check is probably done against ; Account-1's realhostname+realuserName(HostX+UserX) Account-2's hostname+userName(Host1+User1) I think duplicate check should be executed against all of hostname+userName and realhostname+realuserName. Problem is re-created with Tb trunk -> Confirming. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) > Gecko/20081125 Shredder/3.0b1pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Summary: duplicated account not shown in account list → Duplicate account(same hostname/userName) can be created when realhostname/realuserName is set for already defined account, and the duplicated account is not shown in account list
FYI. See Bug 274027 for "mail.server.server#.hostname is left to old value".
Behaviour of Tb trunk was slightly different from Tb 2.0.0.18. Tested with next entries for already defined account. > user_pref("mail.account.account3.identities", "id3"); > user_pref("mail.account.account3.server", "server3"); > user_pref("mail.identity.id3.useremail", "x3@x.x.x"); > user_pref("mail.server.server3.hostname", "xxx.xxx.xxx"); > user_pref("mail.server.server3.userName", "xxx"); > user_pref("mail.server.server3.realhostname", "x3.x.x"); > user_pref("mail.server.server3.realuserName", "x3"); Note: In order to get same N for accountN/idN/serverN for ease of test, number assigned to "Local Folders" (X of account.accountX/server.serverX) is changed to 9999 in prefs.js. (1-A) Tb 2.0.0.14 generated next entries, upon new account definition with hostname=xxx.xxx.xxx, userName=xxx. > user_pref("mail.account.account4.identities", "id4"); > user_pref("mail.account.account4.server", "server4"); > user_pref("mail.identity.id4.useremail", "x4@x.x.x"); > user_pref("mail.server.server4.hostname", "xxx.xxx.xxx"); > user_pref("mail.server.server4.name", "x4@x.x.x"); > user_pref("mail.server.server4.type", "pop3"); > user_pref("mail.server.server4.userName", "xxx"); > (no other mail.server.server4.???? was created by Tb) Directory for this server3 was not created, and entries of directory & directory-rel were not generated. (1-B) Tb trunk generated next entries and some other entries in prefs.js, in addition to above entries in (1-A), upon new account definition with hostname=xxx.xxx.xxx, userName=xxx. > user_pref("mail.server.serverN.directory", "C:\\...\\xxx.xxx-1.xxx"); > user_pref("mail.server.server6.directory-rel", "[ProfD]Mail/xxx.xxx-1.xxx"); And created directory of "...\xxx.xxx-1.xxx". (2-A) Tb 2.0.0.18 didn't display this new account (mail.account.accountN.server points "server4") in Folder Pane nor Account Settings panel. (2-B) Tb trunk(2008/12/04 build) displayed the new account in Folder Pane and Account Settings panel, but all of displayed data was data of already defined account(account.account3/identity.id3/server.server3). And, upon account's settings change, even at account which should be account4, entries for account/account3 was updated. > user_pref("mail.identity.id3.useremail", "x999@x.x.x"); > user_pref("mail.server.server3.realhostname", "x999.x.x"); > user_pref("mail.server.server3.realuserName", "x999"); Settings for account4/id4/server4 was not modified. (3) Because server.server4.hostname=xxx.xxx.xxx and server.server4.userName=xxx already exist, no new account with hostname=xxx.xxx.xxx and userName=xxx dut to duplicate check.
Bug 131176 Comment #3 seems to be first report of the problem.
Depends on: 131176
Blocks: 131176
No longer depends on: 131176
(In reply to comment #7) > Bug 131176 Comment #3 seems to be first report of the problem. dup then?
(In reply to comment #8) > dup then? It's up to you(triage team) or member of Mozilla Messaging Company(who is responsible to "Thunderbird").
Summary: Duplicate account(same hostname/userName) can be created when realhostname/realuserName is set for already defined account, and the duplicated account is not shown in account list → Duplicate account(same hostname/userName) can be created when realhostname/realuserName is set for already defined account (duplicated accounts are; not shown by Tb 2, shown as duplicates by Tb 3)
Blocks: 316765
Attached file Example of duplication check logic (deleted) —
Because incomingServer object of AccountManager kindly returns incomingServer.realHostName and incomingServer.realUsername even when mail.server.serverN.realhostname / mail.server.serverN.realuserName is not generated in prefs.js, if no serverN.realhostname, incomingServer.hostName == serverN.hostname if no serverN.realuserName, incomingServer.username == serverN.userName duplication check with existent type+hostName+username and type+realHostName+realUsername is not so hard job, although arbitary uppercase/lower case in name is annoyng for programmer. This script is an example o duplication check using Associative Array(==Object object in JavaScript). Note-1: Because incomiServer doesn't return hidden server, duplication check with hidden server requirs other aproach. Note-2: Code is merely a sample which uses Associtive Array for duplication check. I use similar logic in my script sometimes, but the presented script is not verified yet, not tested yet.
No longer blocks: 534447
HTML and JavaScript for duplication check of account(already tested). Server definition(emulation of incomingServer object) is gnerated from actual prefs.js of bug 534447, and duplicatin check is executed using Associative Array.
OS: Windows XP → All
Product: Thunderbird → MailNews Core
Hardware: x86 → All
(In reply to WADA from comment #4) > Account-1 : Initially defined with Host1/User1, then changed to > HostX/UserX > hostname =Host1 / userName =User1 > realhostname=HostX / realuserName=UserX > Account-2 : Defined with Host1/User1 > => hostname=Host1/userName=User1 is used > => Duplicate check is probably done against ; > Account-1's realhostname+realuserName(HostX+UserX) > Account-2's hostname+userName(Host1+User1) > I think duplicate check should be executed against all of hostname+userName > and realhostname+realuserName. Ok, so what do we do when a duplication is found? We can't change username/hostname of the first account. Do we create the new account with modified login data? E.g. username = User1-1, hostname = Host1 and realUserName = User1 ? Or do you suggest to modify the hostname? The local directory is already modified in case of duplicate hostnames so we get e.g. /mail.com and /mail-1.com.
Well, we could just refuse to create the account... I don't know what Thunderbird's new code does in this case.
We could, but that would confuse the user and also would be a bug as the new login data is completely valid. If currently no account has the same login (realuser/realhost) then we must allow it in some way. Is it a problem if we mangle the username and put the real user name into realUsername straight at creation time?
(In reply to :aceman from comment #14) > Ok, so what do we do when a duplication is found? > We can't change username/hostname of the first account. It's very simple. (i) Do proper duplication check on any of hostnae+userName and realhostname+realuseName upon account creation, in order that this bug won't occur again any more. (ii) If duplicated accounts due to this bug is detected, notify user about it, then request user to delete the wongly generated and dup accont(s), and request user to re-defie accoutn(s) with Tb which doesn't have this bug.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: