Open Bug 274027 Opened 20 years ago Updated 2 years ago

Mistyped hostname/userName(mail.server.serverNN.hostname/hostname value used in internal folder path) can never be corrected, once initial account definition is successfully saved.

Categories

(MailNews Core :: Account Manager, defect)

x86
Windows 2000
defect

Tracking

(Not tracked)

People

(Reporter: tech, Unassigned)

Details

User-Agent:       Opera/7.54 (Windows NT 5.0; U)  [en]
Build Identifier: version 1.0 (20041206)

This bug is related to 41929 and 232869. I have the same username on different 
hosts. When I installed Thunderbird and configured my first email account I 
entered the wrong server name. I then went back and edited the server 
information. Tested the system and all was fine until I went back to add the 
second email server. At this point, since I had previously entered the server 
name and user name I was dis-allowed from re-adding them even though I had 
already changed the other accounts server information with the following error: 
"A mail or newsgroup account with the same name already exists. Click back and 
enter a different server name or click cancel." 

Now I can't add my second email account.

Reproducible: Always
Steps to Reproduce:
1. Setup a mail account as follows: username1@hostname.maildomain1.com
2. Edit the mail account info as follows: username1@hostname.maildomain2.com
3. Add new mail account as follows: username1@hostname.maildomain1.com

Actual Results:  
I could not add the second email account. Previous server information appears to 
be cached and the error message: "A mail or newsgroup account with the same name 
already exists. Click back and enter a different server name or click cancel." 
appears when I click Next from the User Names page of the wizard.

Expected Results:  
As I have changed the information on account 1, if add a duplicate of the 
previous name there should be no conflict in information.

You can not expect a user to correctly add all their information the first time.
This is current design and current limitation/restriction.
When account is defined, initial userid/servername is saved in
mail.server.serverNN.hostname / mail.server.serverNN.userName, and server name
is used for directry for the account(same as server name, suffix is added if
different account on same server), and hostname/userName are used for internal
path for mail folders for this accounts.
When login-id / server-name change from UI of account settings, new
login-id/server-name are saved in mail.server.serverNN.realhostname /
mail.server.serverNN.realuserName and are used for server connection.
But directry name for this account and internal path name for this account are 
not changed, are still based on initial mail.server.serverNN.hostname /
mail.server.serverNN.userName.
This is design and the cause of your problem.

Try next procedure to see above;
 (1) Define a POP3 account : username=test1 server-name=mail.server.net
     => mail.server.serverNN.hostname = test1 
        mail.server.serverNN.userName = mail.server.net
        Directry of mail.server.net is created.
 (2) Define secnd POP3 account : username=test2 server-name=mail.server.net
     => mail.server.serverNN.hostname = test2 
        mail.server.serverNN.userName = mail.server.net
        Directry of mail.server(-x).net(-y) is created.
        (Suffix is added for directry name)
 (3) Change userid and servername of first account : test1-x, mail.server.net-x
     => mail.server.serverNN.realhostname = test1-x 
        mail.server.serverNN.realuserName = mail.server.net-x
        But hostname/userName are not changed, and this is design
        realhostname/realuserName is used on login
 (4) Change userid and servername of second account : test2-x, mail.server.net-x
     => mail.server.serverNN.realhostname = test2-x 
        mail.server.serverNN.realuserName = mail.server.net-x
        But hostname/userName are not changed, and this is design
        realhostname/realuserName is used on login

Because of this, when you try to define second account, user-id is already
defined, and directry derived from server name of first already exists.

Your problem is easily avoided by next procedure.
 - Deifine a account with dummy & unieque uid and dummy & unieque server name,
   then save account definition,
   then modify account definition - change uid and server name to real one.
