[dev] Horde Group Policy Objects

[Chuck Hagenbuch]

Quoting Ben Chavet <ben at horde.org>:

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

Okay, that's fine. I don't know enough about LDAP to really say. Just  
an (uneducated) gut reaction.

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

UI-wise you can state the negative if you like, but your wording does  
sound good.

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

Yes, you have to hack the code to use the custom prefs. But I know  
people do this, so I was hoping to hear from some of the people who do.

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

There's a bootstrapping issue; you need to configure the GPO driver  
somewhere. :) I think it makes sense to move:

- anything that is anything like a user preference, whether an admin  
would ever unlock it or not.
- anything that is like a backend, where admins can manage a set of  
backends and who can access them.

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

Awesome. Looking forward to it.

-chuck

-- 
"we are plastered to the windshield of the bus that is time." - Chris