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_idgrantee_idprivilege
object_id_1user_id_1'read'
object_id_1user_id_2'read'
...
object_id_1user_id_n'read'
object_id_2user_id_1'read'
object_id_2user_id_2'read'
...
object_id_2user_id_n'read'
...
...
object_id_muser_id_1'read'
object_id_muser_id_2'read'
...
object_id_muser_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 @@

Context Hierarchy

Suppose objects A, B, ..., and F form the following hierarchy. -

Table 11.2. Context Hierarchy Example

+

Table 11.2. Context Hierarchy Example

A

object_id=10 @@ -139,7 +138,7 @@ This can be represented in the acs_objects table by the following entries: -

Table 11.3. acs_objects example data

object_idcontext_id
2010
3010
4020
5020
6030

+

Table 11.3. acs_objects example data

object_idcontext_id
2010
3010
4020
5020
6030

The first entry tells us that object 20 is the descendant of object 10, and the third entry shows that object 40 is the descendant of object 20. By running a CONNECT BY query, @@ -324,7 +323,7 @@ view of the privilege hierarchy in a specially maintained table like it is done in the case of the context hierarchy.

Party Hierarchy

- Now for the third hierarchy playing a promiment role in the permission system. The party + Now for the third hierarchy playing a prominent role in the permission system. The party data model is set up as follows.