The ptweb template supports a typical web site development process. Typical of this process is the immediate posting of bug fixes to the web site being developed and maintained. This model assumes the follow organizations are involved in the defect tracking process:
Responsible for performing engineering development tasks necessary to handle the request.
Verifies that the request has been successfully implemented by the Engineering organization.
Places the updated files onto the live server.
The data record contains the following fields. Note that you can customize the database by adding to or removing fields, or changing any pulldown menu values. Field names with an asterisk are required by the system and cannot be removed from the data record.
|PRN*||Numeric record identifier. Assigned at the time the record is created.|
|Title||A one line text summary of the problem report. Set at the time the record is created.|
|Product*||Identifies the product the problem record has been reporter for. Set at the time the record is created.|
|Browser||Describes the browser the problem occurs on. Examples include Internet Explorer 4.0, Netscape 4.5, etc. Set at the time the record is created.|
|Platform||Describes the hardware or software platform the problem occurs on. Examples are the operating system (e.g. Windows 95), or the CPU (e.g. Intel Compatible). Set at the time the record is created.|
|Problem URL||URL of the web page that a problem was found on. Set at the time the record is created.|
|Request Type||Classifies the problem report. Possible values are: Bug, Contract Requirement,Customer Feedback, Customer Problem, Enhancement. Set at the time the record is created.|
|Severity||Describes how serious the problem is. Set at the time the record is created.|
|Description||Full description of the problem. Ideally describes the nature of the problem and how to reproduce the behavior. Set at the time the record is created.|
|Reported By*||Name of the user that reported the problem. Initially set to the name of the current user logged in. Set at the time the record is created.|
|Date Reported||The date the record was created. Automatically initialized, and set at the time the record is created.|
|Workaround||Describes how to work around the reported problem. Set at the time the record is created.|
|Status*||Current state of the problem record. Changes as the record is processed through the workflow.|
|Substatus||Describes the the condition of the record in the current state. Possible values are: None, In Progress. Optionally set by each user while processing the record.|
|Assigned To*||User the record is currently assigned to for processing. Set either manually or automatically during processing of the workflow.|
|Estimated Size||Used to enter an estimated amount of time it will take for an engineer to fix the problem.|
|Fix - Close Date||Date when the problem record was fixed. Set by Engineering when the problem is fixed. Automatically initialized to the current date/time.|
|Fix-Close Detail||A Description of the action taken by an engineer to fix the problem. Set by Engineering when the problem is fixed.|
|Priority||Describes the relative importance of handling this record compared to other records entered in the system.|
|Deleted*||Has the record been deleted.|
|Date Tested||Date when the fix for the problem record was tested. Set by QA when the problem is fixed. Automatically initialized to the current date/time.|
|Test URL||URL of the web page that is an example of the problem fix. Can be set by either engineering or QA to allow verification of the fix.|
|Date Released||Date when the fix for the problem is made live on the appropriate server. Set by Build when the fix is applied.s fixed. Automatically initialized to the current date/time.|
The workflow implemented by the ptweb database is as follows:
This is implemented by defining Reported as the default state when a record is added, assigning the process_mgr user as the manager for the Reported state, defining the Status and Assignee field to be presented for the Task operation on the Reported state, and by assigning eng_one as the manager for the Scheduled state.
This is implemented by defining the "In Development" state as the next state for "Scheduled", and defining the Assignee field to be presented for the Task operation on the "Scheduled" state.
This is implemented by defining "Fixed" as the next state for "In Development", defining the Fix-Close date and Fix-Closed description to be presented for the Task operation on the "In Development" state, and defining the qa_mgr user as the manager for the Fixed state.
This is implemented by defining "In QA" as the next state for "Fixed", and defining the Assignee field to be presented for the Task operation on the "Fixed" state.
This is implemented by defining "Tested" as the next state for "In QA", and defining the user "bld_mgr" as the manager for the Tested state.
This is implemented by defining "Released" as the next state for "Tested", and defining the user "process_mgr" as the manager for the Released state.
The ptweb template is set up to notify users as follows:
On Add or Delete Record
Both the current assignee, and the manager for the current state are notified.
On Change of State
The manager for the new state is notified.
On Change of Assignment
Both the previous and current assignee are notified of the change, and the manager for the current state is notified.
The ptweb template assumes a very simple security model reflecting a workgroup situation where all users are considered knowledgeable in use of the system and are trusted to perform the appropriate actions. As such, all manager and users have been given access to all operations except the admin operations, which are only available to the Admin user.
Since no restrictions are placed on any users as far as visibility of records, all users are able to see any record. This is implemented by setting Enable Record-Level Security option under General Preferences in the Administration Task page to No.