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