The ACS 4.0 permissions system is about hierarchies and in particular hiearchical containment. There are three important hiearchies: the user hierarchy (users, groups, and parties) the object hierarchy (objects nested in the contexts of others) the privilege hiearchy (privileges can entail other entails). This complexity of mechanism is designed to allow for simplicity of use for programmers and administrators. Unfortunately, interfaces to facilitate this simplicity of use are not here yet. Until then, sophisticated control and configuration of BBoard necessitates an understanding of these details. The first hierarchy is straightforward. There are users and groups (or together parties). Privileges granted to groups inherit to their members. Unless explicitly disabled (see below), privileges granted to parties are inherited down an object hierarchy. The nature of the BBoard hierarchy is as follows: subsites contain bboard package instances; bboard package instances contain forums; forums contain both categories and messages. Privileges granted to parties on the package instance are inherited to all the forums nested within and so on. The third hiearchy is the least clear. Privileges can be nested into other privileges. This lets us group related privileges like those for reading a message and reading a forum together to allow us to easily grant "read access" on a hiearchy of objects to a party even though there are separate notions of "read a message" and "read a forum". All the bboard privileges are nested in one of the following system level "super"-privileges: "read", "write", "create", "delete", and "admin". The full set of self explanatory bboard privileges is listed here: bboard_create_forum bboard_create_category bboard_create_message bboard_write_forum bboard_write_category bboard_write_message bboard_read_forum bboard_read_category bboard_read_message bboard_delete_forum bboard_delete_category bboard_delete_message bboard_moderate_forum Permissions on package instances are controlled through the "set permissions" options on the appropriate folder in the admin site map (/admin/site-map/). While in principal, the system should allow you to grant permissions on lower level objects like forums or even individual messages and categories, right now the UI is limited to granting permissions on the application instance. SQL*Plus users or even URL hackers can probably figure out how to do this if they're so inclined. The default set of permissions granted in a bboard system are those inherited from the main site: Registered Users have bboard_create_message The Public has bboard_read_category The Public has bboard_read_forum The Public has bboard_read_message The Public has read [Admin user] admin Granting additional privileges to parties is fairly straightforward. For moderated forums, creating a moderators group and granting them "bboard_moderate_forum" (or "admin" if you're feeling lucky) will let you delegate more of the discussion culling. For significantly different configurations you might need to revoke privileges already granted by the defaults. In this case you must configure the package instance not to inherit permissions from the main site and then add back any permissions needed. Granting "read" to registered users and bboard_create_message to "Elite d00ds" will give you a pseudo-private forum. Note: To facilitate usability in the common case, BBoard pages present the option to post or reply even if the user doesn't have the bboard_create_message privilege. If you remove posting ability from registered users, you may wish to alter the templates to appropriately display options.