I got the New Account Wizard to come up by editing the pref files by hand and adding a server and identity and marking the identity as invalid. It even works if I put these settings into the .cfg file. But there is still one problem using this approach. How do I create the new account (mail.accountmanager.accounts)? The webmail scheme does it programmatically while the client is running. I am trying to configure an install image. I don't want to whack any existing mail accounts that the end user may already have.
Steve Meredith wrote: > Is it "mail.identity.id1.valid" by any chance? > > Steve Meredith wrote: > >> OK, I don't see anything that looks like it's marking the account as >> incomplete. Another hint, perhaps? >> >> Alec Flett wrote: >> >>> >>> >>> Steve Meredith wrote: >>> >>>> In which case you would have to set up all the prefs for an account, >>>> including username, right? We can't know that in advance, unless >>>> somebody wants to configure a client for each and every user. Can we >>>> set some prefs in the .cfg and then somehow tie them to the account >>>> created by the wizard? >>>> >>> >>> >>> Not necessarily. One thing you can do (not that this is at all >>> obvious) is to mark an account as "incomplete" - then the wizard will >>> run through and "complete" the account by reconfirming all the values >>> with the user... this is how Netscape "activates" webmail accounts - >>> they create an incomplete account during setup (they actually fill in >>> the username, but you don't have to) and then mark the account as >>> "incomplete" - >>> >>> then when the user first launches mail, they will get prompted to >>> "complete" the account by confirming a bunch of values. WebMail >>> actually skips specific pages of the wizard, which you could possibly >>> do as well... check out the sample .rdf files in mailnews/base/isp >>> >>> >>> >>>> Alec Flett wrote: >>>> >>>>> Ah,. hmm.. I guess it would make sense to be able to lock them in a >>>>> standard way >>>>> >>>>> one thing you could do is manually set up these accounts by setting >>>>> the initial default prefs in your .cfg file, and then locking >>>>> specific prefs. The account keys are garanteed if _you_ create >>>>> them. See http://www.mozilla.org/mailnews/arch/accountmanager.html >>>>> for details on how they are stored in prefs.js >>>>> >>>>> Alec >>>>> >>>>> Stephen Meredith wrote: >>>>> >>>>>> >>>>>>> Actually, the RDF does expose all preferences, automatically >>>>>>> (i.e. there's no code which picks and chooses which prefs >>>>>>> are/aren't supported) >>>>>>> the RDF is translated into strings which are used by xpconnect to >>>>>>> get to all the standard mail interfaces, like >>>>>>> nsIMsgIncomingServer, nsIMsgIdentity, nsIImapIncomingServer and >>>>>>> so forth. All per account mail prefs are done through that >>>>>>> mechanism, so all per account mail prefs are exposed via the RDF >>>>>>> file. >>>>>>> >>>>>> >>>>>> >>>>>> Excellent. I didn't pick up on that. >>>>>> >>>>>> Any suggestions on how to protect the mail prefs? For other prefs, >>>>>> we are putting them into a hashed .cfg and locking them. I think >>>>>> it makes sense for an IT admin to want to lock some of them. >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >
