Index: openacs-4/packages/acs-core-docs/www/xml/developers-guide/permissions-tediously-explained.xml =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/xml/developers-guide/permissions-tediously-explained.xml,v diff -u -N -r1.8 -r1.9 --- openacs-4/packages/acs-core-docs/www/xml/developers-guide/permissions-tediously-explained.xml 25 Sep 2006 20:32:37 -0000 1.8 +++ openacs-4/packages/acs-core-docs/www/xml/developers-guide/permissions-tediously-explained.xml 7 Aug 2017 23:47:54 -0000 1.9 @@ -359,7 +359,7 @@ ..., and F can be derived by ascertaining that these objects are children of A by traversing the context hierarchy. As it turns out, hierarchical queries are expensive. As - Rafael Schloming put it so aptly, Oracle can't deal with hierarchies for shit. + Rafael Schloming put it so aptly, Oracle can't deal with hierarchies for shit. @@ -535,7 +535,7 @@ One final note about . By setting - an object's security_inherit_p column to 'f', you can stop permissions + an object's security_inherit_p column to 'f', you can stop permissions from cascading down the context tree. In the following example, Joe does not have the read permissions on C and F. @@ -1129,7 +1129,7 @@ as exists_p char(1); begin - -- XXX This must be fixed: -1 shouldn't be hardcoded (it is the public) + -- XXX This must be fixed: -1 shouldn't be hardcoded (it is the public) select decode(count(*),0,'f','t') into exists_p from where object_id = permission_p.object_id