This appendix contains the code listings for the RTS PDL files with the on-line help text embedded. These files are also available in /usr/Tracker/RTS. The files are:
Tracker.pdl (the main file for rtsquery)
rtsapprove.pdl
rtsrespond.pdl
rtssubmit.pdl
/////////////////////////////////////////////////////////////////////
//
// File: Tracker.pdl
// Description: RTS default pdl
// This is the master pdl file that defines the fields
// and transitions for the RTS. Each RTS app includes
// another pdl file that defines its views.
// Author: Pete Orelup
// Created: Fri Apr 10 09:29:49 PDT 1992
// Language: Text
//
// (C) Copyright 1992, Silicon Graphics, Inc.
//
// Permission to use, copy, modify, and distribute this software for
// any purpose except publication and without fee is hereby granted,
// provided that the above copyright notice appear in all copies of
// the software.
////////////////////////////////////////////////////////////////////
// This define should be changed to the login name or mail alias of
// the Tracker facilitator.
#define CZAR 'root'
// This define should be changed to contain the login name or mail
// alias for the person (or persons) responsible for assigning owner
// to reports entered without an owner or project field.
#define BBOARD 'root'
////////////////////////////////////////////////////////////////////
// Top-level Help
////////////////////////////////////////////////////////////////////
help {
help-title 'Request Tracking System Overview';
short-help-title 'RTS Overview';
help-text'
The Request Tracking System (RTS) provides four applications for
accessing requests (bugs or RFEs) in request database:
* rtsquery - the main application, it provides full functionality
* rtssubmit - a specialized application for submitting new
requests
* rtsrespond - a specialized application for responding to
requests you have received
* rtsapprove - a specialized application for approving requests
after resolution or rejection by the owner
Note that all applications permit you to browse requests in the
database. Only rtsquery provides all the details; the others supply
subsets of the request data.'; }
////////////////////////////////////////////////////////////////////
// Field Declarations
////////////////////////////////////////////////////////////////////
fields {
help {
help-title 'Field Entry';
short-help-title 'Field Entry';
help-text'
All fields in RTS display a menu if the right mouse button is held
down while the cursor is in the field. If there are predefined values
for the field, a selection called "Values" displays that accesses a
cascading menu with the value selections. For more help, look up the
specific field.
When you select a transition from the Modes menu, all required fields
are highlighted. If you enter an invalid value for a field, the field
becomes highlighted when you leave it.
When conducting queries, you can enter an exact value or an expression
using one of these operators:
= <> < <= > >= equality and inequality operators
match regular expression match
contains [any | only] specific list value; choice of values;
multiple
specific values
= null | <> null test whether value is set (exists) or
not
[ val1, val2, ... valN ] test whether value is equal to one of
a list of values
[ startrange:endrange, ...] range of values';
};
////////////////////////////////////////////////////////////////////
// Report Number Field
////////////////////////////////////////////////////////////////////
report_number: int // Equal to $ENTITY_ID by
// default
help {
help-title 'Report # Field';
short-help-title 'Report # Field';
help-text'
The Report # field displays the ID assigned to the request. You
cannot change this value.
When you are in query mode, the field becomes editable and you can
enter a specific value, a range of values, or an expression.
See also RTS Fields help.';
};
////////////////////////////////////////////////////////////////////
// Submitter Field
////////////////////////////////////////////////////////////////////
submitter: short-text // person
help {
help-title 'Submitter Field';
short-help-title 'Submitter Field';
help-text'
The Submitter field displays the person who created the request. Any
text string is valid.
When you are in query mode, you can enter a specific value, a range of
values, or an expression.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Date Field
////////////////////////////////////////////////////////////////////
submit_date: date
help {
help-title 'Date Field';
short-help-title 'Date Field';
help-text'
The Date field contains the date on which the request is submitted.
When you submit a request, the current date is entered automatically.
When entering dates, you can use such forms as: mm/dd/yy; month day,
year; day-month-year; day month; time. You can also enter the
variables "today" and "now". You can use additive expressions such as
(today + days) and (month day - hh:mm:ss).
When performing queries involving dates, you can enter: a range, such
as [date:date]; an operator such as < (before) or > (after); the
variables "this year" and "this month"; or any of the previously
mentioned expressions. For a complete list of date options, see the
man page for cftime.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Recommendation Field
////////////////////////////////////////////////////////////////////
recommendation: one-of
DEFERRAL, REJECTION, RESOLUTION, DUPLICATION
help {
help-title 'Recommendation Field';
short-help-title 'Recommendation Field';
help-text'
The Recommendation field indicates the recommended disposition of the
request as of the most recent transition: DEFER (DEFERRAL), REJECT
(REJECTION), RESOLVE (RESOLUTION), and DUPLICATE (DUPLICATION). These
recommendations are entered automatically by the transition.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Type Field
////////////////////////////////////////////////////////////////////
type: one-of
BUG, RFE
help {
help-title 'Type Field';
short-help-title 'Type Field';
help-text'
The Type field indicates the type of request: BUG for bug report and
RFE for request for enhancement. Your tracking system administrator
may have implemented additional types. To check for these, hold down
the right mouse button while the cursor is in the type field and
select "Values" to display all allowable types.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Priority Field
////////////////////////////////////////////////////////////////////
priority: one-of
LOW, MEDIUM, HIGH
help {
help-title 'Priority Field';
short-help-title 'Priority Field';
help-text'
The Priority field indicates the designated priority for this request.
The standard values are LOW, MEDIUM, and HIGH. Your tracking system
administrator may have implemented different priorities. To check for
these, hold down the right mouse button while the cursor is in the
priority field and select "Values" to display all allowable
priorities.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Owner Field
////////////////////////////////////////////////////////////////////
owner: short-text // person
help {
help-title 'Owner Field';
short-help-title 'Owner Field';
help-text
'The Owner field displays the person responsible for implementing this
request. Any text string is valid.
When you are in query mode, you can enter a specific value, a range of
values, or an expression.
See also Field Entry help card.';
};
// Project Field
////////////////////////////////////////////////////////////////////
project: one-of
#include "projects.h" // This include file contains the list of
// projects.
// Edit it to change the list of known
// projects.
help {
help-title 'Project Field';
short-help-title 'Project Field';
help-text'
The Project field indicates the project to which the request is
assigned. The placeholder values: PROJECT_1, PROJECT_2, and PROJECT_3
are installed initially. Your tracking system administrator has
probably implemented different project names. To check for these, hold
down the right mouse button while the cursor is in the project field
and select "Values" to display all allowable projects.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// System Field
////////////////////////////////////////////////////////////////////
system: one-of
SYSTEM_1, SYSTEM_2, SYSTEM_3
help {
help-title 'System Field';
short-help-title 'System Field';
help-text
'The System field indicates the system to which the request is
assigned. The placeholder values: SYSTEM_1, SYSTEM_2, and SYSTEM_3 are
installed initially. Your tracking system administrator has probably
implemented different system names. To check for these, hold down the
right mouse button while the cursor is in the system field and select
"Values" to display all allowable systems.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Found in Field
////////////////////////////////////////////////////////////////////
found_in: list-of short-text // list-of product
help {
help-title 'Found in Field';
short-help-title 'Found in Field';
help-text'
The Found in field indicates the location(s) of the bug or
enhancement.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Summary Field
////////////////////////////////////////////////////////////////////
summary: short-text
help {
help-title 'Summary Field';
short-help-title 'Summary Field';
help-text'
The Summary field describes the request in a single line. When you
submit a request, this field defaults to the first line of the request
description, unless you have made an overriding entry. You can edit
this line at any time. The summary line information appears in the
query results area during queries.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Description Field
////////////////////////////////////////////////////////////////////
description: long-text
help {
help-title 'Description Field';
short-help-title 'Description Field';
help-text'
The Description field contains a complete explanation of the request.
You can enter as many lines as needed. If you have set either the
$WINEDITOR or $EDITOR environment variables, then the right-button
menu for the field will have an "Edit..." selection that lets you
enter the description in your default editor and import it into the
field.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Dup of Field
////////////////////////////////////////////////////////////////////
is_duplicate_of: int // pr-num
help {
help-title 'Dup of Field';
short-help-title 'Dup of Field';
help-text'
The Dup of field is only used when you are executing the DUPLICATE
transition. You use DUPLICATE when you feel that a new request is a
duplicate of a previous request. If so, you must enter the report
number of the previous request in the dup of field in order to mark
the new request as a duplicate.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Notify Field
////////////////////////////////////////////////////////////////////
interested_parties: list-of short-text // list-of person
help {
help-title 'Notify Field';
short-help-title 'Notify Field';
help-text'
The Notify field is used to add interested parties to the list of
people to be notified when changes occur to the request. Initially,
the list contains the submitter, owner, and tracking system
administrator.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Due Date Field
////////////////////////////////////////////////////////////////////
due_date: date
help {
help-title 'Due Date';
short-help-title 'Due Date';
help-text'
The Due Date field contains the date by which the request is intended
to be fixed. When you submit a request, the current date plus 30 days
is entered automatically. Your tracking system administrator may have
implemented a different default date.
When entering dates, you can use such forms as: mm/dd/yy; month day,
year; day-month-year; day month; time. You can also enter the
variables "today" and "now". You can use additive expressions such as
(today + days) and (month day - hh:mm:ss).
When performing queries involving dates, you can enter: a range, such
as [date:date]; an operator such as < (before) or > (after); the
variables "this year" and "this month"; or any of the previously
mentioned expressions. For a complete list of date options, see the
man page for cftime.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Close Date Field
////////////////////////////////////////////////////////////////////
close_date: date
help {
help-title 'Close Date';
short-help-title 'Close Date';
help-text'
The Close date field contains the date on which the request is closed.
When you approve a request, the current date is entered automatically.
When entering dates, you can use such forms as: mm/dd/yy; month day,
year; day-month-year; day month; time. You can also enter the
variables "today" and "now". You can use additive expressions such as
(today + days) and (month day - hh:mm:ss).
When performing queries involving dates, you can enter: a range, such
as [date:date]; an operator such as < (before) or > (after); the
variables "this year" and "this month"; or any of the previously
mentioned expressions. For a complete list of date options, see the
man page for cftime.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Reopen Field
////////////////////////////////////////////////////////////////////
reopen_date: date
help {
help-title 'Reopen Date';
short-help-title 'Reopen Date';
help-text'
The Reopen date field contains the date on which the deferred request
is to be reopened.
When entering dates, you can use such forms as: mm/dd/yy; month day,
year; day-month-year; day month; time. You can also enter the
variables "today" and "now". You can use additive expressions such as
(today + days) and (month day - hh:mm:ss).
When performing queries involving dates, you can enter: a range, such
as [date:date]; an operator such as < (before) or > (after); the
variables "this year" and "this month"; or any of the previously
mentioned expressions. For a complete list of date options, see the
man page for cftime.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Resolved In Field
////////////////////////////////////////////////////////////////////
resolved_in: list-of file // list-of file
help {
help-title 'Resolved In Field';
short-help-title 'Resolved In';
help-text'
The Resolved in field lets you enter files used to implement the
request. You can select the file access format through the
right-button menu. The text format lets you enter files as text
strings inside parenthese separated by spaces. The list format lets
you enter and delete files in a scrollable list.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Resolution Field
////////////////////////////////////////////////////////////////////
resolution_description: long-text
help {
help-title 'Resolution Field';
short-help-title 'Resolution';
help-text'
The Resolution field contains ane explanation of implementation of the
request. You can enter as many lines as needed. If you have set either
the $WINEDITOR or $EDITOR environment variables, then the right-button
menu for the field will have an "Edit..." selection that lets you
enter the resolution explanation in your default editor and import it
into the field.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Fixed In Field
////////////////////////////////////////////////////////////////////
fixed_releases: list-of short-text // list-of
// product
help {
help-title 'Fixed In Field';
short-help-title 'Fixed In';
help-text'
The Fixed in field lets you identify the product release in which the
request is implemented
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Approver Field
////////////////////////////////////////////////////////////////////
approver: short-text // person
help {
help-title 'Approver Field';
short-help-title 'Approver';
help-text'
The Approver field identifies the person with approval authority over
this request.
See also Field Entry help card.';
};
////////////////////////////////////////////////////////////////////
// Non-displayable Fields
////////////////////////////////////////////////////////////////////
// These fields are not visible to the users
czar: short-text; // person
bboard: short-text; // person
notify_list: list-of short-text; // list-of
// person
tempShortText: short-text;
}
////////////////////////////////////////////////////////////////////
// Transition Section
////////////////////////////////////////////////////////////////////
transitions {
help {
help-title 'Transition Overview';
short-help-title 'Transitions';
help-text'
To perform operations in the RTS applications, you choose the desired
editing mode from the Modes menu, edit the appropriate fields, and
click the <apply command> button (the third from the left in the
control area) to execute the operation or the Cancel button to void
it.
The RTS process begins with submitting a request, using either the
SUBMIT_BUG or SUBMIT_RFE transition, which puts the request in the
AWAITING_RESPONSE state. The next step is screening the request. Use
REJECT if the request is invalid, DEFER to postpone the fix, DUPLICATE
if an earlier request covers the suggestion, or RESOLVE to indicate
that the request has been executed.
At this point, the request is in the AWAITING_APPROVAL state. The
approver can issue a REDO if the request has not been satisfied, which
returns the request to the AWAITING_RESPONSE state. If the fix is
satisfactory, then the approver issues the APPROVE transition which
takes the request to the CLOSED state. When a DEFERRed request is
APPROVEd, it enters the CLOSED state, but will be REOPENed by the
owner later.
After a waiting period, the tracking system administrator removes the
request from the database using the DELETE transition.';
};
////////////////////////////////////////////////////////////////////
// SUBMIT_BUG Transition
////////////////////////////////////////////////////////////////////
SUBMIT_BUG(=>AWAITING_RESPONSE) {
help {
help-title 'SUBMIT_BUG Transition';
short-help-title 'SUBMIT_BUG';
help-text'
SUBMIT_BUG creates a new request of type BUG.
Prior state: non-existent New state: AWAITING_RESPONSE
Default fields:
1. The Date field is set to the current date.
2. The Type field is set to BUG.
3. The Submitter field is set to the current user.
4. The Summary field is set to the first line of the description.
Rule requirements:
1. The description field must have an entry.
Actions:
1. The owner is set to the entered value or if not entered to the
project manager if known or otherwise to the tracking system
administrator.';
};
rules {
description.isSet;
submit_date.is(submit_date.setDefault('now'));
type.is(type.setDefault(BUG));
submitter.is(submitter.setDefault($USER.value));
summary.is(summary.setDefault(description.value));
// Expect some action in one month
due_date.is(due_date.setDefault('now +30:00:00:00'));
}
actions {
bboard.setValue(BBOARD);
// If the owner is not set but a project was entered, then
// set the owner to the project manager. If no project
// was entered, then set owner to the bug board.
tempShortText.
setValue(execFilter(
'echo "select manager from project where name = \'$project\';"'));
owner.setValue(owner.isSet ?
owner.value :
(project.isSet ?
owner.setValue(execSelect(tempShortText.value)) :
owner.setValue(execFilter('/bin/echo $bboard'))));
tempShortText.setValue('');
}
}
////////////////////////////////////////////////////////////////////
// SUBMIT_RFE Transition
////////////////////////////////////////////////////////////////////
SUBMIT_RFE(=>AWAITING_RESPONSE) {
help {
help-title 'SUBMIT_RFE Transition';
short-help-title 'SUBMIT_RFE';
help-text'
SUBMIT_RFE creates a new request of type RFE.
Prior state: non-existent New state: AWAITING_RESPONSE
Default fields:
1. The Date field is set to the current date.
2. The Type field is set to RFE.
3. The Submitter field is set to the current user.
4. The Summary field is set to the first line of the description.
Rule requirements:
1. The description field must have an entry.
Actions:
1. The owner is set to the entered value or if not entered to the
project manager if known or otherwise to the tracking system
administrator.';
};
rules {
description.isSet;
submit_date.is(submit_date.setDefault('now'));
type.is(type.setDefault(RFE));
submitter.is(submitter.setDefault($USER.value));
summary.is(summary.setDefault(description.value));
// Expect some action in one month
due_date.is(due_date.setDefault('now +30:00:00:00'));
}
actions {
bboard.setValue(BBOARD);
// If the owner is not set but a project was entered, then
// set the owner to the project manager. If no project
// was entered, then set owner to the bug board.
tempShortText.
setValue(execFilter(
'echo "select manager from project where name = \'$project\';"'));
owner.setValue(owner.isSet ?
owner.value :
(project.isSet ?
owner.setValue(execSelect(tempShortText.value)) :
owner.setValue(execFilter('/bin/echo $bboard'))));
tempShortText.setValue('');
}
}
////////////////////////////////////////////////////////////////////
// ASSIGN Transition
////////////////////////////////////////////////////////////////////
ASSIGN(AWAITING_RESPONSE=>AWAITING_RESPONSE) {
help {
help-title 'ASSIGN Transition';
short-help-title 'ASSIGN';
help-text'
ASSIGN establishes the owner and a due date for the request.
Prior state: AWAITING_RESPONSE New state: AWAITING_RESPONSE
Default fields: none
Rule requirements:
1. There must be an entry in the Owner field.
2. There must be an entry in the Due Date field.
Actions: none';
};
rules {
owner.isSet;
due_date.isSet;
}
}
////////////////////////////////////////////////////////////////////
// FORWARD Transition
////////////////////////////////////////////////////////////////////
FORWARD(AWAITING_RESPONSE=>AWAITING_RESPONSE) {
help {
help-title 'FORWARD Transition';
short-help-title 'FORWARD';
help-text'
FORWARD establishes a change in ownership of the request.
Prior state: AWAITING_RESPONSE New state: AWAITING_RESPONSE
Default fields: none
Rule requirements:
1. The Owner field must be changed.
Actions: none';
};
rules {
owner.changed;
}
}
////////////////////////////////////////////////////////////////////
// RESOLVE Transition
////////////////////////////////////////////////////////////////////
RESOLVE(AWAITING_RESPONSE=>AWAITING_APPROVAL) {
help {
help-title 'RESOLVE Transition';
short-help-title 'RESOLVE';
help-text'
RESOLVE is issued by the request owner to indicate that the request
has been executed and is ready for approval.
Prior state: AWAITING_RESPONSE New state: AWAITING_APPROVAL
Default fields: none
Rule requirements:
1. There must be an entry in the Resolution field.
2. There must be one or more valid files entered in the Resolved in
field.
Actions:
1. The Recommendation field is set to RESOLUTION.';
};
rules {
resolution_description.isSet;
resolved_in.isSet;
}
actions {
recommendation.setValue(RESOLUTION);
}
}
////////////////////////////////////////////////////////////////////
// REJECT Transition
////////////////////////////////////////////////////////////////////
REJECT(AWAITING_RESPONSE=>AWAITING_APPROVAL) {
help {
help-title 'REJECT Transition';
short-help-title 'REJECT';
help-text'
REJECT is issued by the request owner to indicate that the request is
not considered and needs to be confirmed (through the APPROVE
transition) as such by the approver.
Prior state: AWAITING_RESPONSE New state: AWAITING_APPROVAL
Default fields: none
Rule requirements:
1. There must be an entry in the Resolution field.
Actions:
1. The Recommendation field is set to REJECTION.';
};
rules {
resolution_description.isSet;
}
actions {
recommendation.setValue(REJECTION);
}
}
////////////////////////////////////////////////////////////////////
// DEFER Transition
////////////////////////////////////////////////////////////////////
DEFER(AWAITING_RESPONSE=>AWAITING_APPROVAL) {
help {
help-title 'DEFER Transition';
short-help-title 'DEFER';
help-text'
DEFER is issued by the request owner to indicate that the request
should be postponed to the suggested date. This postponement needs to
be confirmed (through the APPROVE transition) by the approver.
Prior state: AWAITING_RESPONSE New state: AWAITING_APPROVAL
Default fields: none
Rule requirements:
1. There must be an entry in the Resolution field.
2. There must be an entry in the Reopen date field.
Actions:
1. The Recommendation field is set to DEFERRAL.';
};
rules {
resolution_description.isSet;
reopen_date.isSet;
}
actions {
recommendation.setValue(DEFERRAL);
}
}
////////////////////////////////////////////////////////////////////
// DUPLICATE Transition
////////////////////////////////////////////////////////////////////
DUPLICATE(AWAITING_RESPONSE=>AWAITING_APPROVAL) {
help {
help-title 'DUPLICATE Transition';
short-help-title 'DUPLICATE';
help-text'
DUPLICATE is issued by the request owner to indicate that an earlier
request made the same suggestion and that this request is unnecessary.
The DUPLICATE transition needs to be confirmed (through the APPROVE
transition) by the approver.
Prior state: AWAITING_RESPONSE New state: AWAITING_APPROVAL
Default fields: none
Rule requirements:
1. There must be an entry in the Resolution field.
2. There must be an entry in the Dup of field, indicating the earlier
transition that was duplicated.
Actions:
1. The Recommendation field is set to DUPLICATION.';
};
rules {
resolution_description.isSet;
is_duplicate_of.isSet;
}
actions {
recommendation.setValue(DUPLICATION);
}
}
////////////////////////////////////////////////////////////////////
// NOTIFY Transition
////////////////////////////////////////////////////////////////////
NOTIFYME(=>) {
help {
help-title 'NOTIFY Transition';
short-help-title 'NOTIFY';
help-text'
NOTIFYME adds a new user to the list of users to be informed when
changes occur to this request.
Prior state: any New state: any
Default fields: none
Rule requirements: none
Actions:
1. The name in the Notify field is added to the list of interested
parties for this request.';
};
actions {
interested_parties.append($USER.text);
}
}
////////////////////////////////////////////////////////////////////
// REDO Transition
////////////////////////////////////////////////////////////////////
REDO(AWAITING_APPROVAL=>AWAITING_RESPONSE) {
help {
help-title 'REDO Transition';
short-help-title 'REDO';
help-text'
An approver issues a REDO when a request has not been adequately
satisfied so that the request is returned to the owner.
Prior state: AWAITING_APPROVAL New state: AWAITING_RESPONSE
Default fields: none
Rule requirements: none
Actions: none';
};
rules {
}
actions {
}
}
////////////////////////////////////////////////////////////////////
// EDIT Transition
////////////////////////////////////////////////////////////////////
EDIT(=>) {
help {
help-title 'EDIT Transition';
short-help-title 'EDIT';
help-text'
EDIT lets you change the current values of fields in the request.
Prior state: any New state: any
Default fields: none
Rule requirements: none
Actions: none';
};
rules {
}
actions {
}
}
////////////////////////////////////////////////////////////////////
// APPROVE Transition
////////////////////////////////////////////////////////////////////
APPROVE(AWAITING_APPROVAL=>CLOSED) {
help {
help-title 'APPROVE Transition';
short-help-title 'APPROVE';
help-text'
APPROVE is only accessible to those authorized to approve requests.
APPROVE changes the state of the request from AWAITING_APPROVAL to
CLOSED. Prior state: AWAITING_APPROVAL New state: CLOSED
Default fields: none
Rule requirements: none
Actions:
1. The Approver field is set to the entered value or if none, to the
current user.
2. The Close date field is set to the current date.';
};
actions {
approver.setValue(approver.isSet ?
approver.value :
$USER.value);
close_date.setValue('now');
}
}
////////////////////////////////////////////////////////////////////
// REOPEN Transition
////////////////////////////////////////////////////////////////////
REOPEN(CLOSED=>AWAITING_RESPONSE) {
help {
help-title 'REOPEN Transition';
short-help-title 'REOPEN';
help-text'
REOPEN is used to open a request that has been deferred.
Prior state: CLOSED New state: AWAITING_RESPONSE
Default fields: none
Rule requirements: none
Actions: none ';
};
}
////////////////////////////////////////////////////////////////////
// DELETE Transition
////////////////////////////////////////////////////////////////////
DELETE(CLOSED=>DELETED) {
help {
help-title 'DELETE Transition';
short-help-title 'DELETE';
help-text'
DELETE is used to remove a request from the request database. It is
valid for the tracking system administrator only.
Prior state: CLOSED New state: DELETED
Default fields: none
Rule requirements:
1. Current user must be the tracking system administrator.
Actions: none ';
};
rules {
$USER.is(CZAR);
}
}
////////////////////////////////////////////////////////////////////
// Global Rules and Actions for All Transitions
////////////////////////////////////////////////////////////////////
rules {
help {
help-title 'Global Rules and Actions';
short-help-title 'Global Rules and Actions';
help-text'
These rules and actions are applied to all transitions.
Rule requirements:
1. Report number cannot be changed after the request has been
submitted.
2. The Recommendation field cannot be edited. It is set
automatically.
Actions:
1. Add the owner and submitter to the list of interested parties to be
notified when changes occur to the request.';
};
// The report_number can only be changed as part of
// submission.
$TRANSITION.is(SUBMIT_BUG) ||
$TRANSITION.is(SUBMIT_RFE) ||
!report_number.changed;
!recommendation.changed;
}
actions {
// If the report_number is not set, then set it to the value
// of the $ENTITY_ID field.
// report_number.setValue(report_number.isSet ?
// report_number.value : $ENTITY_ID.value);
// Execute the notifier to send mail as appropriate.
//
czar.setValue(CZAR);
notify_list.setValue(interested_parties.value);
notify_list.append(owner.value);
notify_list.append(submitter.value);
execCommand('/usr/local/lib/rts_notify');
};
}
views {
help {
help-title 'rtsquery Views';
short-help-title 'rtsquery Views';
help-text
'The rtsquery view lets you access the request database. It has four
main areas. From top to bottom these are:
* menu bar - for accessing menus
* control bar - select editing mode from the mode menu, enter
data in the appropriate fields, and complete transaction by
clicking the command (third button from left). Right four
buttons are for selecting requests in query results area.
* query results area - lists requests resulting from a query
* request form area - contains detailed request information
The rtsfiles view is an auxiliary view of the rtsquery application.
It contains a request form area with three fields. These fields list
the files associated with a request. For more help, look up the help
cards for the individual fields. ';
};
RTSQuery(){
display () {
control-bar( ) {
help {
help-title 'Control Bar';
short-help-title 'Control Bar';
help-text'
The control bar consists of the Modes menu, the Cancel and <apply
command> buttons, and the four query list control buttons.
To perform operations in the RTS applications, you choose the desired
mode from the Modes menu, edit the appropriate fields, and click the
<apply command> button (the third from the left in the control area)
to execute the operation or the Cancel button to void it. The <apply
command> button label changes as the mode, selected from the Modes
menu, changes.
The list control buttons control the selection of requests in the
query results area.';
};
// Include all transitions
transitions;
};
};
qresults() {
index type, '#' $ENTITY_ID, $STATE, owner, summary;
};
fourColumn: display() {
row{'Report #:' $ENTITY_ID,
'Status:' $STATE,
'Type:' type,
'Submitter:' submitter};
row{'Date:' submit_date,
'Recommend:' recommendation,
'Project:' project,
'Priority:' priority};
oneRowList:
row{'Owner:' owner,
'System:' system,
'Notify:' interested_parties,
'Due Date:' due_date};
row{'Close Date:' close_date,
'Reopen Date:' reopen_date,
'Approver:' approver,
'Dup of:' is_duplicate_of};
row{'Summary:' summary};
}
display() {
row{'Description:' ' '};
fourRowLongText:
row{description};
}
display() {
row{'Resolution:' ' '};
fourRowLongText:
row{resolution_description};
}
}
RTSFiles(type ' #' $ENTITY_ID ' ' $STATE ' ' owner ' ' summary) {
display() {
row{'Found in:' ' ', ' '};
row{found_in};
}
display() {
row{'Resolved in:' ' ', ' '};
row{resolved_in};
}
display() {
row{'Fixed Releases:' ' ',,,,};
row{fixed_releases};
}
}
}
|
//////////////////////////////////////////////////////////////////////
//
// File: approve.pdl
// Description: RTS approval pdl
// This pdl file defines the report approval app's GUI
// Author: Pete Orelup
// Created: Fri Apr 10 09:29:49 PDT 1992
// Language: PDL
//
// (C) Copyright 1992, Silicon Graphics, Inc.
//
// Permission to use, copy, modify, and distribute this software for
// any purpose except publication and without fee is hereby granted,
// provided that the above copyright notice appear in all copies of
// the software.
//
//////////////////////////////////////////////////////////////////////
//
views {
RTSApprove(){
help {
help-title 'rtsapprove View';
short-help-title 'rtsapprove View';
help-text
'The rtsapprove window is a supplementary application for approving
fixed requests. The transitions available in rtsapprove are: APPROVE,
NOTIFYME, REDO, and EDIT.
It has four main areas. From top to bottom these are:
* menu bar - for accessing menus
* control bar - select editing mode from the mode menu, enter data
in the appropriate fields, and complete transaction by clicking
the command (third button from left). Right four buttons are for
selecting requests in query results area.
* query results area - lists requests resulting from a query
* request form area - contains detailed request information
relevant for responding to requests. This includes a Resolution
field for explaining the fix to the request and a Resolved in
field that identifies the files that have changed as a result of
the request.';
};
control-bar( ) {
help {
help-title 'Control Bar';
short-help-title 'Control Bar';
help-text'
The control bar consists of the Modes menu, the Cancel and <apply
command> buttons, and the four query list control buttons.
To perform operations in the RTS applications, you choose the desired
mode from the Modes menu, edit the appropriate fields, and click the
<apply command> button (the third from the left in the control area)
to execute the operation or the Cancel button to void it. The <apply
command> button label changes as the mode, selected from the Modes
menu, changes.
The list control buttons control the selection of requests in the
query results area.';
};
transitions APPROVE, NOTIFYME, REDO, EDIT;
};
display () {
qresults() {
index type, '#' $ENTITY_ID, $STATE, owner, summary;
};
};
display() {
row{'Report #:' $ENTITY_ID,
'Status:' $STATE};
row{'Submitter:' submitter,
'Date:' submit_date};
row{'Type:' type,
'Recommend:' recommendation};
row{'Project:' project,
'Priority:' priority};
oneRowList:
row{'System:' system,
'Notify:' interested_parties};
row{'Owner:' owner,
'Due Date:' due_date};
row{'Duplicate of:' is_duplicate_of,
'Re-Open Date:' reopen_date};
row{'Approver:' approver, };
row{'Summary:' summary};
}
display() {
row{'Description:' ' '};
fourRowLongText:
row{description};
}
display() {
row{'Resolution:' ' '};
fourRowLongText:
row{resolution_description};
}
display() {
row{'Resolved in:' ' '};
row{resolved_in};
}
}
}
|
//////////////////////////////////////////////////////////////////////
//
// File: respond.pdl
// Description: RTS response pdl
// This pdl file defines the report response app's GUI
// Author: Pete Orelup
// Created: Fri Apr 10 09:29:49 PDT 1992
// Language: PDL
//
// (C) Copyright 1992, Silicon Graphics, Inc.
//
// Permission to use, copy, modify, and distribute this software for
// any purpose except publication and without fee is hereby granted,
// provided that the above copyright notice appear in all copies of
// the software.
//
///////////////////////////////////////////////////////////////////////////////
//
views {
RTSRespond(){
help {
help-title 'rtsrespond View';
short-help-title 'rtsrespond View';
help-text
'The rtsrespond window is a supplementary application for responding
to requests in the request database. It is intended for request
owners. The transitions available in rtsrespond are: NOTIFYME,
FORWARD, EDIT, DEFER, RESOLVE, REJECT, and DUPLICATE.
It has four main areas. From top to bottom these are:
* menu bar - for accessing menus
* control bar - select editing mode from the mode menu, enter data
in the appropriate fields, and complete transaction by clicking
the command (third button from left). Right four buttons are for
selecting requests in query results area.
* query results area - lists requests resulting from a query
* request form area - contains detailed request information
relevant for responding to requests. This includes a Resolution
field for explaining the fix to the request and a Resolved in
field that identifies the files that have changed as a result of
the request.';
};
control-bar( ) {
help {
help-title 'Control Bar';
short-help-title 'Control Bar';
help-text'
The control bar consists of the Modes menu, the Cancel and <apply
command> buttons, and the four query list control buttons.
To perform operations in the RTS applications, you choose the desired
mode from the Modes menu, edit the appropriate fields, and click the
<apply command> button (the third from the left in the control area)
to execute the operation or the Cancel button to void it. The <apply
command> button label changes as the mode, selected from the Modes
menu, changes.
The list control buttons control the selection of requests in the
query results area.';
};
transitions NOTIFYME, FORWARD, EDIT, DEFER, RESOLVE,
REJECT, DUPLICATE;
};
display () {
qresults() {
index type, '#' $ENTITY_ID, $STATE, owner, summary;
};
};
display() {
row{'Report #:' $ENTITY_ID,
'Status:' $STATE};
row{'Submitter:' submitter,
'Date:' submit_date};
row{'Type:' type,
'Recommend:' recommendation};
row{'Project:' project,
'Priority:' priority};
oneRowList:
row{'System:' system,
'Notify:' interested_parties};
row{'Owner:' owner,
'Due Date:' due_date};
row{'Duplicate of:' is_duplicate_of,
'Re-Open Date:' reopen_date};
row{'Approver:' approver, };
row{'Summary:' summary};
}
display() {
row{'Description:' ' '};
fourRowLongText:
row{description};
}
display() {
row{'Resolution:' ' '};
fourRowLongText:
row{resolution_description};
}
display() {
row{'Resolved in:' ' '};
row{resolved_in};
}
}
}
|
//////////////////////////////////////////////////////////////////////
//
// File: submit.pdl
// Description: RTS submittal pdl
// This pdl file defines the report submission app's GUI
// Author: Pete Orelup
// Created: Fri Apr 10 09:29:49 PDT 1992
// Language: PDL
//
// (C) Copyright 1992, Silicon Graphics, Inc.
//
// Permission to use, copy, modify, and distribute this software for
// any purpose except publication and without fee is hereby granted,
// provided that the above copyright notice appear in all copies of
// the software.
//
//////////////////////////////////////////////////////////////////////
//
views {
RTSSubmit(){
help {
help-title 'rtssubmit View';
short-help-title 'rtssubmit View';
help-text '
The rtssubmit window is a supplementary application for creating new
requests in the request database. The transitions available in
rtssubmit are: SUBMIT_BUG, SUBMIT_RFE, ASSIGN, FORWARD, NOTIFYME, and
EDIT.
It has four main areas. From top to bottom these are:
* menu bar - for accessing menus
* control bar - select editing mode from the mode menu, enter data
in the appropriate fields, and complete transaction by clicking
the command (third button from left). Right four buttons are for
selecting requests in query results area.
* query results area - lists requests resulting from a query
* request form area - contains detailed request information
relevant for submitting requests. This includes a Found in field
for identifying the location of the request.';
};
control-bar( ) {
help {
help-title 'Control Bar';
short-help-title 'Control Bar';
help-text'
The control bar consists of the Modes menu, the Cancel and <apply
command> buttons, and the four query list control buttons.
To perform operations in the RTS applications, you choose the desired
mode from the Modes menu, edit the appropriate fields, and click the
<apply command> button (the third from the left in the control area)
to execute the operation or the Cancel button to void it. The <apply
command> button label changes as the mode, selected from the Modes
menu, changes.
The list control buttons control the selection of requests in the
query results area.';
};
transitions SUBMIT_BUG, SUBMIT_RFE, ASSIGN, FORWARD,
NOTIFYME, EDIT;
};
display () {
qresults() {
index type ' #' $ENTITY_ID ' ', $STATE ' ', owner ' ',
summary;
};
};
display() {
row{'Report #:' $ENTITY_ID,
'Status:' $STATE};
row{'Submitter:' submitter,
'Date:' submit_date};
row{'Type:' type,
'Recommend:' recommendation};
row{'Project:' project,
'Priority:' priority};
oneRowList:
row{'System:' system,
'Notify:' interested_parties};
row{'Owner:' owner,
'Due Date:' due_date};
row{'Summary:' summary};
}
display() {
row{'Description:' ' '};
fourRowLongText:
row{description};
}
display() {
row{'Found in:' ' '};
oneRowList:
row{found_in};
}
}
}
|