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. >>> >>> >> >
