[cvs] [Wiki] changed: HordePolicy

Wed May 24 22:12:55 PDT 2006

ben  Wed, 24 May 2006 22:12:55 -0700

Modified page: http://wiki.horde.org/HordePolicy
New Revision:  1.23
Change log:  steps for applying a policy, leave hooks to Prefs, minor cleanups and clarifications

@@ -18,25 +18,22 @@
 `-- app2 (ie, turba)
     |--attribute-group1
     |   |-- attribute-group2
     |   |   `-- attribute1
-    |   |       `-- value
     |   `-- attribute2
-    |       `-- value
     `-- attribute3
-        `-- value
 </code>
 
 * each app would have a policy.xml file defining what policy attributes are available.
 * A target can consist of one or more:
- * default (applies to entire installation)
- * horde application (including 'horde')
+ * horde application
  * horde group
  * individual user
  * guest user
- * OU if using LDAP backend
 
 This structure should be easy to cache when a given app is loaded.  something like {{ if (!isset($policy[$app])) { load $policy[$app] from xml } }}.
+
+Not something that we would really enforce in code, but we could have an organizational convention that we stick to in the xml files, so that each app has a common policy structure.  Something like 'prefs', 'config', 'backends', 'servers', etc.
 
 ----
 
 ++ What would need to be done
@@ -69,9 +66,8 @@
 policy_id
 attribute_name
 attribute_scope
 attribute_state  <-- mask for things like enabled, disabled, overridable, etc.
-attribute_hook  <-- if defined, use it to get the default value for this attribute.
 attribute_type  <-- what data type are we working with?
 attribute_value
 </code>
 
@@ -93,15 +89,14 @@
 
 * **user-defined** - value defined by the user.
 * **uid** - policy applied directly to the current user.
 * **gid** - policy applied to a group that the current user is a member of.
-* **app** - policy applied to current app, including 'horde'
-* **root** - default "root" policy, always present.
+* **app** - policy applied to current app
 * **default** - default value pulled from XML file.
 
-I haven't decided if it would be better to check from top to bottom, or bottom to top.  bottom-to-top would give us quicker results if overridable is false at any level.  top-to-bottom would give us the "real" value faster, assuming overridable is not false at some lower level.
+When loading a policy, we should go bottom-to-top in this list.  Any new values in higher levels can just overwrite the values found in lower levels, unless a lower level has specified that the value is not overridable.
 
-Also, we need to work out a way to resolve collisions at a given level.  For example, a user might be a member of various groups, and each group might have a different value set for a given attribute.  If there is not a value set at a higher level, how do we decide which takes priority?  Sort alphabetically?  Give a priority to overridable?
+We need to work out a way to resolve collisions at a given level.  For example, a user might be a member of various groups, and each group might have a different value set for a given attribute.  If there is not a value set at a higher level, how do we decide which takes priority?  Sort alphabetically?  Give a priority to overridable?  Add documentation saying that this behaviour is undefined and leave it up to admins to avoid collisions?
 
 ----
 
 ++ Cache
@@ -117,9 +112,8 @@
 * 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.
 * Should we keep a history of who created or edited a policy?  Can we use the history classes for this?
-* Hooks should definitely come into play somehow.  Perhaps store the name of the hook function with the attribute, where there is no hook if this is null?
 * Do we need a Policy "manager" object like we have with the DataTree?  Or should we include static functions to Horde_Policy?  do static functions get copied for each instance of an object?  If so, the "manager" object might be the way to go.
 
 ----
 
@@ -142,8 +136,18 @@
 }
 </code>
 
 Still need to be able to read from XML, not sure if that should be put in the constructor, or in the public API.  Also need to be able to save to backend somehow.
+
+----
+
+++ What happens when applying a Horde Policy
+
+* read XML file(s) to set up internal attribute tree with default values.
+* see if any policies target the current user, if so...
+ * go through target cascade (see above), pulling values from SQL
+ * overwrite default values with values pulled from SQL
+* cache
 
 ----
 
 ++ Links
@@ -168,18 +172,4 @@
 > 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!
 
-----
-
-Notes:
-
-**Horde_Policy** - name(sql), settings(xml), targets(sql)
-
-**Horde_Policy_Target** - target(sql)
-
-**Horde_Policy_Setting**(xml) - name, desc, attributes
-* Setting status can be stored in an attribute
-* Extend Horde_Policy_Attribute to allow other Horde_Policy_Settings in the attributes list.
-
-**Horde_Policy_Attribute** - name(sql), type(xml), value(sql), hook(sql)
-* by incorporating a "type" in the xml, we can store a serialized array for dynamic lists (ie, IMAP servers).
