Index: openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html,v diff -u -r1.46.2.10 -r1.46.2.11 --- openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 21 Jun 2016 07:44:36 -0000 1.46.2.10 +++ openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 23 Jun 2016 08:32:46 -0000 1.46.2.11 @@ -152,7 +152,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.

One way to solve this problem is to cache a flattened view of the context tree like so:

objectancestorn_generations
AA0
BB0
BA1
CC0
CA1
DD0
DB1
DA2
EE0
EB1
EA2
FF0
FC1
FA2

@@ -223,7 +223,7 @@

One final note about acs_objects. 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.

@@ -615,7 +615,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 acs_object_party_privilege_map where object_id = permission_p.object_id