[dev] Horde Group Policy Objects

[Ben Chavet]

>> This is definitely something that I would like to see take shape.
>
> Looks good, and very useful. A few comments on the wiki page:
>
> - you say that a GPO target could be an OU if using LDAP. I feel
> pretty strongly right now that this should be handled by the
> Groups_ldap driver, instead of being another special case.

Depending on how you want Groups_ldap to handle this, I might have to
disagree.  While an OU is a group in an organizational sense, it is
not a group in the users/groups sense.  I know I certainly wouldn't
want the OU's in my LDAP directory showing up in my groups listing.
Of course, I'm just brain-storming at this point, and OU attachment of
a GPO would definitely be a special case, and most likely the last
thing implemented, if at all.  It might not even turn out be a
feasible target.

> - this is semantic, but I'd prefer HGPO_overridable to
> HGPO_override_user_settings

So, UI-wise, instead of "Override user settings", it'd be "Allow users
to override this setting".  Sounds good to me.

> - prefs caching does us a world of good here, in terms of only having
> to build and apply any applicable GPOs at user login. it'd be
> important to make sure that guest sessions included cached guest
> preferences, though, for any real use of this with guest users. I
> don't think we currently do that.

Makes sense.

> - we've been looking at prefs.xml for a while. One consideration is
> how to allow for custom prefs, or if we still need to do that (could
> just be, if you need them, you modify prefs.xml - but I can see
> needing to be more flexible).

I'm not sure what the benefit would be of allowing custom prefs, maybe
I'm being too closed-minded, though.  If we allow custom prefs, they
aren't going to do anything unless the code is hacked to use the pref,
right?  If that's the case, then I think requiring modification to
prefs.xml should be sufficient.

> - with something like this in place I think it would make more and
> more sense to move everything that's at all user-related in conf.php
> files to this system. Things like "user capabilities" in both Horde
> and IMP - they can even be locked (overridable = false?) by default,
> but letting people easily manage them on a per-group basis, or
> whatever, sounds very good to me.

Just brainstorming here, but we could even go a step further and use  
this type of system for all of the configs (except for maybe the very  
basic stuff, like authentication).  Doing so would let different  
groups have different configs, which might be helpful for sites  
hosting for various groups.

> If there were a way to manage, say, IMAP server configs, or other
> backend configurations (sieve servers, etc.) using this system, that
> would be even better.

Yes!  We could put IMAP server configs, etc. in a GPO and assign to  
targets as necessary.  Same way that printers can be assigned in an  
active directory.  "group A uses this IMAP server, group B uses this  
other IMAP server, group C gets to specify their own IMAP server." The  
possibilities are endless! I love it!

> All in all, I really like it as a direction.

I appreciate the feedback!  I'll start working on solidifying the  
concepts and get the ball rolling with it.

--Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: PGP Digital Signature
Url : http://lists.horde.org/archives/dev/attachments/20060503/ba2b30ab/attachment.bin