+ Horde Group Policy Objects (or perhaps some other name, as Microsoft may have a copyright on that term) The idea of Horde Group Policy Objects (HGPO) is to implement a replacement for the current prefs system, modeled after how Group Policy Objects work in a Microsoft Active Directory. Including a nice administrative GUI, meaning no more editing prefs.php files, and happier admins :) ---- ++ Visualization of a HGPO <code> + app | + prefgroup | | + pref | | + pref | + prefgroup | + pref + app + prefgroup + pref </code> * The list of apps would be pulled from the registry * each app would have a prefs.xml file defining what prefs are available. * bundle the GPO and specify a target. A target can consist of: * entire horde installation * horde group * individual user * guest user * OU if using LDAP backend ---- ++ What would need to be done * build a HGPO manager to list, create, edit, delete, etc. HGPO's * Store HGPO in DB table(s) * horde_gpo table? * possible extend the datatree * would (Rampage|RDO) apply? Possible DB schema, extending existing prefs schema: **horde_prefs** table: {{pref_uid, pref_scope, pref_name, pref_value, HGPO}} * If pref_uid is set, the pref is a user pref * if HGPO is set, it is a HGPO pref * what happens if both are set? **horde_gpo** table: {{HGPO_ID, HGPO_name, HGPO_target, HGPO_target_type, HGPO_override_user_settings}} * link horde_gpo::HGPO_ID to horde_prefs::HGPO to get a list of prefs belonging to a given HGPO. ---- ++ Other Thoughts * all $pref->getValue() calls could be handled on the backend by a HGPO manager, giving us a drop-in replacement. * we'd need a way to clearly define what happens if two HGPO's have overlapping, conflicting settings. ---- ++ Links http://www.microsoft.com/technet/itsolutions/msit/security/grppolobjectmgmt.mspx - gives a good overview on how MS GPO's work, and a nice graphic that really helped me visualize the internal workings.