Open Bug 564043 Opened 14 years ago Updated 6 months ago

[autoconfig] Allow custom fields in config files

Categories

(Thunderbird :: Account Manager, enhancement)

Product:
Thunderbird
Component:
Account Manager
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: BenB, Assigned: BenB)

References

(Blocks 1 open bug)

Details

(Keywords: ux-jargon) 

A number of ISPs allow alias email addresses. You username is u13543, and your standard email address is u13543@example.com, but you may, on a webfrontend, create aliases of the form ben.bucksch@exmaple.com. The emails go to the very same mailbox as u13543@example.com. Many ISPs then also allow ben.bucksch@example.com as IMAP username, but not all. For some, the username to use as login to the IMAP/POP3 server must be "u13543" and cannot be "ben.bucksch" nor "ben.bucksch@example.com".

To complicate matters further, many of these ISPs have several usernames: one for their admin website, one for PPP, one for mail. They also often use different terminology, like "customer ID", "member name" or similar, and sometimes use "customer ID" for the admin site login and some other term for the one to be used for IMAP login. Worst case are probably companies which also have Windows login, Samba, employee site etc., all with *slightly* different username forms, e.g. "fred", fred@example.com, fred\\EXAMPLE, fred.EXAMPLE, and so on.

That's why just a field "Username:" does *not* cut it and leaves users confused (what autoconfig tries to solve). It's critical to allow a custom label for the username, and an example, e.g.
OS login account  [          ] Example: wilma.example

If the company would always have "\\EXAMPLE" at the end for this domain, the config file could even add that as literal, and let the user enter only the "fred".

Also, there may be other parts of the config being variable, e.g. part of the hostname.

----
Here's what
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat#User_input_fields says:

For some ISPs, the IMPA/POP/SMTP username (and maybe other fields) has no relation to the email address and has to be entered separately. E.g. Email address is ben.bucksch@wong.com (chosen by user), but username is G675476 (provided by ISP).

In this case, an <inputfield> can be added for the username. It will let the client show a textfield to the user. The user-visible label is the one provided in the <inputfield label=""> attribute, to allow the ISP to use custom terminology for "username". The label is not localizable, that would be too complicated and most ISPs are local anyways - if really important, the ISP config server can look at the HTTP headers during the fetch.

The text that the user entered is written into a placeholder %KEY%, where KEY is the content of the <inputfield key="KEY"> attribute and must be only upper case letters. The placeholder can then be used in other settings, see #Placeholders above.

For example, a config file entry

        <userinput label="Username" key="%USERNAME%">D123456</userinput>

would result in a UI like:

  Username:     [             ] example: D123456

and cound be used elsewhere in the config file like:

        <username>%USERNAME%</username>

and if the user enters "D32198", it would be automatically filled in like:

        <username>D32198</username>

i.e. using D32198 as username for IMAP, POP or SMTP.

The system is generic, so that it can in theory be used for other values as well. No other such purpose is currently known, apart from a separate POP and SMTP username maybe. It should not be used to let the user supply hostnames, as that would defeat the purpose of the autoconfig and be worse than the manual config UI provided by the client.

---


