/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