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.49.2.7 -r1.49.2.8
--- openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 13 Jul 2023 12:43:22 -0000 1.49.2.7
+++ openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.html 1 Aug 2024 08:03:41 -0000 1.49.2.8
@@ -6,13 +6,12 @@
(privilege
) on which object
(object_id
).
- The general permissions system has a flexible (and relatively complex) data model in OpenACS.
+ The general permission system has a flexible (and relatively complex) data model in OpenACS.
Developers who have not had the time to learn the internals of the data model
may end up writing seemingly correct code that crashes their system in
weird ways. This writeup is the result of my running into such a piece
of code and trying to understand exactly what went wrong.
- It is geared towards developers who understand the general permissions
- system to the extent that is described in the
+ It is geared towards developers who understand the general permission system to the extent that is described in the
Groups, Context, Permissions documentation,
but who have not had the opportunity to take a long, careful look at the
@@ -51,7 +50,7 @@
allows developers to define relationships between any two entities A
and B by defining a relationship between their corresponding entries
in the acs_objects
table. One of the applications of this
- powerful capability is the general permissions system.
+ powerful capability is the general permission system.
At the heart of the permission system are two tables: acs_privileges
and acs_permissions
.
@@ -92,7 +91,7 @@
entries of the form:
object_id | grantee_id | privilege |
---|---|---|
object_id_1 | user_id_1 | 'read' |
object_id_1 | user_id_2 | 'read' |
... | ||
object_id_1 | user_id_n | 'read' |
object_id_2 | user_id_1 | 'read' |
object_id_2 | user_id_2 | 'read' |
... | ||
object_id_2 | user_id_n | 'read' |
... | ||
... | ||
object_id_m | user_id_1 | 'read' |
object_id_m | user_id_2 | 'read' |
... | ||
object_id_m | user_id_n | 'read' |
Although quite feasible, this approach fails to take advantage of the fact - that objects in the system are commonly organized hierarchally, + that objects in the system are commonly organized hierarchically, and permissions usually follow the hierarchical structure, so that if user X has the read privilege on object A, she typically also has the read privilege on all objects attached under A. @@ -105,7 +104,7 @@
Suppose objects A, B, ..., and F form the following hierarchy. -
Table 11.2. Context Hierarchy Example
+ Table 11.2. Context Hierarchy Example
|