#
begin
acs_privilege.create_privilege('read');
@@ -125,8 +125,8 @@
In OpenACS 5.9.0, object context is a scoping mechanism.
-"Scoping" and "scope" are terms best explained by example: consider
-some hypothetical rows in the address_book table:
+"Scoping" and "scope" are terms best explained
+by example: consider some hypothetical rows in the address_book table:
@@ -140,15 +140,13 @@
... public...
-
The first row represents an entry in User 123's personal address
-book, the second row represents an entry in User Group 456's shared
-address book, and the third row represents an entry in the site's
-public address book. In this way, the scoping columns identify the
-security context in which a given object belongs, where each
-context is either a person
-or a group of people
-or the general public
-(itself a group of people).
Every object lives in a single context. A context is just an another
+
The first row represents an entry in User 123's personal
+address book, the second row represents an entry in User Group
+456's shared address book, and the third row represents an
+entry in the site's public address book. In this way, the
+scoping columns identify the security context in which a given
+object belongs, where each context is either a person or a group of people or the general public (itself a group of
+people).
Every object lives in a single context. A context is just an another
object that represents the security domain to which the object
belongs. By convention, if an object A does not have any
permissions explicitly attached to it, then the system will look at
@@ -160,8 +158,8 @@
If security_inherit_p flag
is set to 't', then the
automatic search through the context happens, otherwise it does
-not. You might set this field to 'f' if you want to override the default
-permissions in a subtree of some context.
For an example of how to use context hierarchy, consider the
+not. You might set this field to 'f' if you want to override the
+default permissions in a subtree of some context.
For an example of how to use context hierarchy, consider the
forums application. With only row-level permissions it is not
obvious how to reasonably initialize the access control list when
creating a message. At best, we have to explicitly grant various
@@ -171,14 +169,15 @@
forum. Then, suppose we grant every user in the system read-access
to this forum. By default, they will automatically have read-access
to the new message we just inserted, since the system automatically
-checks permissions on the message's context. To allow the creator
-of the message to change the message after it has been posted we
-grant the user write-access on the message, and we are done.
This mechanism allows developers and administrators to define a
+checks permissions on the message's context. To allow the
+creator of the message to change the message after it has been
+posted we grant the user write-access on the message, and we are
+done.
This mechanism allows developers and administrators to define a
hierarchy that matches the structure they need for access control
in their application. The following picture shows a typical context
-hierarchy for a hypothetical site:
The top two contexts in the diagram are called "magic" numbers,
-because in some sense, they are created by default by OpenACS for a
-specific purpose. The object default_context represents the root of the
+hierarchy for a hypothetical site:
The top two contexts in the diagram are called "magic"
+numbers, because in some sense, they are created by default by
+OpenACS for a specific purpose. The object default_context represents the root of the
context hierarchy for the entire site. All permission searches walk
up the tree to this point and then stop. If you grant permissions
on this object, then by default those permissions will hold for
@@ -197,8 +196,8 @@
user rights.