IBM Rational ClearQuest and IBM Rational ClearCase V1.0 IBM Rational Software
1. INTRODUCTION 2 2. ENVIRONMENTS ASSUMPTIONS 2 3. ESTABLISHING A UCM ENABLED CCRC ENVIRONMENT 2 3.1 Hardware Configurations 3 3.2 Requirements to Install 3 3.3 Setting up the CCRC Server 3 3.3.1 Installing ClearCase RWP 3 3.3.2 Configuring CCWEB Config File 3 3.3.3 Installing ClearQuest on CCRC Server 4 3.3.4 Testing 5 3.3.5 Performance Monitoring 5 3.4 Setting up the CQ Web Server 5 3.4.1 ClearQuest Web Installation 5 3.4.2 ClearCase Client Installation 5 3.4.3 Setting up a View for Access 5 3.3.4 Testing 6 3.3.5 Performance Monitoring 6 4. OTHER CONSIDERATIONS 6 4.1 Replica Naming Considerations 6 4.2 IBM Compartmentalization Requirements and Server Access 7 4.3 Project Settings 7 5. TESTING THE ENTIRE ENVIRONMENT 8 5.1 Use Cases 8 5.2 Sub-Cases 9 APPENDIX 1 USE AND SUB-CASES 9 1
1. Introduction This document describes the ClearQuest and ClearCase operational needs to establish an Unified Change Management (UCM) enabled environment using the ClearCase Remote Client (CCRC). 2. Environments Assumptions This document assumes there is already an existing UCM environment (ClearCase and ClearQuest) that works without CCRC available. The ClearCase environment is expected to have the following configuration. Operational ClearCase (CC)environment with License, Registry and VOB server(s) Operational ClearQuest (CQ) environment with CQ Java Web Servers One or more UCM enabled Projects This document will not provide details describing these portions of the environment. 3. Establishing a UCM Enabled CCRC Environment At a very high level, the ClearQuest /ClearCase environment will look like: CCRC Server Machine Client Desktop CCRC Eclipse HTTP CCRC Server VOB s Server Browser HTTP App Server ClearQuest Java Web Server CQ DB s Server This document discusses the configuration of the CCRC Server and ClearQuest Java Web Server related to UCM Enablement. 2
3.1 Hardware Configurations The CCRC and CQ Server Hardware configurations will be site specific. The requirements for a low-use CCRC Server serving a few small VOBs can be quite different from the requirement for a high-use CCRC Server with many large VOBs. When choosing the hardware needed, please consider the usage needs. For a generic configuration, the following server specifications should be used as a guide. CCRC Server: Hardware: IBM xseries, 2u systems, 2 CPU, 8 GB RAM, running Microsoft Windows or Linux. Software: ClearCase 7.0.1 or greater, ClearQuest 7.0.1 or greater (Versions of ClearCase and ClearQuest must be compatible) CQ Server: Hardware: xseries, 2u systems, 2 CPU, 4 GB RAM or greater, running Windows 2000 or Windows Server 2003 R2 Software: ClearCase 7.0.1 or greater, ClearQuest 7.0.1 or greater (Versions of ClearCase and ClearQuest must be compatible) 3.2 Requirements to Install Before installing ClearCase, appropriately site-prepped ClearCase Installation Areas should be created to allow installation of ClearCase Client and ClearCase Client with the Rational Web Platform (RWP). ClearQuest installation areas must have the IBM Rational ClearQuest client only components selected. 3.3 Setting up the CCRC Server 3.3.1 Installing ClearCase RWP Install ClearCase. Make sure to choose CCWeb (RWP) & MVFS Components. Complete the Install for the site-specific needs. 3.3.2 Configuring CCWEB Config File (a) Go to <CLEARCASE_HOME>\config\ccweb and copy ccweb.config into <CLEARCASE_HOME>\var\Config directory and edit it in notepad. (b) Set the following parameters: -cqweb_url <url for CQ Web : See Step 2> 3
-cqweb_autologin true -cqweb_browser_timeout ( if left unset, default is 30 minutes) A sample might look like: -cqweb_browser_timeout 300 -cqweb_autologin true -cqweb_url https://<yourcqweb>.lexma.ibm.com/cqweb/login 3.3.3 Installing ClearQuest on CCRC Server Install ClearQuest. The core components are installed for use and reference with the CCRC server. The UNIX installation requires some configuration due to a couple defects: 1. Install a ClearQuest Profile this should be obtained from the ClearQuest Admin, typically in Tar format. Untar the replica profile info in: /opt/rational/clearquest/cqdb_rgys/cqdb_registry/<cqversion> 2. There is an issue with mail. To work around this, replace the CQ executable cqintsvr_main with a script. First, move the executable to another name: mv /opt/rational/clearquest/sun5/bin/cqintsvr_main /opt/rational/clearquest/sun5/bin/cqintsvr_main.real 3. Then, create a wrapper script to allow mail to be sent. The wrapper script should replace the executable (/opt/rational/clearquest/sun5/bin/cqintsvr_main) and look like: #!/bin/sh pwd > /tmp/env.$$ HOME=/opt/rational/clearquest export HOME env >> /tmp/env.$$ exec /opt/rational/clearquest/sun5/bin/cqintsvr_main.real "$@" Then, make the script execute. chmod 555 /opt/rational/clearquest/sun5/bin/cqintsvr_main 4. Create the SendMail file, /opt/rational/clearquest/.rational/.registry/clearquest/sendmail with contents: ReplyTo: <GenericAccount>@us.ibm.com SMTPHost: mailrelay.<fqdn> SendActive: 1 4
3.3.4 Testing Go to http://<server-name>/cqweb/login and verify that CQ Web is running. (The CQ Web Login Page should appear). 3.3.5 Performance Monitoring Appropriate Performance Monitoring parameters are still being considered and will be part of the ITM plans. Some metrics to consider including are: Base System parameters (CPU load, Free Memory, etc) Number of CCRC views active on system Various View monitoring characteristics 3.4 Setting up the CQ Web Server 3.4.1 ClearQuest Web Installation Install ClearQuest. Make sure to choose CQ Java Web and Administrative tools components. Complete the Install. For Code Page, choose Windows -Latin (1252). 3.4.2 ClearCase Client Installation Install ClearCase client software with MVFS. 3.4.3 Setting up a View for Access The CQ Web Server requires access to an active view to provide UCM information in CQ. The view can be created on the local system or elsewhere. However, a view needs to be started on the CQ Web Server to access this information. No VOBs need be mounted. For example, a default view can be created on one of the CQ Web Servers; the view can be started during initial startup on both CQ Web Servers. There is no need to identify this view to CQ. To assist with the automatic start of a view, it is suggested that a Scheduled Task be added to start it and make sure it is readily available. First create a.bat file on the local system with the following (editted) command: if NOT exist M:\<viewtag>. cleartool startview <viewtag> 5
Then, add a scheduled task (Start -> Control Panel -> Scheduled Tasks) to run the.bat file every 5 minutes. It is preferable to run from an account with a non-expiring password, otherwise the password will need to be updated everytime the account s password changes. 3.3.4 Testing Go to http://<server-name>/cqweb/login and verify that CQ Web is running. (The CQ Web Login Page should appear). TIP : If CQ-Web is not running, then go to Control Panel->Administrative Tools->Services->IBM WebSphere Application Server V6-RWP Servlet and start this service. Make sure this service is running. If not running properly, try rebooting the machine and starting the service again. 3.3.5 Performance Monitoring Two methods can be used for performance monitoring CQJW as follows: Method 1: Setup Perfmon to Log Memory Statistics Use the following counters for monitoring: Processor(_Total)\% Processor Time Network Interface(Broadcom NetXtreme Gigabit Ethernet)\Bytes Total/sec PhysicalDisk(0 C:)\% Disk Time PhysicalDisk(0 C:)\Avg. Disk Queue Length PhysicalDisk(1 D: F:)\% Disk Time PhysicalDisk(1 D: F:)\Avg. Disk Queue Length Process(_Total)\Private Bytes Process(_Total)\Working Set Method 2: Use Tivoli Monitoring to check performance. Base System parameters (CPU load, Free Memory, etc) 4. Other Considerations 4.1 Replica Naming Considerations The local project VOB replica name must match the local CQ Replica name. For example, both are named REPLICA1. 6
4.2 IBM Compartmentalization Requirements and Server Access Access to CCRC must be controlled based on need to access managed source code. Users will need to obtain appropriate access permissions to the needed CCRC Servers. 4.3 Project Settings Any new project which will be using CCRC in conjunction with ClearQuest and is UCM enabled should set the following policies on the Project: Check the Perform ClearQuest Action Before Work On Policy Checkout requires choice of a CR Assigned to the Developer. Optional: Perform ClearQuest Action Before Delivery" Determines if Delivery is Approved. Delivery allowed if ApprovedBy has a value Only supported if Product->AdminOwnersRequired= Yes Clearquest Forum polling. Optional: Perform ClearQuest Action Before Changing Activity" Determines if Finish Activity is Approved in a Single-stream UCM-enabled Project Finish allowed if ApprovedBy has a value Only supported if Product->AdminOwnersRequired= Yes Do not Check Perform ClearQuest Action After " Email notification is handled by ClearQuest Email Rules. Do not Check Perform ClearQuest Action After Changing Activity Email notification is handled by ClearQuest Email Rules. Check "Transition to Complete After Delivery" for some Projects Deliver operation If all Developers on a Project use ClearCase GUI (Windows or UNIX) for checkout If the Developer is the Integrator for all Remote Deliveries: This Policy will save the developer from having to do the extra step of connecting to ClearQuest and Manually Resolving the CR separately after doing a Delivery Complete At Deliver Complete, the Developer will be presented with an editable CR transitioned to the Resolved state, mastership set based on Owner's site and waiting for any changes to be made and for the ClearQuest OK button to be clicked. Check "Transition to Complete After Changing Activity" for some Projects Finish Activity If all Developers on a Project use ClearCase GUI (Windows or UNIX) for checkout 7
If the Developer is the Integrator for all Remote Deliveries: This Policy will save the developer from having to do the extra step of connecting to ClearQuest and Manually Resolving the CR separately after doing a Delivery Complete At Deliver Complete, the Developer will be presented with an editable CR transitioned to the Resolved state, mastership set based on Owner's site and waiting for any changes to be made and for the ClearQuest OK button to be clicked. Check "Transfer ClearQuest Mastership Before Delivery" for all Projects Support if doing a Command Line Interface (CLI) when doing just a Deliver No support for Command Line Interface (CLI) when doing a Deliver Complete Will remaster ClearQuest ChangeRequest to same site where Delivery is targeted Introduces new rule for Mastership When ChangeRequest has no Owner, ratl_mastership is set to mastership of Change Request Component When ChangeRequest has an Owner, ratl_mastership is set to mastership of Change Request Owner s UserID If this Policy is enabled, a ChangeRequest may be mastered at a site in which neither of the above is true while waiting for the corresponding Deliver Complete The Transfer ClearQuest Mastership After Delivery policy must not be checked The Developer must be the Integrator in order to be able to provide the ChangeRequest- >Status and ChangeRequest ->Resolution_Description When doing a Deliver Complete, the associated ChangeRequest is Resolved ChangeRequest->Owner will be automatically set and may be manually changed by the Developer. Owner will be set to a UserID that may be mastered at any ClearQuest replica. ChangeRequest mastership is set based on the mastership of the UserID The ChangeRequest may get remastered to another site 5. Testing the Entire Environment 5.1 Use Cases Several use cases are available which describe the expected behavior of CCRC usage with the CQWeb/UCM-CQ Integration. They can be used in conjunction with ClearQuest CCRC to validate the infrastructure setup. They are presented for reference in Appendix 1 and include: Use Case 1: Checkout, Checkin or Add to Source Use Case 2: Work On Use Case 3: Deliver Use Case 4: Finishing an Activity 8
Use Case 5: Viewing an Activity 5.2 Sub-Cases In addition, several sub-cases are available which can be used to further validate the ClearQuest CCRC Deployment infrastructure. They are presented for reference in Appendix 1 and include: Sub-Case 1: CQ Login Sub-Case 2: Auto-Transition Appendix 1 Use and Sub-Cases The following use cases and sub-cases are excerpted from the 7.x CCRC CQWeb-UCM-ClearQuest Integration Function Spec document authored by Hans Heilman of IBM Rational Software. AP1 Behavior by Use Cases In this section: Saying that a use case's context is CQWeb-configured means that: o The user s working context in the CCRC client is a CQ-enabled UCM Project/Stream/View. o The CCRC Server is CQWeb-configured (this implies it is also CQ-configured) o The CCRC client where the user is performing the use case is running on a platform which supports CQWeb-configured use cases Saying that a use case's context is CQ-configured-only means that: o The user s working context in the CCRC client is a CQ-enabled UCM Project/Stream/View o Either: or The CCRC Server is CQ-configured but not CQWeb-configured, The CCRC client where the user is performing the use case is running on a platform which does NOT support CQWeb-configured use cases Note: In all use cases below where CQWeb displays a ClearQuest form, if CQWeb is operating in Restricted Mode then the ClearQuest form will not be displayed -- instead an error message will be displayed. Reasons for this could be: The CQWeb site is configured as a Restricted Site, or The ClearQuest user who is logged in is identified in CQWeb as a Restricted User, or The CQ Server is unable to obtain a ClearQuest license UC1 Use Case 1: Checkout, Checkin or Add to Source [The details which are summarized in this section were present in 2003.06.xx -- the new 7.x behavior is captured in sub-cases which are referenced by this section] User's working context in CCRC Client: CQ-enabled view 9
Use Case context: This use case s behavior may depend on whether the use case is being performed in a CQ-configured-only or CQWeb-configured context. The flow will be as follows: User: Performs action which causes the Checkout, Checkin or Add to Source dialog box to appear System: Displays the dialog box modally: The Activity field displays the title of the view s current activity, if there is one. [Optional flow if the user attempts to create a new activity record] User: Clicks the New button System: Displays an error message that this is not supported when the user is working in CQ-enabled context (this is true for a use case context of both CQ-configured-only and CQWeb-configured) [Usability note: There are some arguments for either not displaying a button that is not legal, or displaying it as disabled, but this is what the 2003.06.xx implementation does, so we will stick with it for the moment] [Optional flow if the user wants to select a different activity] User: Clicks the Browse button System: o Performs the CQ Login sub-case (see Error! Reference source not found.) which may cause the CQ Login dialog to be displayed modally [If the user clicks the Cancel button on the CQ Login dialog] The system displays an error message 10
The system displays the Select Activity dialog box, but it is not operable [This is what the 2003.06.xx implementation does, so we will stick with it] [If the user clicks the OK button on the CQ Login dialog] After validation of the CQ credentials (as described in Error! Reference source not found.), the use case continues. o Runs the user's UCMCustomQuery1 query [Note: This is different behavior than is performed by the Browse button in the native UCM-ClearQuest integration]. That query's default definition is to display all UCM-enabled records which are: Assigned to the current user, and In a READY or ACTIVE state, and Either not associated with any Project or Stream or, are associated with the user's Project or Stream. o Displays the Select Activity dialog box modally which displays the results of the query (if the CQ Login dialog was displayed just prior, this will not happen until the CQ Login dialog is closed): User: Selects an activity record then clicks OK System: o Closes the Select Activity dialog box o Updates the Activity field in the Checkout, Checkin or Add to Source dialog box to reflect the activity record which the user selected User: Clicks Apply in the Checkout, Checkin or Add to Source dialog box System: o Performs the CQ Login sub-case (see Error! Reference source not found.) which may cause the CQ Login dialog to be displayed modally [If the user clicks the Cancel button on the CQ Login dialog] [TBD -- What happens in this case?] [If the user clicks the OK button on the CQ Login dialog] After validation of the CQ credentials (as described in Error! Reference source not found.), the use case continues. o Closes the Checkout/Checkin/Add to Source dialog box then displays a progress window to the user: 11
(As is standard Eclipse behavior, if the user has selected Run in Background as an Eclipse Preference, Eclipse will only display a progress indication in the status bar) o If the ClearQuest activity record is not already in an ACTIVE state, performs the Auto-Transition sub-case (see Error! Reference source not found.). The target state will be ACTIVE and the parent window will be the progress window. The sub-case s behavior may depend on whether it is being performed in CQ-configured-only or CQWeb-configured context. [If the auto-transition process completed successfully] Performs the checkout/checkin/add-to-source operation. Creates a UCM activity and binds it to the ClearQuest activity record (if this has not happened previously) As the UCM activity is set current in the view, that will be mirrored in the ClearQuest activity record Closes the progress window [If the auto-transition process did NOT complete successfully (this can happen for several reasons, see Error! Reference source not found.)] UC2 Use Case 2: Work On An error message box replaces the progress window (to attempt the use case again, the user will have to perform the initial action which caused the Checkout, Checkin or Add to Source dialog box to appear). [The details which are summarized in this section were present in 2003.06.xx -- the new 7.x behavior is captured in sub-cases which are referenced by this section] User's working context in CCRC Client: CQ-enabled view Use Case context: This use case s behavior may depend on whether the use case is being performed in a CQ-configured-only or CQWeb-configured context. The flow will be as follows: User: o Performs action which causes the list of MyActivities to be displayed in the ClearCase Details view. This list is generated by running the user's UCMCustomQuery1 query. o Selects an activity and invokes Work On from the context menu System: o Performs the CQ Login sub-case (see Error! Reference source not found.) which may cause the CQ Login dialog to be displayed modally. If the user clicks the Cancel button on the CQ Login dialog, [TBD what happens?] o For the selected activity, if the ClearQuest activity record is not already in an ACTIVE state, performs the Auto-Transition sub-case (see Error! Reference source not found.). The target state will be ACTIVE and the parent window will be the ClearCase Details Eclipse view, showing the activities. [If the auto-transition process completed successfully] 12
Creates a UCM activity and binds it to the ClearQuest activity record (if this has not happened previously) As the UCM activity is set current in the view, that will be mirrored in the ClearQuest activity record. Updates the displayed activity list to reflect that. [If the auto-transition process did NOT complete successfully (this can happen for several reasons, see Error! Reference source not found.)] An error message box will be displayed UC3 Use Case 3: Deliver [The details which are summarized in this section were present in 2003.06.xx -- the new 7.x behavior is captured in sub-cases which are referenced by this section (except for the CQWeb form opens in a browser window... reference)] User's working context in CCRC Client: CQ-enabled stream Configuration dependency: This use case s behavior may depend on whether the use case is being performed in a CQ-configured-only or CQWeb-configured context. The flow will be as follows: User: Performs action which indicates that they want to perform a deliver. System: Displays the Deliver from Stream dialog box: User: Clicks OK 13
System: o Closes the Deliver from Stream dialog box then displays a progress window to the user. o Opens a Delivering To Eclipse view in which it shows the files being checked out and merged. o When the files have been checked out and merged, the system closes the progress window and opens a message box reminding the user to Complete the deliver operation. The Eclipse view will show the files as having been merged but they are still checked-out: User: o Validates the merging o Clicks Complete the Deliver System: o Displays a progress window to the user (as is standard Eclipse behavior, if the user has selected Run in Background as an Eclipse Preference, Eclipse will only display a progress indication in the status bar). o Checks in all of the checked out files, the progress is reflected in the Delivering To Eclipse view o [If the project's Transition to Complete after Delivery policy is NOT enabled]: Completes the deliver operation (the user is now free to begin a new deliver) and closes the progress window. The Delivering To Eclipse view will show all of the files as no longer checked out [If the project's Transition to Complete after Delivery policy is enabled]: Performs the CQ Login sub-case (see Error! Reference source not found.) which may cause the CQ Login dialog to be displayed modally. If the user clicks the Cancel button on the CQ Login dialog, the deliver operation will be left in an incomplete state (the user must resume, then complete this deliver operation before they can begin a new one). For every activity which was delivered, the system: o Performs the Auto-Transition sub-case (see Error! Reference source not found.). The target state will be COMPLETE and the parent window will be the Delivering To Eclipse view. The sub-case s behavior may depend on whether it is being performed in a CQconfigured-only or CQWeb-configured context. o If a CQWeb form opens in a browser window and the user clicks Cancel on the form in the browser (or if auto-transitioning the current activity record fails for any other reason): No further auto-transitioning for the remaining delivered activities will be performed The deliver operation will be left in an incomplete state (the user must resume, then complete this deliver operation before they can begin a new one) After the above processing has exited, the system: [If the auto-transition process completed successfully for all delivered activities] o Completes the deliver operation (the user is free to begin a new deliver) and closes the progress window. [If the auto-transition process did NOT complete successfully for all delivered activities] o Closes the progress window and displays an error message to the user o The deliver operation will be left in an incomplete state (the user must resume, then complete this deliver operation before they can begin a new one) UC4 Use Case 4: Finishing an Activity [The details which are summarized in this section were present in 2003.06.xx -- the new 7.x behavior is captured in sub-cases which are referenced by this section] 14
User's working context in CCRC Client: CQ-enabled UCM project which is single-stream (in a singlestream UCM project, all users work on activities in an integration view) or an integration stream. Configuration dependency: This use case s behavior may depend on whether the use case is being performed in a CQ-configured-only or CQWeb-configured context. The flow will be as follows: User: o Performs action which causes the list of MyActivities to be displayed in the ClearCase Details view. o Selects an activity and invokes Finish Activity from the context menu System: o [If the selected activity has checkouts]: The Checkin dialog will be displayed to give the user an opportunity to check in the checked out files. o [If the project's Transition To Complete After Changing Activity policy is enabled]: Performs the CQ Login sub-case (see Error! Reference source not found.) which may cause the CQ Login dialog to be displayed modally. If the user clicks the Cancel button on the CQ Login dialog, [TBD what happens?] For the activity record, performs the Auto-Transition sub-case (see Error! Reference source not found.). The target state will be COMPLETE and the parent window will be the ClearCase Details Eclipse view, showing the activities. User: If the auto-transition succeeded, when the user next refreshes their list of MyActivities, it will not display the activity which was finished. UC5 Use Case 5: Viewing an Activity [This section describes functionality which is new in 7.x] User's working context in CCRC Client: CQ-enabled stream Configuration dependency: This use case s behavior will depend on whether the use case is being performed in a CQ-configured-only or CQWeb-configured context. The flow will be as follows: User: o Selects an activity from the list of MyActivities invokes the Properties menu item. Note that these actually represent ClearQuest records which may or may not be bound to a UCM activity. System: The system displays the Activity Properties dialog box modally. In CQ-configured-only or CQWeb-configured context, the dialog box will have a ClearQuest tab which displays a View Record button. 15
16
User: Clicks the View Record button System: [In a CQ-configured-only context] o Displays an error message that this is only supported in a CQWeb-configured context. [In a CQWeb-configured context] o Performs the CQ Login sub-case (see 4.5) which may cause the CQ Login dialog to be displayed modally. If the user clicks the Cancel button on the CQ Login dialog, nothing further happens. o After the sub-case has completed, displays a modal window containing a browser which is displaying a ClearQuest record form in view mode: User: Interaction with the form in the browser follows normal CQWeb behavior. including utilization of pop-up windows, etc. Notes: o The user is free to click a button on the record toolbar which puts the form to edit mode, change fields in the form then click Save. o The user is free to view the activity's change set on the Unified Change Management tab of the ClearQuest form, although that does not make much sense because the same information is available on the Change Set tab of the Activity Properties dialog box. o In the native CQ/UCM integration, when a UCMUtilityActivity record representing a delivered integration activity is being viewed, a Contributors action is available to the user, allowing them to view the contributing activity records. This capability is not available in the CCRC/CQWeb-integration. User: Clicks the Close button on the modal window. Note: If the user clicks the Close button on the modal window while the form is in edit-mode, it will be treated the same as if they had clicked Cancel on the form in the browser. 17
System: Closes the modal window and control returns to the Activity Properties dialog box. Note: If the user changed the headline of the activity record in the ClearQuest form, the change will be mirrored back into the UCM activity's title but the Activity Properties dialog box will still show the old title. To see the new title, the user must close, then reopen the Activity Properties dialog box. SC1 Sub-Case 1: CQ Login At various points in the use cases above, when the user performs an action that causes the system to need credentials to access ClearQuest, it will perform the sub-case described here, which may result in the CCRC Eclipse client displaying a ClearQuest Login dialog to the user. SC1.1 Sub-Case Behavior [The functionality which is summarized in this section was present in 2003.06.xx] Use Case context: This sub-case s behavior will be the same regardless of whether the use case is being performed in a CQ-configured-only or CQWeb-configured context. The flow will be as follows: User: Performs initial action that causes the system to need credentials to access ClearQuest. System: [If the user has never been previously prompted with the ClearQuest Login dialog for this Schema Repository, OR the user has been previously prompted for this Schema Repository, but the CQ credentials which they supplied and which were then cached have expired (see 0)] o The system will display the CQ Login dialog modally (see section 0). o After the user supplies valid CQ credentials, the CQ Login dialog will be closed and the system will perform the requested action. [Otherwise (the user has been previously prompted with the CQ Login dialog for this Schema Repository AND the CQ credentials which they supplied then and which were cached have not expired)] o The system validates the cached credentials for the appropriate Schema Repository o If the cached credentials pass validation, the system will use them to perform the requested action o If the cached credentials fail validation: The system displays the CQ Login dialog modally again (see section 0). After the user supplies valid CQ credentials, the System closes the CQ Login dialog and performs the requested action. SC1.2 The ClearQuest Login Dialog [The functionality which is summarized in this section was present in 2003.06.xx] Note: System: Displays CQ Login dialog modally: 18
User: Supplies values in the Username and Password fields. The username that the user must supply will be, in ClearQuest terminology, the AuthenticationLoginName (not the UserLoginName). The correct format of the name (ClearQuest or LDAP) depends on how the Schema Repository's authentication is set up. User: Clicks OK or Cancel [If they click OK] o System: Validates the credentials supplied by the user If the credentials pass validation, the credentials will be cached (see section 0) and the CQ Login dialog will be closed. If the credentials fail validation, the system will redisplay the CQ Login dialog (back to the top of this section) [If they click Cancel] o System: Performs behavior which is specific to the use case within which this sub-case is executing. SC1.3 Caching CQ Credentials [This functionality was present in 2003.06.xx] CQ credentials are cached on the CCRC Server: o per-ccrc Eclipse session o and, for each CCRC Eclipse session, per-clearquest-database [This functionality is new in 7.x] The behavior regarding CQ credential expiration will change in 7.x (see Error! Reference source not found. for details). Also, an additional feature is being added, entirely for the purposes of making testing easier which allows the user to disable CQ credential caching for the duration of their CCRC session SC2 Sub-Case 2: Auto-Transition At various points in the use cases above, when the user performs an action, the system may attempt to auto-transition the activity record through a sequence of state transitions until it reaches a target state. This behavior is described in the sub-case here. SC2.1 Sub-Case Terminology 19
Target state: The final state to which the use case is attempting to auto-transition the record. In the different use cases, this may be a state whose state type is ACTIVE or COMPLETE. Parent window: The Eclipse dialog box or view in which the user performed the action which caused the system to perform the auto-transition sub-case. SC2.2 Sub-Case Behavior Use Case context: This sub-case s behavior may depend on whether the use case is being performed in a CQ-configured-only or CQWeb-configured context. System: Attempts to auto-transition the activity record through a sequence of state transitions until it reaches the target state. The system's behavior is different for the following cases: [If the user does not have mastership of the activity record] [This functionality was present in 2003.06.xx] o The auto-transition process will not be started. o It will display an error message to the user o The use case steps after the sub-case will NOT be performed -- the flow will return to the parent window which will still be displayed. [If the auto-transitioning process does NOT encounter missing fields] [This functionality was present in 2003.06.xx] o It will complete without interaction with the user and the use case steps after the sub-case will be performed. [If the auto-transitioning process encounters missing fields, and the use case is being performed in a CQ-configured-only context] [This functionality was present in 2003.06.xx] o The auto-transition process will be stopped and the activity record will be left in the state which had the fields with missing values. o It will display an error message to the user o The use case steps after the sub-case will NOT be performed -- the flow will return to the parent window which will still be displayed. [If the auto-transitioning process encounters a state with missing fields, and the use case is being performed in a CQWeb-configured context] [This functionality is new in 7.x] o For each state that the-auto-transitioning process encounters which has missing fields, the system will display a modal window containing a browser which is displaying a CQWeb record form in edit mode. See section 0 for details. 20
SC2.2.1 Opening a CQWeb Record Form During Auto-Transitioning [This section describes functionality which is new in 7.x] System: For each state that the-auto-transitioning process encounters which has missing fields: The system will display a modal window containing a browser which is displaying a CQWeb record form in edit mode. The record will be in the state with the missing field values and the fields will be highlighted. [TBD -- Describe SQUID behavior for auto-initializing the SQUID-related fields. This needs investigation] User: Specifies values for the relevant fields in the form. Their interaction with the form follows normal CQWeb behavior, including utilization of pop-up windows, etc. User: Clicks either Save or Cancel on the form in the browser: [If they click Save on the form in the browser] o System: If validation of the fields fails, follows normal CQWeb behavior to display the error messages in the browser along with a Return button that allows the user to return to the CQ form, correct their invalid fields, then try to Save again. If validation of the fields succeeds, displays a message in the browser that the save has succeeded. The browser window displays no user actions. o User: Clicks the Close button on the modal window (or the X button on its title bar) o System: Closes the modal window and the auto-transition process continues. 21
[If they click Cancel on the form in the browser] o System: Displays a message in the browser that the save was canceled. The browser window displays no user actions. o User: Clicks the Close button on the modal window (or the X button on its title bar) o System: Closes the modal window Displays an error message to the user. The auto-transition process will be stopped and the activity record will be left in the state which had the fields with missing values. The use case steps after the sub-case will NOT be performed -- the flow will return to the parent window which will still be displayed. Alternate flows: If the user clicks the Close button on the modal window without having clicked either Save or Cancel on the form in the browser, it will be treated the same as if they had clicked Cancel on the form in the browser. If there is a CCRC server browser timeout (see Error! Reference source not found.): o The auto-transition process will be stopped. o The use case steps after the sub-case will NOT be performed -- the flow will return to the parent window which will still be displayed. 22