Sharing work across a network of computers is one of the most important features of ClearDDTS. If you are using multiple ClearDDTS installations, there are certain steps you must take to manage remote access between the installations.
Before using ClearDDTS on a distributed network review the following chapters of the ClearDDTS Administrator's Guide to learn how electronic mail is used to communicate between ClearDDTS sites:
These two files are used to restrict project access between remote sites.
The export file defines the projects other systems can see and the
projects remote systems can log bugs against. The import file defines
the projects allowed to be installed on the local system. For a complete
explanation of file syntax and examples see Chapter 4, Managing
Remote Access Between Multiple Installations, in the ClearDDTS Administrator's
Guide.
IMPORTANT: Complete edits to these files before proceeding to Step
3 below.
Use the adminibug conn command to connect one site to another.
This command sets up communication between two machines so they can exchange
information about projects. For more information about the conn command
see Chapter 3, Maintaining the
Network, in the ClearDDTS Administrator's Guide.
Once the sites are connected, users on either system can enter defects
to projects on a remote system according to the rules established in the
import and export files. Defects submitted by the remote
system are transmitted to the system owning the project.
Establishing connections between sites with the adminbug conn command allows users on one ClearDDTS system to log defects in a project on a remote system. However, it does not allow users to see all the defects in that project. Remote sites can use project subscription to view all defects.
To subscribe to a project run the adminbug asub command from the machine that wants the subscription. This command replicates all of the defect information for a project from the owning machine onto the remote machine. This is useful when a user needs to see all defects in order to run composite defect metrics. For a complete description of the command see Chapter 5, Maintaining Classes and Projects, in the ClearDDTS Administrator's Guide.
By default, projects are owned by only one site, and the defects associated with a project can only be modified by a user on the owning site. Users at other connected sites can submit and view defects on a remote site, but they cannot modify or forward existing defects on that site. To allow users on remote machines to modify defects, use the adminbug aprj or mprj commands to specify that subscribing sites can modify defects in that project. Even with this feature enabled, users cannot forward defects belonging to projects on a remote site. For a description of the prompts involved see Chapter 5, Maintaining Classes and Projects, in the ClearDDTS Administrator's Guide.
CAUTION: There is no facility in ClearDDTS to lock records across the network or provide project level security. If more than one person submits modifications to a defect at the same time (or close to the same time) some of the changes will be lost. There is no way to prevent or detect such conflicts. Remote project modification should be used with extreme care.
All customizations to ClearDDTS are done at the class level. Each class has its own master.tmpl file plus other key files for customization. By design, classes are site specific and are not broadcast to the distributed ClearDDTS network. This allows different sites to customize classes to their specific defect cycle and unique requirements. If you want to keep identical classes on different sites, replicate the class modifications manually on each site.
[TOC] [Step 1: Planning] [Step 2: Installation] [Step 3: Customization] [Step 4: User Access] [Step 5: Distribution]