Building a Bug Tracker: My Bugs Section
With the layout ready to go, we are ready to consider how to display posts in a variety of useful ways, so that both reporters and developers can easily sift through what has already been reported, the report’s status, and any discussion regarding that report.
To begin, let’s start by quickly supply the reporters a list of their own reports. That way they can track the status on those reports as well as respond to any enquiries for further details.
In order to achieve an infrastructure that can easily be expanded down the line, we’re not going to restrict ourselves to one mega-template; instead, we’ll create function-based templates that we can expand on later in order to get detailed reports.
Our first goal for this is to be able to limit bug reports by the reporter. So, let’s make a template and call it by_author. This will be in the bug_tracker template group. When you create this template, duplicate the bug_tracker template group’s index.
This template is going to remain largely the same as the index template. Only now, we’re going to add the dynamic= and username= parameters, with the username= calling the third segment. This will be the new weblog entries opening tag:
{exp:weblog:entries weblog="{bug_tracker_weblog}" limit="30" status="Open|New|Confirmed|Unconfirmed|External|Resolved" username="{segment_3}" dynamic="off"}
Important to note is that if we did not turn dynamic off here, then the weblog entries tag would believe that Segment 3 was a URL Title, and would give us different results than what we are after.
Now we’ll add a link in our left navigation, under “Search and Report”, and call it “View My Bugs”. The link will look like this:
<a href="{path="{bug_tracker_template_group}/by_author}{logged_in_username}"}">View My Bugs</a>
Not only have we now set up the ability for the reporter to view their own reports, we have also set up the infrastructure that will allow us to create links for any bug reporter, by simply passing the username in the URL.
If you test at this point, it beccomes readily apparent that we get a rather uninformative page if we pass an non-existing username via Segment 3. At this point, it would be good to make use of the if no_results conditional variable pair. You can do that by simply adding the following code directly under your opening weblog entries tag:
{if no_results}
<p>No Bugs Reported</p>
{/if}
Here is the finished by_author template:
{html_begin}
{embed="inc/.head" title="Bug Tracker"}
<body>
<div id="container">
{embed="inc/.banner"}
{embed="inc/.leftnav"}
<div id="content">
{!-- Showing My Bug Reports --}
<h3>Bugs Reported by {logged_in_username}</h3>
{exp:weblog:entries weblog="{bug_tracker_weblog}" limit="30" status="Open|New|Confirmed|Unconfirmed|External|Resolved" username="{segment_3}" dynamic="off"}
{if no_results}
<p>No Bugs Reported.</p>
{/if}
{if count == "1"}
<table>
<tr>
<th>ID</th>
<th>Status</th>
<th>Version</th>
<th>Description</th>
</tr>
{/if}
<tr>
<td>{entry_id}</td>
<td>{status}</td>
<td>{bug_tracker_version}</td>
<td>{bug_tracker_details}</td>
</tr>
{if count == total_results}
</table>
{/if}
{/exp:weblog:entries}
{!-- End Bug List --}
</div>
{embed="inc/.footer"}
</div>
{html_end}
Of course, there are other ways that we could have handled this, and I’ll give a brief mention of them. We could have, for instance, used:
username="CURRENT_USER"
However, to do that would have involved either a dedicated template, or a series of conditionals in order to ascertain what segment 3 contained. In this case, by simply using the logged in member’s username, we were able to create a clean, optimized template with all the functionality that we required.
It is easy to see how important URL segments can be to ExpressionEngine; not just in the normal usage, but when we vary up what they mean, and define our very own semantics.
