/bboard system

part of the ArsDigita Community System by Philip Greenspun

User directory: /bboard/
Admin directory: message deletion, etc., is handling by admin-*.html scripts within the user directory; heavy duty stuff such as creating a new bboard or adding a maintainer is done at /admin/bboard/
data model : /doc/sql/bboard.sql

The discussion software supports the following kinds of user interfaces, all of which query and insert to the same bboard table. Currently the system supports:

Q&A format, developed for the photo.net site and one of the most refined interfaces
Editorial-commentary format, developed for cognet.mit.edu. This is suitable for when the publisher has longish thought-provoking editorials. Readers then submit commentary on this. A big advantage of this format is that the user interface isn't festooned with the words "question" and "answer".
US-geospatial format, developed for scorecard.org. This allows messages to be tagged with a zip code, county, or state. So you can look at discussion nation-wide, in a region, or limited to a zip code.
original threads interface. This is a lot like USENET and it doesn't scale very well as the discussion accumulates threads.

File upload

Users can upload one file in association with any message. This was developed to facilitate photo uploading. There is only one extra table defined for


create sequence bboard_upload_id_sequence;

create table bboard_uploaded_files (
	bboard_upload_id	integer primary key,
	msg_id			not null references bboard,
	file_type		varchar(100),	-- e.g., "photo"
	file_extension		varchar(50), 	-- e.g., "jpg"
	-- can be useful when deciding whether to present all of something
	n_bytes			integer,
	-- generally the filename will be "*msg_id*-*upload_id*.extension"
	-- where the extension was the originally provided (so 
	-- that ns_guesstype will work)
	filename_stub		varchar(200) not null,
	-- fields that only make sense if this is an image
	caption			varchar(4000),
	-- will be null if the photo was small to begin with
	thumbnail_stub		varchar(200),
	original_width		integer,
	original_height		integer
);

Permissions Model

[The bboard module was upgraded around time of version 2.1 to use the comon ACS user/groups administrative API]

Goal: To allow per-group bboards, and to use the new ACS permissions system to control user and administrative access to the bboards.

Each bboard topic is now associated with an administrative group, created using ad_administration_group_add, with "bboard" as the module and the topic_id as the sub-module. Any users who have been added to the corresponding administration group by ad_administration_group_user_add will have administrative access to the topic. They can access the bboard/admin-xxx pages, and moderate discussions on the topic.

Public and Private Bboards

There is a new read and write permissions model for topics. A topic has "read-access" and "write-access" permissions.

Read-access := any | public | group

 any    :=  topic may be viewed by any user of the system
 public :=  topic may only be view by a registered user of the system
 group  :=  topic may only be viewed by members of the topic's group(s)

Write-access :=  public | group

 public := any registered user may post a message or reply
 group  := only members of the topic's group(s) may post or reply to messages

Urgent requests

data model: an additional column urgent_p which says if the posting is urgent or not
parameters: UrgentMessageEnabledP=[0|1], DaysConsideredUrgent=number-of-days in the bboard section of the config file.

philg@mit.edu