Re: [Evolution-hackers] Mailer lockdown

[Jeffrey Stedfast <fejj ximian com>]

On Wed, 2004-03-03 at 04:01, Not Zed wrote:
> There's been mention in meetings, there's been blog entries, and maybe
> even some code (?), but its time to kick off some discussion here, I
> think.
>
> The account settings is the hardest part, but we can also abstract them
> mostly behind EAccount.
>
> It seems at this point, the easiest solution isn't another xml config
> library with more features (but hey, if we'd used my e-config design, it
> could've been layered on top fairly easily ... :).

this was actually the first thing that came to mind when I saw the lockdown problems caused by using the xml blobs in gconf :-)

"if only we had done it zucchi's way..."

> So we came up with something like:
>  - some specific gconf keys, wherever they live, that define the
> lockdown policies to apply.
>  - logic inside EAccount to enforce the policies, on the specific fields
> relevant to the lockdown policies requested
>  - similar logic inside mail prefs and so on to enforce other policies
>
> One of the problems is how to build the gui based on these policies.
>
> For EAccount, probably the easiest is a method that can return read/
> write status of each possible field in EAccount.
>
> I would suggest a single method rather than a gaggle of methods for each
> possible field.

agreed.

> e.g.
>
> bool = e_account_is_writeable(EAccount *, e_account_field_t field)

looks good (similar to gconf's api, except 'field' is a gconf key string rather than an enum)

> We can then use this, on a per-field basis, to build the gui, together
> with more broad policy stuff.  Of course it might be that we can just
> use the broad policy stuff anyway, but then we need to duplicate some
> logic between the two levels.
>
> We probably also need accessor methods to set the fields, so the
> settings can be enforced too.
>
> I would also prefer a similar mechanism:
>
> e_account_set(EAccount *, field, ...)
>
> Rather than a bazillion set/get method pairs.  I thin kthe get method
> should be optional, it wont add anything in non-threaded code like this.

*nod* sounds good so far...

> Live updating of the lockdown state shouldn't be too much of an issue.

when EAccountList catches the lockdown changes, we'd probably have to emit emit our own signal(s) and catch them in the account editor ui?

> This doesn't cover being able to set specific values for settings 'on
> the fly', it assumes it comes preconfigured in the right state, which we
> dont want to allow you to change.
>
>
> What do we need to work out at least:
>  - what policies we want
>  - how to break up these policies into a set of gconf keys
>  - how to map these gconf key policies to the ui and backend parts, i.e.
> specific ui elements and specific account fields.

I think Anna has at least a partial list as to what sorts of items in the account we'd like to lock down.

stuff like:

- auto-check timeout (possibly also have a min value? - this is actually just my own idea. admin might not care how often a user auto-checks mail as long as it isn't more frequent than every 10 minutes?)
- service type (want to lock users into using IMAP?)
- hostname     (don't want users accidently changing hostname)
- port
- ssl options
- auth options
- remember passwd  (false sense of security since user's will probably just post-it note the passwd their monitor)
- drafts/sent folders seem like a good idea  (admin wants everyone to use the IMAP sent/drafts folders to make backup easier?)
- signature?       (don't allow users to set inappropriate signatures and/or force them to a particular company-wide signature?)
- organisation     (we are the Borg. you will be assimilated...)

unfortunately some of these depend on what the provider exposes as customisable settings. not sure how we'll work that...

Jeff