[cvs] [Wiki] changed: HordeGPO

Ben Chavet ben at horde.org
Wed May 17 20:43:54 PDT 2006


ben  Wed, 17 May 2006 20:43:54 -0700

Modified page: http://wiki.horde.org/HordeGPO
New Revision:  1.7
Change log:  settle on "Horde Policy" name

@@ -1,14 +1,13 @@
 [[toc]]
 
-+ Horde Group Policy Objects
-(or perhaps some other name, as Microsoft may have a copyright on that term)
++ Horde Policies
 
-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 :)
+The idea of Horde Policy 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
+++ Visualization of a Horde Policy
 
 <code>
 + app
 |  + prefgroup
@@ -22,9 +21,9 @@
 </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:
+* bundle the policy and specify a target.  A target can consist of:
  * entire horde installation
  * horde group
  * individual user
  * guest user
@@ -33,26 +32,12 @@
 ----
 
 ++ 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 ((RampageFramework|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_overridable}}
-**horde_gpo_targets** table: {{HGPO_ID, target_type, target}}
-
-* link horde_gpo::HGPO_ID to horde_prefs::HGPO to get a list of prefs belonging to a given HGPO.
+* build a Horde Policy manager to list, create, edit, delete, etc. policies.
+* Store Horde Policies in DB table(s)
+ * horde_policy table(s)?
+ * extend the datatree?  The data structure fits perfectly with a few performance tweaks
 
 ----
 
 ++ Storage
@@ -92,16 +77,16 @@
 ----
 
 ++ Cache
 
-At login, all applicable GPO's should be loaded and cached.  We should also try to do something to cache GPO's for guest sessions.
+At login, all applicable Policies should be loaded and cached.  We should also try to do something to cache Policies for guest sessions.
 
 ----
 
 ++ 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.
+* all $pref->getValue() calls could be handled on the backend by writing a Policy driver for the Prefs system, giving us a drop-in replacement.
+* we'd need a way to clearly define what happens if two Horde Policies have overlapping, conflicting settings.
 * there should be a default "root" policy, which cannot be detached from the root installation.  This policy would be a site-wide policy that always exists.
 
 ----
 


More information about the cvs mailing list