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 typeuser_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 approveduser_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 requestopen: 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.