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.6 -r1.7 --- openacs-4/packages/acs-core-docs/www/groups-requirements.html 10 Aug 2002 20:07:20 -0000 1.6 +++ openacs-4/packages/acs-core-docs/www/groups-requirements.html 30 Nov 2002 17:16:24 -0000 1.7 @@ -1,9 +1,9 @@ -
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 +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 -group can be a component of another group. The child group +composition relationship that may exist between groups: A +group can be a component of another group. The child group is called a component group; the parent group is called a -composite group.
A group Gc can be a member and/or a component -of another group Gp; the difference is in the way -the members of Gc are related to -Gp:
If a party P is a member (or a component) of -Gc and if Gc is a -component of Gp, then P is also -a member (or a component) of Gp
If a party P is a member (or a component) of -Gc and if Gc is a -member of Gp, then no -relationship between P and -Gp exists as a result of the relationship between -Gp and Gp.
Consider an example to make this less abstract: Pretend that the Sierra +composite group.
A group Gc can be a member and/or a component +of another group Gp; the difference is in the way +the members of Gc are related to +Gp:
If a party P is a member (or a component) of +Gc and if Gc is a +component of Gp, then P is also +a member (or a component) of Gp
If a party P is a member (or a component) of +Gc and if Gc is a +member of Gp, then no +relationship between P and +Gp exists as a result of the relationship between +Gp and Gp.
Consider an example to make this less abstract: Pretend that the Sierra Club is a member of Greenpeace. The Sierra Club has chapters; each chapter is a component of the Sierra Club. If Eddie Environmentalist is a member of the Massachusetts Chapter of the Sierra Club, Eddie is @@ -68,160 +68,158 @@ 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 -group GP and any of its component groups, -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 -the following types of entities:
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 -group or a person.
The data model should enforce these constraints:
10.10 A party has an email address, which can be -empty.
10.20 A party may have multiple email addresses -associated with it.
10.30 The email address of a party must be unique within -an OpenACS system.
A party is an entity used to represent either a +group or a person.
The data model should enforce these constraints:
10.10 A party has an email address, which can be +empty.
10.20 A party may have multiple email addresses +associated with it.
10.30 The email address of a party must be unique within +an OpenACS system.
A group is a collection of zero or more parties.
20.10 The data model should support the subclassing of -groups via OpenACS Objects.
A group is a collection of zero or more parties.
20.10 The data model should support the subclassing of +groups via OpenACS Objects.
A person represents an actual human being, past or -present.
A person represents an actual human being, past or +present.
A user is a person who has registered with an OpenACS site. A -user may have additional attributes, such as a screen name.
The data model should enforce these constraints:
40.10 A user must have a non-empty email address.
40.20 Two different users may not have the same email +
A user is a person who has registered with an OpenACS site. A +user may have additional attributes, such as a screen name.
The data model should enforce these constraints:
40.10 A user must have a non-empty email address.
40.20 Two different users may not have the same email address on a single OpenACS installation; i.e., an email address identifies a -single user on the system.
40.30 A user may have multiple email addresses; for -example, two or more email addresses may identify a single user.
40.40 A user must have password field which can be +single user on the system.
40.30 A user may have multiple email addresses; for +example, two or more email addresses may identify a single user.
40.40 A user must have password field which can be empty.
The data model for the parties and groups system must provide support for -the following types of relationships between entities:
-A party P is considered a member of a -group G
when a direct membership relationship exists between P -and G
or when there exists a direct membership relationship between -P and some group GC and -GC has a composition relationship (c.f., 60.0) with G.
50.10 A party may be a member of multiple groups.
50.20 A party may be a member of the same group multiple +A party P is considered a member of a +group G
when a direct membership relationship exists between P +and G
or when there exists a direct membership relationship between +P and some group GC and +GC has a composition relationship (c.f., 60.0) with G.
50.10 A party may be a member of multiple groups.
50.20 A party may be a member of the same group multiple times only when all the memberships have different types; for example, Jane may be a member of The Company by being both an Employee and an -Executive.
50.30 A party as a member of itself is not supported.
50.40 The data model must support membership -constraints.
50.50The data model should support the subclassing of +Executive.
50.30 A party as a member of itself is not supported.
50.40 The data model must support membership +constraints.
50.50The data model should support the subclassing of membership via OpenACS Relationships.
A group GC is considered a -component of a second group -GP
when a direct composition relationship exists between -GC and GP
or when there exists a direct composition relationship between -GC and some group Gi -and Gi has a composition relationship with -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:
A group GC is considered a +component of a second group +GP
when a direct composition relationship exists between +GC and GP
or when there exists a direct composition relationship between +GC and some group Gi +and Gi has a composition relationship with +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 parties and groups system provides a well defined API call that creates a new group by running the appropriate transactions on the parties and groups system data model. This API is subject to the constraints laid out -in the data model.
The parties and groups system provides a well defined API call that creates a new person by running the appropriate transactions on the parties and groups system data model. This API is subject to the constraints laid out -in the data model.
The parties and groups system provides a well defined API call that creates a new user by running the appropriate transactions on the parties and groups system data model. This API is subject to the constraints laid out in -the data model.
The parties and groups system provides a well defined API call that creates a new user by running the appropriate transactions on an existing person entity. This API is subject to the constraints laid out in the data -model.
The parties and groups system provides a well defined API call that demotes an existing user entity to a person entity by running the appropriate transactions on the existing user. This API is subject to the constraints -laid out in the data model.
The programmer should be able to modify, add, and delete attributes on any -party. This API is subject to the constraints laid out in the data model.
The programmer should be able to view the attributes on any party. This -API is subject to the constraints laid out in the data model.
The system provides an API for deleting a party. This API is subject to -the constraints laid out in the data model.
100.30 The system may provide a single API call to remove -the party from all groups and then delete the party.
100.40 In the case of a group, the system may provide a +the constraints laid out in the data model.
100.30 The system may provide a single API call to remove +the party from all groups and then delete the party.
100.40 In the case of a group, the system may provide a single API call to remove all parties from a group and then delete the -group.
The parties and groups system provides an API for adding a party as a member of a group. This API is subject to the constraints laid out in the -data model.
The parties and groups system provides an API for adding a group as a 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 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 composition in 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 answering the question: -"Is party P a member of group -G?"
The parties and groups system provides an API for answering the question: -"Is group GC a component of group -GP?"
The parties and groups system provides an API for answering the question: -"Which parties are members of group G?"
The parties and groups system provides an API for answering the question: -"Which groups are components of group G?"
The parties and groups system provides an API for answering the question: -"Of which groups is party P a member?"
The parties and groups system provides an API for answering the question: -"Of which groups is group G a component?"
The parties and groups system provides an API for answering the question: -"Is party P allowed to become a member of group -G?"
The parties and groups system provides an API for answering the question: -"Is group GC allowed to become a component -of group GP?"
Since many pages at a site may check membership in a group before serving a page (e.g., as part of a general permissions check), the data model must support the efficient storage and retrieval of party attributes and -membership.
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 |
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 |