Index: openacs-4/packages/acs-core-docs/www/permissions.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/permissions.html,v diff -u -r1.50 -r1.51 --- openacs-4/packages/acs-core-docs/www/permissions.html 27 Oct 2014 16:39:24 -0000 1.50 +++ openacs-4/packages/acs-core-docs/www/permissions.html 7 Aug 2017 23:47:51 -0000 1.51 @@ -1,9 +1,9 @@ -
By Pete Su
+By Pete Su
OpenACS docs are written by the named authors, and may be edited by OpenACS documentation staff.
-The OpenACS 5.7.0 Permissions system allows developers and administrators to
+The OpenACS 5.9.0 Permissions system allows developers and administrators to
set access control policies at the object level, that is, any
application or system object represented by a row in the
acs_objects
table can be access-controlled via a
@@ -21,7 +21,7 @@
The rest of this document discusses each of these parts, and how they fit together with the permissions system.
-OpenACS 5.7.0 has an abstraction called a party. Parties have a recursive
+OpenACS 5.9.0 has an abstraction called a party. Parties have a recursive
definition. We can illustrate how it works with the following
simplified data model. First, we define the parties
table, where each party has an email address and a URL for contact
@@ -84,14 +84,14 @@
some object. Privileges are the basic units out of which we build access
control policies. For example in the Unix filesystem, access is controlled by granting users some combination of
read, write, or execute privileges on files and directories. In
-OpenACS 5.7.0,
+OpenACS 5.9.0,
the table of privileges is organized hierarchically so that developers
can define privileges that aggregate some set of privileges
together. For example, if we have read, write, create and delete
privileges, it might be convenient to combine them into a new privilege
called "admin". Then, when a user is granted "admin" privilege, she is
automatically granted all the child privileges that the privilege
-contains. The OpenACS 5.7.0 kernel data model defines these
+contains. The OpenACS 5.9.0 kernel data model defines these
privileges:
# @@ -136,11 +136,11 @@ OpenACS provides a object contexts as a means for controlling permissions of a large group of objects at the same time.
-In OpenACS 5.7.0, object context is a scoping
+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:
-
... | scope | user_id | group_id | ... |
---|---|---|---|---|
... | user | 123 | ... | |
... | group | 456 | ... | |
... | public | ... |
+
... | scope | user_id | group_id | ... |
---|---|---|---|---|
... | user | 123 | ... | |
... | group | 456 | ... | |
... | 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 @@ -199,7 +199,7 @@
See the package developer tutorials for examples on how to use permissions code.
-OpenACS 5.7.0 defines three separate mechanisms for specifying access control +OpenACS 5.9.0 defines three separate mechanisms for specifying access control in applications.
The Groups data model allows you to define hierarchical organizations of users and groups of users. @@ -211,4 +211,4 @@ permissions in a hierarchical fashion.
A PL/SQL or Tcl API is then used to check permissions in application pages. -