I agree, that is exactly the problem as I saw it after posting the bug and 
reviewing the .js file. My solution was to delete the .js file and start over. 
The question is why does it matter what the account name is? This seems like bad 
programming to me. The account name and the account settings (even if textually 
the same) should be considered different items and not conflict with each other.
Is there a logic behind this, i.e. matching the account service and the account 
name, because, while I understand the desire for unique account names, and 
uniques services per account, I don't see any relation between the account name 
and the service where this would be a relevant check. 
(In reply to comment #2)
> The question is why does it matter what the account name is?
> This seems like bad programming to me.
> The account name and the account settings (even if textually the same) 
> should be considered different items and not conflict with each other.

No.

Current programing is ;
 - Account name is only a display label and can be any string if not conflict.
 - There is no need of real server-name nor real login-id on initial definition
   from point of programing view.
   mail.server.serverNN.hostname and mail.server.serverNN.userName are used as
   unieque internal account identifier, internal mail folder path name(also used
   by message filter or junk filter) and default mail directry name (Local
   Directry setting),
   but there is no relation to real account's attributes(server name, login id,
   password, etc.).
 - mail.server.serverNN.realhostname and mail.server.serverNN.realuserName
   are used on server connection(these are real account's attributes),
   and if not defined, value in mail.server.serverNN.hostname or 
   mail.server.serverNN.userName is used(only has meaning of default value).
 - Real login-id and real server-name can be changed any time if not conflict.

The only limitation/restriction is ;
 - Initially entered "server-name"  (mail.server.serverNN.hostname)
   and initially entered "login-id" (mail.server.serverNN.userName)
   can not be changed, and
   ( mail.server.serverNN.hostname + mail.server.serverNN.userName )
   should be unieque.

Cause of confusion of user(especialy your case) is UI, I think.
But description/explanation on above "programing view" is meaningless for almost
all users, I think.
Actually it is the section "Only Restriction Is" that is at issue. Since I can 
not change the original entry (ever) when I change the logical entry and return 
to re-add the original entry the problem is produced.
Change summary for ease of understanding and search.
(Old)
SMTP server information cached even after edit
(New)
Mistyped hostname/userName(mail.server.serverNN.hostname/hostname value used in
internal folder path) can never be corrected, once initial account definition is
successfully saved.
Summary: SMTP server information cached even after edit → Mistyped hostname/userName(mail.server.serverNN.hostname/hostname value used in internal folder path) can never be corrected, once initial account definition is successfully saved.
I have run into this same issue and I strongly believe that this needs to be
fixed.  There is no reason why you should force the user to ensure unique
hostname/username when the account is being created.  Instead of creating a
directory using the hostname, use the same mechanism for generating a unique
profile directory eg: "eskdfios.2d" and then plop all the account data in there.
 This results in removing mail.server.serverNN.userName and
mail.server.serverNN.hostname from the prefs, and then adding a
mail.server.serverNN.FolderID pref.  It solves the problem, has no visual impact
to the user (other than the error a non-tech user wouldn't understand), and
allows for feature development without unescessary workarounds.
Related to/duplicate of bug 254500?
I had a similar problem. My ISP moved my mail from one machine to another, and so I tried to change the machine name in the Account Settings while keeping everything else the same. It all went entirely pear-shaped. 

One of the symptoms was a mix up in directories - so my mail account appeared in the folder pane to have my blog list as children! Looking at the prefs, the account type had changed to rss; half the prefs matched my mail account, the other half my blog account! I tried to hack my profile to fix the problem, but ended up creating a new one from scratch.

This problem could be reproduced by setting up two DNS names for the same machine, configuring a mail account with one name, and then changing the Account Settings to use the other. If a Thunderbird developer or QA person tries these steps to reproduce and reports that everything works fine for them, then I'd be happy to look into what makes my setup special.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: account-manager
Assignee: mscott → nobody
Is the original report still valid?
I am not sure what is discussed here. Is it the problem that the directory containing the folder files contains the original server name and can never be changed?
Or does this really prevent some NEW accounts to be created if they resemble the hostname+username combo used previously?
Product: Thunderbird → MailNews Core
QA Contact: account-manager → account-manager
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.