[cvs] [Wiki] changed: HordePolicy

[Ben Chavet]

ben  Tue, 23 May 2006 21:51:25 -0700

Modified page: http://wiki.horde.org/HordePolicy
New Revision:  1.20
Change log:  API notes

@@ -82,8 +82,25 @@
 target_type  <-- 'uid', 'gid', 'app', or 'global'/'default'
 </code>
 
 We can get the attribute group structure from the XML file.  No need to worry about storing it, just need to enforce that all attributes for a given app have unique names.  If there are two attributes with the same name, we should use the last one found in the XML file.
+
+----
+
+++ Cascading Heirarchy
+
+Listed by priority, highest-priority first.  All levels would need to be checked, though, as some lower level might have the overridable bit set to false.
+
+* **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.
+* **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.
+
+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?
 
 ----
 
 ++ Cache
@@ -100,8 +117,32 @@
 * 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.
+
+----
+
+++ API
+
+Some thoughts about an API for Horde_Policy
+
+<code type=php">
+class Horde_Policy {
+    var $name // policy name
+    var $targets // array of targets
+    var $attributes // array of attributes
+    var $_params // storage parameters
+    function name($name) {} // get/set policy name
+    function attribute($attribute, $params) // set given attribute
+    function addTarget()
+    function removeTarget()
+    function listTargets()
+    static function getPolicyAttribute($attribute) // go through the cascading heirarchy, and return the value with priority (see Cascading Heirarchy above)
+}
+</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.
 
 ----
 
 ++ Links