ArsDigita Archives

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 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