Build a Web-Based Bug Tracking App, Part 2

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

AS

BEGIN

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

errorHandler:

   rollback transaction

done:

END

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.

Related Reading Programming ASP.NET Building Web Applications and Services with ASP.NET 2.0 By JesseLiberty, DanHurwitz Table of Contents Index Sample Chapter

[1] [2] [3] [4] Next