Building a Bug Tracker: Bug Submissions
Now we know what kind of functionality the bug tracker will have. The first thing the bug tracker needs to do is accept bug reports. We don’t really want to give all of our members access to the control panel, but really any member should be able to submit a bug.
Let’s explore getting the bug reporting set up then, shall we?
The first thing to do is head to Admin -> Members & Groups -> Member Groups and edit the member groups that should be able to submit bug reports.
Head down to Weblog Assignment, and for “Can post and edit entries in: Bug Tracker” choose “yes”. We’ll keep the rest as is.
But how can we let them create entries if they can’t get into the control panel? Enter the Stand Alone Entry Form.
We’re going to modify this form a bit, and simplify it, because we really don’t need our members to see every option. So, first, create a new template in the bug_tracker template group. Call it “submit_bug”, choose to duplicate an existing template (make sure you click that Radio button!) and duplicate bug_tracker/index.
Now, in bug_tracker/submit_bug, we’re going to edit the template and inside the content div, we’ll replace the code for the list of entries with code for the Stand Alone Entry Form.
The first thing to do is copy the example from the docs and then start customizing it. The first thing to customize is the weblog=, return=, and preview= in the opening tag. Mine now looks like this:
{exp:weblog:entry_form weblog="bug_tracker" return="bug_tracker/index" preview="bug_tracker/submit_bug"}
Next it’s time to go through and remove the elements we don’t want the user modifying. Those elements are:
* URL Title
* Formatting Buttons
* File Upload and Smileys
* Trackbacks
* Status
* All Date Fields
* Checkbox options for sticky, allow comments, allow trackbaacks, and DST Active.
* Ping Servers
Regarding status, as we remove the status drop-down, we should set the default status as a parameter of the form, using:
status="New"
New bug reports should always be a “New” status. This needn’t be a choice for the end-user, so we can force it as a parameter.
For aesthetics, we also want to customize this a bit - we have a few categories, so make that category select box size=“10”:
{category_menu}
<p>Categories<br />
<select name="category[]" size="10" multiple="multiple">
{select_options}
</select>
</p>
{/category_menu}
The textarea really needs to be enlarged for larger bug reports. Now you’ll notice the rows=”{rows}” in our Textarea. We can change that, instead, in our custom field. So head here:
Admin › Weblog Administration › Field Groups › Custom Fields
and Edit the Details custom field in your Bug Tracker custom field group. Set the Textarea rows to be 10. Now have a look at your form - that’s a much nicer space for a report.
We can return to the template and remove the conditionals to check if the custom fields are dates or relationships. For the purposes of this bug tracker, we have already identified what types of custom fields we have and know that we won’t be using those two types - so no reason to have the template parser deal with them.
Next is to remove the preview code. the reason for this is that we haven’t yet decided what a single bug report will look like. Once we have designed that, then we can come back and build a proper preview. Currently, it’s not needed - we now have a method for submitting reports.
The end result for how this template looks in the Templates screen is like so:
{doctype}
{embed="inc/.head" title="Bug Tracker"}
<body>
<div id="container">
{embed="inc/.banner"}
{embed="inc/.leftnav"}
<div id="content">
{!-- SAEF --}
<table>
<tr>
{exp:weblog:entry_form weblog="bug_tracker" return="bug_tracker/index" status="New"}
<td>
<p>Title<br />
<input type="text" name="title" id="title" value="{title}" size="60" maxlength="100" onkeyup="liveUrlTitle();" /></p>
{custom_fields}
{if required}** {/if}{field_label}
{field_instructions}
{if textarea}
<br /><textarea id="{field_name}" name="{field_name}" dir="{text_direction}" cols="60" rows="{rows}" onclick="setFieldName(this.name)">{field_data}</textarea>
{/if}
{if textinput}
<input type="text" dir="{text_direction}" id="{field_name}" name="{field_name}" value="{field_data}" maxlength="{maxlength}" size="50" onclick="setFieldName(this.name)" />
{/if}
{if pulldown}
<select id="{field_name}" name="{field_name}">
{options}<option value="{option_value}"{selected}>{option_name}</option>{/options}
</select>
{/if}
{/custom_fields}
<p><input type="submit" name="submit" value="Submit" />
</td>
<td>
{category_menu}
<p>Categories<br />
<select name="category[]" size="10" multiple="multiple">
{select_options}
</select>
</p>
{/category_menu}
</td>
{/exp:weblog:entry_form}
</tr>
</table>
{!-- End SAEF --}
</div>
{embed="inc/.footer"}
</div>
{html_end}
and our users will see this:
Of course, now that we have this working, we can do one more thing: Link our “Report” link to the submission form! Open inc/.leftnav, and replace:
<li><a href="#">Report</a></li>
with
<li><a href="{path="{bug_tracker_template_group}/submit_bug"}">Report</a></li>
We’re all set, now, to collect data. As we go forward, we’ll work on ouputting that data in a variety of useful ways for both the bug reporters, and the developers fixing those bugs.
