Index: openacs-4/packages/acs-core-docs/www/groups-requirements.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/groups-requirements.html,v diff -u -r1.34.2.4 -r1.34.2.5 --- openacs-4/packages/acs-core-docs/www/groups-requirements.html 19 Nov 2016 09:21:53 -0000 1.34.2.4 +++ openacs-4/packages/acs-core-docs/www/groups-requirements.html 6 Jan 2017 09:18:41 -0000 1.34.2.5 @@ -8,26 +8,26 @@ 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 - be able to model the the real world's very rich organizational structures + 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, and their departments) or regions (the Boston office, the LA office); a person who is employed by (is a member of) a specific department is also a member of the division and the corporation, and works at (is a member of, but - in a different sense) a particular office. OpenACS's Parties and Groups + in a different sense) a particular office. OpenACS'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
support is limited because it only allows one kind of relationship between
- groups to be represented. Moreover, the Oracle database's limited support
+ 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
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
+ 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
@@ -63,7 +63,7 @@
modeled as groups, and Eddie would be a user. There would be a composition
relationship between each Sierra Club chapter and the Sierra Club. Membership
relationships would exist between Eddie and the Massachusetts Chapter,
- between Eddie and the Sierra Club (due to Eddie's membership in the
+ between Eddie and the Sierra Club (due to Eddie's membership in the
Massachusetts chapter), and between the Sierra Club and Greenpeace.
Membership requirements can vary from group to group. The parties and groups system must provide a base type that specifies the bare minimum necessary to join a group.
The parties and groups system must support constraints between a composite @@ -165,12 +165,12 @@ component of a second group. This API is subject to the constraints laid out in the data model.
The parties and groups system provides an API for deleting a party's +
The parties and groups system provides an API for deleting a party's membership in a group. This API is subject to the constraints laid out in the data model.
The parties and groups system provides an API for deleting a group's +
The parties and groups system provides an API for deleting a group's composition in a second group. This API is subject to the constraints laid out in the data model.