[cvs] [Wiki] changed: HordePolicy

[Ben Chavet]

ben  Wed, 24 May 2006 22:40:36 -0700

Modified page: http://wiki.horde.org/HordePolicy
New Revision:  1.25
Change log:  tweaks

@@ -24,8 +24,9 @@
 </code>
 
 * each app would have a policy.xml file defining what policy attributes are available.
 * A target can consist of one or more:
+ * entire installation
  * horde application
  * horde group
  * individual user
  * guest user
@@ -62,22 +63,22 @@
 
 <code>
 horde_policy_attributes
 -----------------------
-policy_id
+policy_id  <-- what policy this attribute belongs to.
 attribute_name
-attribute_scope
-attribute_state  <-- mask for things like enabled, disabled, overridable, etc.
+attribute_value
+attribute_scope  <-- what app is this attribute defined in?
+attribute_overridable  <-- can the value be overridden?
 attribute_type  <-- what data type are we working with?
-attribute_value
 </code>
 
 <code>
 horde_policy_targets
 --------------------
-policy_id
-target_id  <-- uid, gid, app-name, or global/default
-target_type  <-- 'uid', 'gid', 'app', or 'global'/'default'
+policy_id  <-- what policy this target belongs to.
+target_id  <-- uid, gid, app, site, or guest
+target_type  <-- 'uid', 'gid', 'app', 'site', or 'guest'
 </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.
 
@@ -89,9 +90,10 @@
 
 * **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
+* **app** - policy applied to current app.
+* **site** - policy applied to entire site.
 * **default** - default value pulled from XML file.
 
 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.
 
@@ -138,15 +140,17 @@
 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
+++ Steps involved 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
+
+Should we apply Policy values at login, or when an app is loaded?
 
 ----
 
 ++ Links
@@ -154,9 +158,9 @@
 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.
 
 ----
 
-++ Cut & Paste from mailing list until I can better organize my thoughts
+++ Long term goals from mailing list
 
 > - 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