Closed
Bug 57129
Opened 24 years ago
Closed 24 years ago
Allow @ in username
Categories
(SeaMonkey :: MailNews: Account Configuration, defect, P3)
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: BenB, Assigned: alecf)
Details
Subject: From mailnews.js: pref("mail.allow_at_sign_in_user_name", false); //strip off chars following the @ sign in mail user name Problem: Many (20-30%, I'd guess) ISPs here is Germany require the full email address as username. They have to provide descriptions to their users how to set the hidden pref to true (i.e. hack the prefs.js). Opinion: Users having to hack prefs.js is very bad - unconvient, failure-prone and all. The situation as described above led me to believe that the pref and especially its default setting was a bad idea in the first place. Solutions: Several alternatives: 1. Change default (|pref("mail.allow_at_sign_in_user_name", true);|) - Breaks 4.x compatibility. (But I think, MSOE never strips the domain, so we would show a behaviour similar to MSOE.) - The problem the pref tried to solve (users being to dumb to differentiate between email address and account username) appears again + The problem as described in the beginning disappears completely 2. Add UI for pref in account wizard (next to account username textfield) + 4.x compat. + Users get aware that email address != account username + The problem as described in the beginning is *much* less worse, because companies can easily add one step "check checkbox blabla" in a step-by-step guide - Account Wizard gets littered 3. Add UI for pref in account manager (under "Advanced" or similar) + 4.x compat. + The problem as described in the beginning is less worse, because the user can change the pref in the UI (more convient, less failure-prone) - Companies still have to add *several* steps in a step-by-step guide, like 'open Account Manager, click on your email address on the right (compare bug 57128), open advanced, blabla'. This is because the user would have to use different 2 dialogs to set up the account (which is a problem in itself, see bug 57126), which also makes it likely that he forgets to set the @-in-username pref. Suggestion: IMO, 3. is not a good solution.
Comment 1•24 years ago
|
||
I think if 2 gets added, three almost has to. It would be bad to have it so easily set in the wizard but not easily changed once finish is clicked. The downside of UI clutter still remains, however.
Reporter | ||
Comment 2•24 years ago
|
||
Jake, you're right. s/3. Add/3. Only add/
Assignee | ||
Updated•24 years ago
|
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 3•24 years ago
|
||
this is not a bug, this is a complaint with suggested solutions. Take this up on the newsgroup, let's reach a resolution there, and then file a bug on the solution decided.
Comment 4•24 years ago
|
||
Just to underline the importance of this: AAt least one of the biggest domain providers in Germany (1,300,000 domains!) *requires* a full username including the domain. And recently an US ISP posted a help request about this issue in the NGs. ok, I'll shut up now and go to discuss this in the NG. Why shouldn't a complaint (in my eyes it *is* a bug) contain possible solution possibilities and be files as RFE?
QA Contact: esther → stephend
VERIFIED INVALID. The valid bug is 53970 which has been FIXED.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•