ArsDigita Archives
 
 
   
 
spacer

/bboard system

part of the ArsDigita Community System by Philip Greenspun
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

All permissioning is done at the topic level. A message inherits its private/public status from the topic of which it is part. 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.

Future Versions

  • kill off the /bboard/unified/colors directory and come up with a system that lets people choose simply with HTML standard color palette (keywords from the server; let the browser render the colors).
philg@mit.edu
spacer