| Prev | Chapter�11.�Kernel Documentation | Next |
|---|
+
Almost all database-backed websites have users, and need to model the grouping of users. The OpenACS 4 Parties and Groups system is intended to provide the flexibility needed to model complex real-world organizational structures, particularly to support powerful subsite services; that is, where one OpenACS installation can support what appears to the user as distinct web services -for different user communities.
A powerful web service that can meet the needs of large enterprises must +for different user communities.
A powerful web service that can meet the needs of large enterprises must be able to model the the real world's very rich organizational structures and many ways of decomposing the same organization. For example, a corporation can be broken into structures (the corporation, its divisions, @@ -18,27 +18,27 @@ in a different sense) a particular office. OpenACS 4's Parties and Groups system will support such complex relations faithfully.
Historical Motivations
The primary limitation of the OpenACS 3.x user group system is that it restricts the application developer to representing a "flat group" -that contains only users: The user_groups table may contain the -group_id of a parent group, but parent-child relationship +that contains only users: The user_groups table may contain the +group_id of a parent group, but parent-child relationship support is limited because it only allows one kind of relationship between groups to be represented. Moreover, the Oracle database's limited support for tree-like structures makes the queries over these relationships expensive.
In addition, the Module Scoping design in OpenACS 3.0 introduced a party abstraction - a thing that is a person or a group of people - though not in the form of an explicit table. Rather, the triple of -scope, user_id, and group_id columns +scope, user_id, and group_id columns was used to identify the party. One disadvantage of this design convention is that it increases a data model's complexity by requiring the programmer to:
add these three columns to each "scoped" table
define a multi-column check constraint to protect against data corruption -(e.g., a row with a scope value of "group" but a null -group_id)
perform extra checks in Tcl and PL/SQL -functions and procedures to check both the user_id and -group_id values
In sum, the goal of the Parties and Groups system is to +(e.g., a row with a scope value of "group" but a null +group_id)
perform extra checks in Tcl and PL/SQL +functions and procedures to check both the user_id and +group_id values
In sum, the goal of the Parties and Groups system is to provide OpenACS programmers and site administrators with simple tools that fully describe the complex relationships that exist among groups in the real -world.
Pat Developer has a client project and wants to model the company, its offices, its divisions, and its departments as groups and the employees as -users.
We start with Groups, which contain members; the member can be either a person or another group (i.e. a member is a party).
In addition to membership, the party and groups system defines a composition relationship that may exist between groups: A @@ -72,7 +72,7 @@ GC. For example, the system should be able to enforce a rule like: Do not allow a party P to become a member of GC unless P is already -a member of GP.
The data model for the parties and groups system must provide support for +a member of GP.
The data model for the parties and groups system must provide support for the following types of entities:
A party is an entity used to represent either a @@ -118,7 +118,7 @@ GP.
60.10A group may be a component of multiple groups.
60.20A group as a component of itself is not supported.
60.30The data model must support component constraints.
60.40The data model should support the subclassing of -composition via OpenACS Relationships.
The API should let programmers accomplish the following tasks:
The API should let programmers accomplish the following tasks:
The parties and groups system provides a well defined API call that creates a new group by running the appropriate transactions on the parties @@ -219,7 +219,7 @@
Since many SQL queries will check membership in a group as part of the -where clause, whatever mechanism is used to check membership in SQL -should be fairly small and simple.
The user interface is a set of HTML pages that are used to drive the underlying API. The user interface may provide the following functions:
200.0 Create a party
210.0 View the attributes of a party
220.0 Update the attributes of a party
240.0 Delete a party
250.0 Add a party to a group
260.0 Remove a party from a group
270.0 Perform the membership and composition checks -outlined in 130.x to 165.x
| Document Revision # | Action Taken, Notes | When? | By Whom? |
| 0.1 | Creation | 08/16/2000 | Rafael Schloming |
| 0.2 | Initial revision | 08/19/2000 | Mark Thomas |
| 0.3 | Edited and reviewed, conforms to requirements template | 08/23/2000 | Kai Wu |
| 0.4 | Further revised, added UI requirements | 08/24/2000 | Mark Thomas |
| 0.5 | Final edits, pending freeze | 08/24/2000 | Kai Wu |
| 0.6 | More revisions, added composition requirements | 08/30/2000 | Mark Thomas |
| 0.7 | More revisions, added composition requirements | 09/08/2000 | Mark Thomas |
| Document Revision # | Action Taken, Notes | When? | By Whom? |
| 0.1 | Creation | 08/16/2000 | Rafael Schloming |
| 0.2 | Initial revision | 08/19/2000 | Mark Thomas |
| 0.3 | Edited and reviewed, conforms to requirements template | 08/23/2000 | Kai Wu |
| 0.4 | Further revised, added UI requirements | 08/24/2000 | Mark Thomas |
| 0.5 | Final edits, pending freeze | 08/24/2000 | Kai Wu |
| 0.6 | More revisions, added composition requirements | 08/30/2000 | Mark Thomas |
| 0.7 | More revisions, added composition requirements | 09/08/2000 | Mark Thomas |