Cox example:
(See http://support.cox.com/sdccommon/asp/contentredirect.asp?sprt_cid=fcb44db0-3835-491c-bca8-2d56ac32a574 )

        <userinput label="Customer ID" key="%CUSTID%">u123456</userinput>
        <userinput label="US area" key="%AREA%">east or west</userinput>
        <hostname>pop.%AREA%.cox.net</hostname>
        <username>%CUSTID%</username>

  Customer ID:  [             ] example: u123456
  Area:         [             ] example: east or west


Intranet example:

        <userinput label="Windows login" key="%OSUSER%">u123456</userinput>
        <userinput label="Department" key="%DEPT%">cs, bio, math</userinput>
        <hostname>imap.%DEPT%.uni-heidelberg.de</hostname>
        <username>%OSUSER%\\%DEPT%\\UNI-HEIDELBERG</username>

  Windows login:  [             ] example: u123456
  Department:     [             ] example: cs, bio, math
Blocks: 555245
Would this create identities ?
It would otherwise work exactly like autoconfig currently. The examples above are just excerpts.
(In reply to comment #0)
> It should not be used to let the user supply hostnames, as
> that would defeat the purpose of the autoconfig and be worse than the manual
> config UI provided by the client.

The above is a little problematic with this:

>         <userinput label="Department" key="%DEPT%">cs, bio, math</userinput>
>         <hostname>imap.%DEPT%.uni-heidelberg.de</hostname>

I see that this was just an example, but here's a counter-example from our university. CS department has address mail.cs.tut.fi for incoming mail, wehereas the central IT support's server address is imap.tut.fi. That's quite impossible to describe in the proposed XML syntax without asking for the complete server address from the user. To make this any easier for the user, there should be a way to predefine a configuration for multiple servers, and offer the user a choice (drop-down menu?) to select one of them.
> CS department has mail.cs.tut.fi, whereas central is imap.tut.fi

That problem cannot be solved with custom fields and is indeed offtopic here.
I'll respond to you per mail with advice.

Please note that @cs.tut.fi and @tut.fi email addresses would get different configs anyways, so if that's the case, there's no problem.
(In reply to comment #4)
> > CS department has mail.cs.tut.fi, whereas central is imap.tut.fi
> 
> That problem cannot be solved with custom fields and is indeed offtopic here.
> I'll respond to you per mail with advice.

What I was saying that your guideline "It should not be used to let the user supply hostnames" can't always be followed. If a user can be asked a *part* of a hostname, why not the whole hostname. I understand that it's not a preferred solution, but I hope it also will not be prevented in any technical way.

> Please note that @cs.tut.fi and @tut.fi email addresses would get different
> configs anyways, so if that's the case, there's no problem.

The problem in this case is that both server's users have @tut.fi addresses. But let's not go into more detail in this forum.
> If a user can be asked a *part* of a hostname, why not the whole hostname.

1) I wrote why: "as that would defeat the purpose of the autoconfig and be worse than the manual config UI provided by the client."
2) It's one thing for the user to tell the department or US state he's in, that's something the user can easily answer, esp. when there are examples given. It's another to ask him which IMAP server he needs. That's something most can't answer. And if they can, they can just go to "Edit" / manual config. That's what it's for. (And bug 564102 shows a way how to force that for your domain.)

As said, your problem unfortunately cannot be solved with Custom Fields and is offtopic here.
Keywords: ux-jargon
Blocks: 559271
Blocks: 567695
Blocks: 556272
No longer blocks: 556272
Username-problem is solved by just plain asking users username giving it a field in new account wizard initial screen.

Currently there are 
"Your Name" [.....]
"Email address" [.....]
"Password" [.....]

Just add username between email address and password and 99% of this headache goes away. This is major issue for any corporate and using placeholders or similar "tweak until I'm dead" -solutions should be avoided.

If not provided then leave it empty. Make user enter the username as well as password (username is part of the credentials, both need to be given, password and username, so there is no reason to force Thunderbird to guess either).

Other than that I'm not against the possibility to tweak settings using config-files.
> Username-problem is solved by just plain asking users username giving it a
> field in new account wizard initial screen.

No, it's not, see initial description.
I think that for about 99% of cases it would solve the problem. I'm not against putting that info in config-file in some form, but just having that field there would pretty much solve the problem.

I think you are overestimating people confusion about different terminology for username. People are quite good at putting two and two together, and if Thunderbird uses term "username" as email username and some webmail/forum login/windows login/etc. uses "userID", "account name" or something else people still understand that it is the one they need to enter before password to get into places. I believe majority of people don't even pay much attention which is which, they just enter their username to first field and password to second field.

Like any login username/account name/userID/etc. is first part of the credentials. It would be useful to *force* people to learn that username and that password belongs together. Generally whenever you are going in any place which asks credentials it should ask them both. Even when prefilled. I think it would be good if TB would show user which username it is trying to use when it asks password. (IE you are not just using your password to login to this account but you are using *this* account name for it and I'm asking you to enter the password)
> I think that for about 99% of cases it would solve the problem.

No, it would not. In any case, that's *not* subject of this bug.
I agree that it is not the subject, just commenting about your initial explanation.

For a record custom fields as you propose here would IMO be a great addition, so "one vote for adding them" :-)

This seems to be few months old bug. Do you have any info when this could be added to TB? I'm fighting with this account wizard just now and to me it looks so messy for majority of users no matter what I do (even bug 564102 "please.click.edit" is bad bad choise) that I can't distribute TB yet. This bug would solve that problem nicely for majority of my users if I could get them to enter their usernames.
Any news for this bug? Should I make a bug for changing new account wizard to ask username instead of guessing it, if that is easier to implement?

IE. change the second screen after servers have been detected as "verify settings" with every (already guessed, and probably wrong) setting writable instead of just "this is what I think your settings are and you are stuck with them unless you press manual setup. Tough luck if there were any errors".
No. Please just wait.
This is in practice (not logically, but due to source code conflicts) waiting for bug 549045 to finish.
Depends on: 549045
Didn't notice the "depends on" earlier. Good to know that this has not stopped completely. Will wait and follow the progress of the bug 549045.
Another cool case I just had, aon.at (big ISP in Austria). You get a "Kundennummer" (customer ID). That's *not* the same as the "aon Kundennummer" (aon customer ID), though. How a mom&dad user is supposed to differentiate the two or even know that there's a difference, I don't know.

Most users would assume "Username" means the first part of the email address, or the real name even. Barely anybody who doesn't know computers well would think Username = customer ID, much less so in cases where there are several "customer ID"s.

The cases in the original description are not far-fetched, but straight from everyday reality, and things that are real road blocks for users.
(In reply to comment #15)
> Another cool case I just had, aon.at (big ISP in Austria). You get a
> "Kundennummer" (customer ID). That's *not* the same as the "aon Kundennummer"
> (aon customer ID), though. How a mom&dad user is supposed to differentiate the
> two or even know that there's a difference, I don't know.

It is a pair. Credentials is always a pair. If they know the password they know which username to use. Unless there is some configuration somewhere that uses same password with different usernames.

That means that if they use wrong username they will also use wrong password. And get confused no matter what you do about this issue.

Anyway this bug wont solve the issue for alias email address translated to username for anybody that doesn't use autoconfig and I believe that would be around 99.99% of the ISP:s that use aliases (maybe not the largest). So I'm thinking maybe you are doing unnecessary work here.
> If they know the password they know which username to use.

I just described a case (big ISP) where this is not true. I get 3-4 different usernames, all with the same password, and I did *not* know which username to use.

> Anyway this bug wont solve the issue

Please avoid discussion on this bug, this bug is not open for general discussion (this means you, Timo!). This bug is about implementing a specific part of the specification.
(In reply to comment #17)

> > Anyway this bug wont solve the issue
> 
> Please avoid discussion on this bug, this bug is not open for general
> discussion (this means you, Timo!). This bug is about implementing a specific
> part of the specification.

Thank you for making my point to newsgroup. Won't say a word after that. In fact I remove myself from cc list so that I don't even get tempted to make any comments in the future.
Blocks: 616947
Is this implementation being worked on?
Same question. Is this being worked on? Current account wizard is useless without this implementation to us (and might be useless even with it).
Three months, nothing new ion here. Is this being worked on? "Depends on" bug seem to be resolved already..
Timo, you have 2 options: 1) pay 10000 Eur 2) wait. There are no other options.
Also, see comment 17
I parse that as "no". Will wait.
(In reply to comment #22)
> Timo, you have 2 options: 1) pay 10000 Eur 2) wait. There are no other
> options.

