| Prev | Chapter�15.�Kernel Documentation | Next |
|---|
By Rafael H. Schloming and Mark Thomas
+User directory
Sitewide administrator directory
Subsite administrator directory
TCL script directory
Data model
PL/SQL file
ER diagram
Transaction flow diagram
User directory
Sitewide administrator directory
Subsite administrator directory
TCL script directory
Data model
PL/SQL file
ER diagram
Transaction flow diagram
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.
The primary limitation of the OpenACS 3.x user group system is that it +for different user communities.
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 @@ -24,7 +24,7 @@ (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
The core of the Group Systems data model is quite simple, but it was designed in the hopes of modeling "real world" organizations which can be complex graph structures. The Groups System only considers groups that can be modeled using directed acyclic graphs, but queries over these @@ -37,7 +37,7 @@ without making the system too complex or too slow. The added triggers, views, and tables and will increase storage requirements and the insert and delete times in an effort to speed access time. The limited flexibility (no updates -on membership) trades against the complexity of the code.
The Group System data model consists of the following tables:
The Group System data model consists of the following tables:
The set of all defined parties: any person, user, or group must have a corresponding row in this table.
A mapping of a party P to the set of parties {Pi} party P is an -approved member of.
The API consists of tables and views and PL/SQL functions. -
The group_types table is used to create new types of groups.
The group_member_map, group_approved_member_map, +
The group_types table is used to create new types of groups.
The group_member_map, group_approved_member_map, group_distinct_member_map, group_component_map, party_member_map, and party_approved_member_map views are -used to query group membership and composition.
Person
person.new creates a new person and returns the +used to query group membership and composition.
Person
person.new creates a new person and returns the person_id. The function must be given the full name of the person in two pieces: first_names and last_name. All other fields are optional and default to null except for object_type which defaults @@ -293,13 +293,13 @@ procedure membership_rel.delete ( rel_id composition_rels.rel_id%TYPE ); -
Mark Thomas
| Document Revision # | Action Taken, Notes | When? | By Whom? | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0.1 | Creation | 08/22/2000 | Rafael H. Schloming | ||||||||||||||||
| 0.2 | Initial Revision | 08/30/2000 |
+ Mark Thomas
|