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


Reply via email to