user_group_types
: one row for each different
type of user group, e.g., at a university you'd have a row for
the "committee" group type and a row for the "course" group type
user_group_type_fields
: one row for each field that we must
keep for a user group type, e.g., for a university "course" group type
there would probably be rows in this table for
semester
, meeting_times
,
room_number
, final_exam_p
user_groups
: one row for each user group in a
community. At a university with 1000 courses per semester, 1000 rows
would be added to this table every semester. Note that these rows don't
store too much info about the groups, beyond their names (e.g., "CS 101,
Introduction to computer languages not used in industry"), whether the
group has been approved by the site administrator, and whether new
members must be approved.
*_info
: one table for each user group type in a
community, each table named "${group_type}_info" (e.g., "course_info" or
"committee_info"). Each table will contain one row for each user group
of that type. So the course_info
table would pick up 1000
new rows each semester. This is where the real information about a
group, the columns defined in user_group_type_fields
are
kept.
user_group_map
before ACS 3.2: one row for each user in a group.
For example, in a university with 1000 courses, 30 students per
course, 30,000 rows would be added to this table each semester. The
user_group_map
table also records a user's role in the
group.
ACS 3.2 and later: one row per each role played by a
user in a group. For example, in a small company where one person
plays both the CEO role and the CTO role, you would represent the
company as a user group of type "company", and there would be two rows
in user_group_map
for that person, one with a value of
"CEO" in the role
column and the other with a value of
"CTO".
user_group_map_queue
: one row for each user who has
applied for membership in a group but whose membership has yet to be
approved
user_group_types
table), you must choose an approval
policy (stored, naturally, in the approval_policy
column) to govern how groups of that type may be created, which must
be one of:
closed
: Only site-wide
administrators can create subcommunities (by using the admin pages in
/admin/ug/
)
wait
: Allow any user to request the
creation of a subcommunity (by using the group-new
pages
in /groups/
), requiring admin approval before fulfilling
the request
open
: Allow any user to create a
subcommunity without administrator intervention (also by using the
group-new
pages)
group-new
pages, Yahoo! Clubs and eGroups provide good examples of
simple user interfaces for user group creation.)
An example of something done consistently, however, is the recording
of whether or not a user is a system administrator of this site
(tested with the Tcl procedure ad_administrator_p
).
There is a user group type of "administration". One group of this
type is pre-defined: "Site-Wide Administration."
A university running one big ACS would have user group types of "committee" and "course". All the administrators on a committee would be in a user group of type "committeee". All the students and teachers in a particular course would be lumped together in a user group and could have a private discussion group. The teachers would have a different role within the user group and hence would have more access privileges.