discussion-services
Articles and docs

New Discussion Services

CollabNet is raising the bar with a new set of discussion services that are designed to merge our current tools while enabling new collaboration idioms to be offered in the future. These services are tightly integrated with our role-based project permissions security for improved access controls and built on a Java J2EE platform for improved performance and reliability. The CEE 5.0 release integrates mailing list and discussion forum features, allowing project owners to select features of either tool for each discussion application and the flexibility to change them as needs change during the life of their project.

The illustration below introduces the new discussion permissions model and the documents that follow provide details on the implementation and how we plan to migrate our existing customer's archives into the new service.

 

LEGEND   View The user has permission to view and to subscribe to project discussions   Post The user has permission to post messages and replies to project discussions   Private The user has permission to view and to post to private project discussions   Trusted The user has permission to post without moderation to trusted project discussions

 

Guest Access

Access by clients who have not registered as users on the domain is also governed by the project permissions system. In this situation, guest access rights are determined by the domain's guest access policy and by the permissions that system administrators have assigned to the domain's guest user. The guest access policy determines whether or not guest users are allowed to use public portions of the site without logging in. This includes public discussions residing in public projects within the domain. Generally, the guest user is given the domain's Anonymous Guest role and if it contains the View and Post permissions shown above then guest users will be able to access public discussions in public projects as would any other user. In addition to these site-wide permissions, discussion administrators can enable or disable guest posting and subscription for each discussion independently.

Pre-Migration Recommendations (about a week before migration)

A big change in the CEE 5.0 release involves migrating all mailing lists and discussion forums into the new discussion services component. While discussion forum subscribers are already represented by their CEE user identities, the same is not true for mailing lists. In current mailing lists, subscribers, allowed posters and moderators are known only by the email address which they used to register with the list. Migrating mailing lists into discussion services requires mapping between subscriber email addresses and CEE user identities.

During mailing list migration, we attempt to map each email address onto a registered user identity. If this is not possible, the resulting subscription is recorded as a guest subscription. Guest subscribers do not have a start page summary of recent discussion activity and may have other limitations that are imposed by site administrators. Thus it behooves project owners to encourage their subscribers to register using the same email address that they use for their subscriptions.

This is especially important for moderators to moderated and discuss mailing lists. The new discussion services require that all moderators be registered users, thus moderator email addresses that cannot be mapped to a registered user will be dropped from the moderators list of each discussion during migration. This may create a situation where a moderated discussion has no moderators after migration. Project owners should review the moderators of each of their mailing lists prior to migration and ask their moderators to be sure to register using the same email address.

Finally, the mailing list tool granted some access rights based upon the existence of a user's subscription. In the discussion services, all access rights are governed by the CEE role-based permission system (above). If subscription email addresses can be mapped to a registered user identity then users will generally experience no impact after migration. Subscribers with email addresses that could not be mapped may experience some reduced access. Users should be advised to watch for such situations and to report them to their project owners quickly so that their disruption will be minimized.

Post Migration Recommendations (after staging and final migration)

Due to the inherent imprecision in mapping subscriber email addresses to CEE user identities, it is highly advisable for project owners to review their discussion subscriber lists after migration. Often, guest subscriptions will remain when registered users have been physically deleted from the system but had dangling subscriptions in the mailing list tool. These need to be removed using the discussion administration screen. Similarly, subscribers who used email addresses that were different than their registered user email addresses will have guest subscriptions.

It is also important for project owners to review the moderators lists of each of their moderated or trusted discussions. This is to ensure that all moderators were correctly migrated and that adequate moderators are subscribed for optimum discussion operation.

Discuss type mailing lists are migrated to become trusted discussions. All subscribers to discuss mailing lists thus receive the trusted permission flag on their subscriptions. All allowed posters to discuss mailing lists also receive a trusted subscription, but with start-page-only notification mode. Project owners should review their trusted discussions after migration to be sure that only appropriate users are able to post without moderation to these discussions.

Public discussions residing in private projects may not initially allow any guest posting even if this is enabled for the discussion. This is due to the default configuration of the Anonymous Guest role, which does not propagate into private projects. To enable guest posting to these discussions it is necessary to create a new domain role with the Post permission and allow it to be propagated into private projects.

Users may find that some automated systems that were previously able to post to mailing lists by virtue of their subscriptions are no longer able to post to discussions after migration. This is caused by the fact that these external mail sources are treated as guests under the project permissions system discussed above. Careful adjustment of the guest permissions at the domain or project levels can rectify most of these situations for public discussions. Because private discussions by definition cannot support guest posting, other remedies need to be applied. It is possible to add new virtual users to the domain so that these systems can be given more specific permissions individually. If such virtual users are granted appropriate project roles then they will be able to post to public or private discussions. It is also possible to add their sender email addresses as secondary email addresses to existing registered users.

Finally, all mailing lists are migrated to discussions with guest posting and anonymous subscription enabled. Migrated discussions also have no message size limit or attachment restrictions. Project owners should review these settings for appropriateness after migration. Many times, discuss type mailing lists were used in an effort to control spam. With the new discussion services, it is possible to make an unmoderated discussion reject spam by disabling guest posting. Project owners may wish to convert some trusted discussions to unmoderated without guest posting enabled.

Notes & Errata

We've discovered a corner-case in the migration of mailing list subscriptions that deserves special consideration. The migration itself makes the tacit assumption that all subscriptions will have appropriate permissions after the migration has completed. Depending upon how mailing list and discussion forum permissions have been set up before migration, this may not always be entirely true. After migration, there may be some subscriptions for discussions where the subscriber does not actually have View permission (and Private permission for private discussions). This is most likely in private projects, where the roles granting viewing permission have been configured not to propagate into them. It may also happen for guest subscriptions, if the guest role does not have View permission or if individual discussions do not have Anonymous Subscriptions enabled. Users whose subscriptions are removed by this process will receive an informative email notification that their permissions were insufficient to maintain their subscription. These notifications will also be posted to the admin@domain discussion so that administrators will have a record.

There are two administrative operations which cause a site-wide validation of existing subscriptions, ensuring that the respective subscribers have required permissions. This validation will cause illegal subscriptions that were grandfathered by the migration process to be removed and the subscribers notified. The administrative operations are: 1) deleting an existing Role and 2) deleting a permission from an existing Role.

We have developed a reporting script to identify and log subscriptions that do not have appropriate permissions after migration. We will run this script during staging and work with domain administrators so that they can take corrective action before users are affected. We recommend that domain administrators do not perform the above administrative actions without seeing this report first. Adding new Roles and adding permissions to Roles are not problematic in this respect.

Important documents

Incremental Consensus	An article describing a conversational-dynamics pattern that can be useful to help a discussion move from brainstorming to consensus and decision	2006-05-31	Jack Repenning
Discussion Services Overview	A slide presentation motivating and introducing our new Discussion Services	2006-10-05	Jeff Eastman
Discussion Services ERS*	The External Reference Specification defines the Discussion Services product from a user's perspective	2007-6-07	Jeff Eastman
Discussion Services Feature Comparison*	A tabular summary of features in current mailing list and discussion forums and how they are mapped to the new Discussion Services	2006-10-05	Jeff Eastman
Mailing List Migration Assumptions*	A summary about how current mailing lists will be migrated to new Discussion Services	2007-6-07	Jeff Eastman

* (members only)