There is also 3) Do it yourself.  :)

Later,
Blake.
I describe our scenario for needing to add "User input fields": associations have collective mailboxes, such as: donate@example.net and several people manages it.
The donations workgroup today is formed by Jacob, Emily, Michael and Emma. But tomorrow the workgroup will be formed by Joshua, Madison, Emily and Michael. In a permissions design this means that old accesses for Jacob and Emma tomorrow will be revoked, and new ones for Joshua and Madison will be created, but these modifications must not affect to the continued accesses for Emily and Michael.

In this permissions design, each one of them has it's own username & password to access and use transparently the same mailbox (donate@example.net), then the SMTP/IMAP server has several accounts registered. This is an example schema for access accounts name inside SMTP/IMAP server:
donate@example.net:jacob@gmail.com
donate@example.net:emily@hotmail.com
donate@example.net:michael@gandi.net
donate@example.net:emma@hover.com
donate@example.net:joshua@example.com
donate@example.net:madison@yahoo.com

Following the example, if Emily logs in with username "donate@example.net:emily@hotmail.com", will see ordinary IMAP mailboxes without any difference as Jacob does, and when they sending a message, she will use "donate@example.net:emily@hotmail.com" to log in the SMTP server and send a message From: donate@example.net transparently to destination.

All this scenario and example require
<userinput label="Your individual user name" key="%MEMBERACCESS%"></userinput>

To be used, following the example, in:
<username>%EMAILADDRESS%:%MEMBERACCESS%</username>
In fact, out implementarion of usernames on SMTP&IMAP servers is currently this:
jacob+gmail.com#donate@example.net
emily+hotmail.com#donate@example.net
michael+gandi.net#donate@example.net
emma+hover.com#donate@example.net
joshua+example.com#donate@example.net
madison+yahoo.com#donate@example.net

For this safer format we will need to make a replacement of the character "@" provided by the user, to give the XML with right data. Javascript inside the XML?
I found this bug through
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat#Placeholders
I need to add a username/loginname for the mail server that is not the first part of the e-mail address.
This bug seems not to be worked on after so many years. What a pity!
Is there any other way to add a custom field to the wizard?
Blocks: 564102
A simpler way to "circumvent these problems: if <username></username> is not found in the xml, leave the "Username: " region as a editable box. At the moment I think the username is in this case simply set to 'undefined'.

Or send the user to the 'manual config' screen with the cursor highlighted on the username.
+1 for Yngve's suggestions.  "<username></username>" currently (TB 45) produces the string "true", while no username element at all produces the string "undefined".  Neither of these are likely to be behaviour already in use, and use of one of these would be a simpler syntax than "inputField" or "userinput" element, both of which appear in Ben's description (are they intended as synonyms?). 

Of course that still needs user interface changes.

There is also the question of "a separate POP and SMTP username maybe" - what's the behaviour if one is defined to a string or placeholder and the other undefined?  Ideally, perhaps there would be two password fields, one under incoming server details (filled in), and one as an input field.  Or otherwise manual config.

If inputfield/userinput is provided with attributes should the help text be limited to an example, or also allow "As in your welcome letter, or phone 0800 xxxx"?

Also IMHO should move towards RFC 6186, again filling in fields but allowing 'Manual config'.  See Bug 342242.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.