Closed Bug 29593 Opened 20 years ago Closed 7 years ago

[autoconfig] pre-populate the users fullname in the new mail account wizard

Categories

(MailNews Core :: Account Manager, enhancement)

enhancement
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 22.0

People

(Reporter: sspitzer, Assigned: mkmelin)

References

Details

Attachments

(1 file, 1 obsolete file)

use nsIUserInfo to pre-populate the users fullname in the new mail account
wizard.

eventually, nsIUserInfo will be extended to pre-populate more fields in the new
account wizard.

note, the implementations of nsIUserInfo are not checked in yet.
Status: NEW → ASSIGNED
Depends on: 29594, 29596
QA Contact: lchiang → nbaca
Summary: pre-populate the users fullname in the new mail account wizard → pre-populate the users fullname and email address in the new mail account wizard
Target Milestone: M15
marking m15, so that the owners of 29594 and 29596 know when I'd like to check
in.

I have this working for unix with nsUserInfoUnix and I've got the changes to
aw-identity.js (in my local tree) so that the pre-population works on unix.

this is not a high priority bug, and it can be delayed if the mac and windows
implementations get delayed.
the windows implementation of nsUserInfo is done, and I just have to change the 
makefile.win to have it build. 
fix in hand.
Whiteboard: fix in hand.
moving to m14.
Target Milestone: M15 → M14
moving out to m17.

this is not a beta2 priority feature.

it works on unix right now, but not mac or windows.
Target Milestone: M14 → M17
Summary: pre-populate the users fullname and email address in the new mail account wizard → UI: pre-populate the users fullname and email address in the new mail account wizard
Mail Review hopes this is post-beta2, easy, polish work.  Marking M18.
Target Milestone: M17 → M18
updating status whiteboard.  just waiting for the windows impl.  
Whiteboard: fix in hand. → mac & unix done. win32 still needs to be implemented.
I can try to take a look at this some time before m18.
Assignee: sspitzer → dougt
Status: ASSIGNED → NEW
I stoled the wrong bug.  Reassigning to sspitzer.
Assignee: dougt → sspitzer
not going to get to the win32 implementation for 6.0

moving to future.
Status: NEW → ASSIGNED
Target Milestone: M18 → Future
Whiteboard: mac & unix done. win32 still needs to be implemented. → mac & unix done. win32 & OS/2 still need to be implemented.
adding mike to the cc list.

I guess I'm the on the hook to get this working for win32.

law, you interested in the win32 implementation?
Sure.  I'll add it to my/our list for the next train.
Whiteboard: mac & unix done. win32 & OS/2 still need to be implemented. → mac & unix done. win32 & OS/2 still need to be implemented. CMVC32859
Component: Mail Window Front End → Account Manager
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: nbaca
Target Milestone: Future → ---
Assignee: mail → nobody
Component: MailNews: Account Configuration → Backend
Product: SeaMonkey → MailNews Core
QA Contact: backend
I'm pretty sure this is now properly covered by the new autoconfig dialogs.
Not on linux, at least.
Summary: UI: pre-populate the users fullname and email address in the new mail account wizard → [autoconfig] pre-populate the users fullname in the new mail account wizard
Severity: normal → enhancement
Component: Backend → Account Manager
QA Contact: backend → account-manager
Depends on: 581508
|nsIUserInfo.fullname| works for me on Linux.
Mac looks implemented, too, but can't test.
Win32 is still not implemented. :-(
<http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/components/startup/src/nsUserInfoWin.cpp>
Filed bug 581508 about Win32.
Bug 561531 is about username.
(Neither username nor email address should be filled in blindly from the OS, because it's very likely to be wrong (e.g. "ben@(none)" for me), and definitely wrong for users with multiple email accounts. That bug asks to allow *specific* configs for some domains to use the OS username as placeholder.)
Attached patch proposed fix (obsolete) — Splinter Review
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #690524 - Flags: review?(bwinton)
Attachment #690524 - Flags: feedback?(ben.bucksch)
Hardware: x86 → All
Whiteboard: mac & unix done. win32 & OS/2 still need to be implemented. CMVC32859
Comment on attachment 690524 [details] [diff] [review]
proposed fix

Huh.  It knew my name.  That's equal parts cool and creepy.  :)

>+++ b/mail/components/newmailaccount/content/accountProvisioner.js
>@@ -249,16 +249,23 @@ var EmailAccountProvisioner = {
>+    if (!name) {
>+      try {
>+        let userInfo = Components.classes["@mozilla.org/userinfo;1"]
>+                                 .getService(Components.interfaces.nsIUserInfo);

I'ld prefer
        let userInfo = Cc["@mozilla.org/userinfo;1"].getService(Ci.nsIUserInfo);
or perhaps we could even add it to MailServices.js.

>+++ b/mailnews/base/prefs/content/accountcreation/emailWizard.js
>@@ -137,19 +137,27 @@ EmailConfigWizard.prototype =
>+      userInfo = Components.classes["@mozilla.org/userinfo;1"]
>+                           .getService(Components.interfaces.nsIUserInfo);

It looks like Cc and Ci are available here, too.

>-    this._realname = "";
>+    this._realname = (userInfo) ? userInfo.fullname : "";

If we have a userInfo object, is it guaranteed to have a non-null fullname?

r=me with those two nits fixed, and that question answered.

Thanks,
Blake.
Attachment #690524 - Flags: review?(bwinton) → review+
> That's equal parts cool and creepy.  :)

We try to please.
http://hg.mozilla.org/comm-central/rev/057219336b07 -> FIXED

I looked it up and it looks like the getters needed to be in trycatch too, at least in theory.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 20.0
This causes perma-oranges:

TEST-UNEXPECTED-FAIL | c:\talos-slave\test\build\mozmill\account\test-mail-account-setup-wizard.js | test-mail-account-setup-wizard.js::test_mail_account_setup
TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during directory run
Bug 661906 - Random Orange TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during test_order_of_address_books TEST-UNEXPECTED-FAIL | c:\talos-slave\test\build\mozmill\newmailaccount\test-newmailaccount.js | test-newmailaccount.js::test_search_button_disabled_if_no_query_on_init
Bug 707105 - Near-perma-orange: TEST-UNEXPECTED-FAIL | test-newmailaccount.js | test-newmailaccount.js::test_get_an_account
Bug 710912 - Permanent orange on Linux: TEST-UNEXPECTED-FAIL | test-newmailaccount.js | test_can_pref_off_account_provisioner TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during directory run
Bug 661906 - Random Orange TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during test_order_of_address_books
backed out http://hg.mozilla.org/comm-central/rev/c8bbd750e1b4
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch proposed fix, v2Splinter Review
Tests needed updating.
Successful try run: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=35ff96164f13
Attachment #690524 - Attachment is obsolete: true
Attachment #690524 - Flags: feedback?(ben.bucksch)
Attachment #706858 - Flags: review?(bwinton)
Attachment #706858 - Flags: feedback+
Comment on attachment 706858 [details] [diff] [review]
proposed fix, v2

Given the successful try run, this is more of an rs=me.  ;)

Thanks,
Blake.
Attachment #706858 - Flags: review?(bwinton) → review+
http://hg.mozilla.org/comm-central/rev/4e99a6a55f80 -> FIXED
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: Thunderbird 20.0 → Thunderbird 22.0
You need to log in before you can comment on or make changes to this bug.