User Groups
part of the
ArsDigita Community System
by
Philip Greenspun
and
Michael Yoon
The Big Idea
There are many applications of the ArsDigita Community System in which
we need to lump users together. If we accomplish that lumping with a
common mechanism, then we can build common user and admin tools that
don't have to be separately debugged for each installation.
Data Model Tour
These are the tables that hold user group information:
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
Creating User Groups
For each type of user group (i.e., row in the
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)
(If you find that you need to customize the
group-new
pages,
Yahoo! Clubs and
eGroups provide good examples of
simple user interfaces for user group creation.)
System-defined Groups
There are a bunch of places within the ArsDigita Community System where
users need to be lumped together. Sadly, some of these subsystems
predate the users group module and use their own mapping tables.
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."
Example Applications
Cisco sets up an ArsDigita Community System to support customers who've
purchased routers. Cisco would create a user group type of "company"
and then a user group of that type for each customer, e.g., "Hewlett
Packard" would be a user group and all the hp.com users would be members
of that group. The grouping mechanism would let Cisco ask for "all
trouble tickets opened by HP employees". The grouping mechanism would
let Cisco offer online prices with the HP discount to anyone logged in
who was recorded as a member of the HP group.
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.
Group login
More Information
philg@mit.edu
