oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Build a Web-Based Bug Tracking App, Part 2

by Jesse Liberty

In a previous column, I began work on a very simple bug tracker that I could use to keep track of bugs (and their squishing) in my own small projects. In this column, I will add a number of additional features that make the product significantly more useful and that illustrate what I hope will be interesting techniques in building web-based applications.

  1. Grid will display the date the bug was originally reported, as well as the date it was last updated.
  2. Ability to filter for open bugs only.
  3. Ability to filter for "my bugs" only (bugs assigned to me).
  4. Implement cancel in the bug reporting page.
  5. Mark "show stopper" bugs in red.

In addition, the new code will enforce two new business rules:

  1. Once a bug is given a short description, that field can not be changed.
  2. Only QA can close a bug (the programmer can mark it "fixed," but only QA can mark it "closed".

A number of features will be hard-coded in the interest of making the article more readable.

Filtering Bugs and Displaying the Original Reported Date

To begin, you'll want to make a copy of the previous application (which you can download from my website) and, if you have not yet done so, use that same downloaded code to create (or restore) the database. Note that since the publication of the earlier article I have renamed the TimeRecorded field in BugHistories and have set it as a DateTime field that will be filled by parameters in the appropriate stored procedures.

Recording the Original Reported Date

To get started, modify the Bugs table, and add a single column, DateFirstRecorded, of the type DateTime. This will require a modification to the stored procedure spNewBug to ensure that the DateFirstRecorded field is populated when a new bug is created.

ALTER PROCEDURE [dbo].[spNewBug]
@ModifiedBy varchar(100),
@ShortDescription varchar(50),
@LongDescription ntext,
@Severity int,
@Notes ntext,
@Status int,
@Owner varchar(100),
@TimeRecorded datetime
Begin Transaction 
   declare @bugID as int
   --declare @Placeholder as varchar(50)
   Insert into Bugs (PlaceHolder, DateFirstRecorded) 
   values (@ShortDescription, @TimeRecorded)
   select @bugID = @@identity
   if @@error <> 0 goto errorHandler
   insert into BugHistories ( BugID, BugHistoryID, TimeRecorded, ModifiedBy, 
      ShortDescription,LongDescription, Severity, Notes, 
      Status, Owner)
      values (
      @bugID, 1, @TimeRecorded, @ModifiedBy, @ShortDescription,
      @LongDescription, @Severity, @Notes, @Status, @Owner)
   if @@error <> 0 goto errorHandler
   commit transaction
   goto done
   rollback transaction

That done, the remaining changes all happen in the application itself.

As a start, add two check boxes to the TBTReview.aspx page: one to signify that you want to see only your own bugs, and the other to indicate that only open bugs should be displayed, as shown in Figure 1.

Figure 1. Checkboxes

Note that while I was at it, I changed the label control to display yellow, bold print on a red background; we'll use this later to indicate whether or not a record was updated or added.

Programming ASP.NET

Related Reading

Programming ASP.NET
Building Web Applications and Services with ASP.NET 2.0
By Jesse Liberty, Dan Hurwitz

Pages: 1, 2, 3, 4

Next Pagearrow