WindowsDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


AddThis Social Bookmark Button

Build a Web-Based Bug Tracking App, Part 2
Pages: 1, 2, 3, 4

The logic of filtering for my bugs and/or open bugs will be accomplished by modifying the select statement in the TBTDataSource control.



select bh.BugID, bh.BugHistoryID, ShortDescription, TimeRecorded, ModifiedBy, sev.Text as Severity,
stat.Text as Status, Owner, DateFirstRecorded from BugHistories bh
join Severities sev on sev.SeverityID = bh.Severity
join Statuses stat on stat.StatusID = bh.Status
join Bugs on bugs.bugID = bh.BugID
join (select bugId, max(bugHistoryId) as bugHistoryId from bughistories
  group by bugId) b
  on bh.bugId = b.bugId and bh.bugHistoryId = b.bugHistoryId
where Owner like  @Owner and Stat.Text <> @StatText
order by bh.bugid

The select statement now joins the bug table to select the DateFirstRecorded field. The new where statement uses the term like to match any bugs whose owner field matches the logged-in user's name. The second part of the where clause will exclude any matches that match the string (if any) that is passed in. For now, we'll hard code the string "Closed" if the appropriate check box is selected.

Unfortunately, this change to the DataSource control's schema requires rebuilding the columns for your grid, but that is quite all right, as we want to accommodate the DateFirstReported. Thus we re-name and re-order the fields in the grid as shown in Figure 2.

Thumbnail, click for full-size image.
Figure 2. Review grid (Click for full-size image)

Short Description is Read-Only

In practice, the short description (shown in the Bug column in Figure 2) acts as the "name" of the bug, and thus should not be modified when the bug is updated. The easiest way to accomplish this is to add a single line to the code that already exists to fill the fields with their existing values if we are updating an existing bug.

if (dv != null)  // yes it is a revision
{
    DataTable dt = dv.Table;

    // get the row for the latest BugHistory
    DataRow dr = dt.Rows[0];  
    //...
    this.txtShortDescription.Text = dr["ShortDescription"].ToString();
    this.txtShortDescription.ReadOnly = true;

Only QA Can Close A Bug

We have quickly accomplished requirements 1-5. Next, to ensure that only QA can close a bug, we'd like not to even offer the Close choice to anyone who is not in the QA role. The simplest way to accomplish this is to wait for the drop-down menu for the bug Status to be bound to its table, and then to delete the Closed element if the user is not in the QA group. We begin by adding an event handler for the DataBound event of the drop-down control, as shown in Figure 3.

dataBoundEvent
Figure 3. Adding the DataBound event

The event handler itself must check to see if the user is in the QA role, and if not, find the item in the list that contains the word closed and take it out of the list. The simplest approach is just to wait for the list to be filled (which will be true when the DataBound event is fired) and then iterate through the list until the item is located.

protected void ddlStatus_DataBound(object sender, EventArgs e)
{
    if (User.IsInRole("QA") == false)
    {
        // ddlStatus.Items.Remove("Closed");
        foreach (ListItem li in ddlStatus.Items)
        {
            if (li.Text.ToUpper() == "CLOSED")
            {
                ddlStatus.Items.Remove(li);
                break;
            }
        }
    }
}

Pages: 1, 2, 3, 4

Next Pagearrow