Index: openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.adp
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.adp,v
diff -u -r1.4 -r1.5
--- openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.adp	25 Apr 2018 08:38:28 -0000	1.4
+++ openacs-4/packages/acs-core-docs/www/permissions-tediously-explained.adp	3 Sep 2024 15:37:32 -0000	1.5
@@ -1,7 +1,11 @@
 
-<property name="context">{/doc/acs-core-docs {ACS Core Documentation}} {OpenACS Permissions Tediously Explained}</property>
+<property name="context">{/doc/acs-core-docs/ {ACS Core Documentation}} {OpenACS Permissions Tediously Explained}</property>
 <property name="doc(title)">OpenACS Permissions Tediously Explained</property>
 <master>
+<style>
+div.sect2 > div.itemizedlist > ul.itemizedlist > li.listitem {margin-top: 16px;}
+div.sect3 > div.itemizedlist > ul.itemizedlist > li.listitem {margin-top: 6px;}
+</style>              
 <include src="/packages/acs-core-docs/lib/navheader"
 			leftLink="parties" leftLabel="Prev"
 			title="Chapter 11. Development
@@ -14,13 +18,13 @@
 Roberto Mello</p><p>The code has been modified since this document was written so it
 is now out of date. See <a class="ulink" href="http://openacs.org/forums/message-view?message_id=121807" target="_top">this forum thread</a>.</p><div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="permissions-tedious-overview" id="permissions-tedious-overview"></a>Permissions Overview</h3></div></div></div><p><span class="strong"><strong>Who (<code class="computeroutput">grantee_id</code>) can do what (<code class="computeroutput">privilege</code>) on which object (<code class="computeroutput">object_id</code>).</strong></span></p><p>The general permissions system has a flexible (and relatively
+<a name="permissions-tedious-overview" id="permissions-tedious-overview"></a>Permissions Overview</h3></div></div></div><p><span class="strong"><strong>Who (<code class="computeroutput">grantee_id</code>) can do what (<code class="computeroutput">privilege</code>) on which object (<code class="computeroutput">object_id</code>).</strong></span></p><p>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
+towards developers who understand the general permission system to
 the extent that is described in the <a class="ulink" href="permissions" target="_top">Groups, Context, Permissions
 documentation</a>, but who have not had the opportunity to take a
 long, careful look at the system internals.</p><p>In OpenACS, most of the interesting tables are expected to
@@ -54,7 +58,7 @@
 OpenACS object system needs to have an entry in the <code class="computeroutput">acs_objects</code>. This allows developers to
 define relationships between any two entities <span class="emphasis"><em>A</em></span> and <span class="emphasis"><em>B</em></span> by defining a relationship between
 their corresponding entries in the <code class="computeroutput">acs_objects</code> table. One of the applications
-of this powerful capability is the general permissions system.</p><p>At the heart of the permission system are two tables:
+of this powerful capability is the general permission system.</p><p>At the heart of the permission system are two tables:
 <code class="computeroutput">acs_privileges</code> and <code class="computeroutput">acs_permissions</code>.</p><a name="acs_privileges" id="acs_privileges"></a><pre class="programlisting">
   create table <span class="bold"><strong>acs_privileges</strong></span> (
       privilege           varchar2(100) not null
@@ -112,7 +116,7 @@
 </tbody>
 </table></div><p>Although quite feasible, this approach fails to take advantage
 of the fact that objects in the system are commonly organized
-hierarchally, and permissions usually follow the hierarchical
+hierarchically, and permissions usually follow the hierarchical
 structure, so that if user <span class="emphasis"><em>X</em></span>
 has the <span class="emphasis"><em>read</em></span> privilege on
 object <span class="emphasis"><em>A</em></span>, she typically also
@@ -127,7 +131,7 @@
 <a name="permissions-tedious-context-hierarchy" id="permissions-tedious-context-hierarchy"></a>Context
 Hierarchy</h3></div></div></div><p>Suppose objects <span class="emphasis"><em>A</em></span>,
 <span class="emphasis"><em>B</em></span>, ..., and <span class="emphasis"><em>F</em></span> form the following hierarchy.</p><div class="table">
-<a name="idp140682187418040" id="idp140682187418040"></a><p class="title"><strong>Table 11.2. Context Hierarchy
+<a name="id1420" id="id1420"></a><p class="title"><strong>Table 11.2. Context Hierarchy
 Example</strong></p><div class="table-contents"><table class="table" summary="Context Hierarchy Example" cellspacing="0" border="1">
 <colgroup>
 <col align="center" class="c1"><col align="center" class="c2"><col align="center" class="c3">
@@ -153,7 +157,7 @@
 </table></div>
 </div><br class="table-break"><p>This can be represented in the <a class="xref" href="permissions-tediously-explained">acs_objects</a>
 table by the following entries:</p><div class="table">
-<a name="idp140682182505032" id="idp140682182505032"></a><p class="title"><strong>Table 11.3. acs_objects example
+<a name="id1421" id="id1421"></a><p class="title"><strong>Table 11.3. acs_objects example
 data</strong></p><div class="table-contents"><table class="table" summary="acs_objects example data" cellspacing="0" border="1">
 <colgroup>
 <col align="center" class="c1"><col align="center" class="c2">
@@ -383,7 +387,7 @@
 context hierarchy.</p>
 </div><div class="sect2">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="permissions-tedious-party-hierarchy" id="permissions-tedious-party-hierarchy"></a>Party Hierarchy</h3></div></div></div><p>Now for the third hierarchy playing a promiment role in the
+<a name="permissions-tedious-party-hierarchy" id="permissions-tedious-party-hierarchy"></a>Party Hierarchy</h3></div></div></div><p>Now for the third hierarchy playing a prominent role in the
 permission system. The party data model is set up as follows.</p><div class="informaltable"><table class="informaltable" cellspacing="0" border="1">
 <colgroup>
 <col align="center" class="c1"><col align="center" class="c2">
@@ -487,7 +491,7 @@
 </tr>
 </tbody>
 </table></div><p>Read <code class="computeroutput">acs_rels</code>: right-side is
-a subset of left-side, ie <code class="computeroutput">object2</code> is a part of <code class="computeroutput">object1</code>.</p><p>Another way of building up groups is by adding subgroups.
+a subset of left-side, i.e. <code class="computeroutput">object2</code> is a part of <code class="computeroutput">object1</code>.</p><p>Another way of building up groups is by adding subgroups.
 Suppose we define <span class="emphasis"><em>Merry
 Pranksters</em></span> and <span class="emphasis"><em>Sad
 Pranksters</em></span> as subgroups of <span class="emphasis"><em>Pranksters</em></span>. We say that the <span class="emphasis"><em>Pranksters</em></span> group is <span class="strong"><strong>composed</strong></span> of groups <span class="emphasis"><em>Merry Pranksters</em></span> and <span class="emphasis"><em>Sad Pranksters</em></span>. This information is