/bboard system
part of the ArsDigita Community System by Philip Greenspun
- User directory: /bboard/
- Unified bboard directory: /bboard/unified/
- Icons for unified bboard system: /bboard/unified/icons/
- Color swatches for unified bboard system: /bboard/unified/colors/
- Admin directory: message deletion, etc., is handling by admin-* 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
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).