Question

• TWiki version: (TWiki version: 01 Feb 2003)
• Perl version: 5.6.1
• Web server & version: Apache
• Server OS: SunOS + Linux
• Web browser & version: Internet Explorer 6.0
• Client OS: WinXP

I am confused as to what is the best, or at least standard, way to create an issue tracking system (bug tracking system, to do list, etc.) in TWiki.

I think my problem is that there seem to be several different ways of doing so, and I do not understand the tradeoffs.

For example:

• ActionTrackerPlugin looks like it does this

• TWiki forms seem to be possibly useful
  • Q: is there a Date field type, so I can sort things by due date, etc?
  • Q: how scalable is this? My company's projects usual use an Oracle database for issue tracking.
  • Can these be made SelfSchematizingTWikiData?

• It appears that TWiki can be interfaced to an external database, such as the company issue database I mentioned above.

To be honest, I'm interested in an issue tracking system that is lighter weight than the corporate Oracle database. I just don't want to start off using, say, TWiki forms, and then realize it won't scale.

-- AndyGlew - 15 Apr 2003

For example, I just started using Twiki forms, and it quickly became obvious that having the user choose a unique wiki name is not so good an idea. Generating a unique name (number) for a bug report is a good thing, although it might be nice if the user could provide some extra info.

Answer

See TicketWiki for some more experience in this area. Of course, Codev is an example of a bug tracking system, albeit not that great (see CodevFields) at present.

-- RichardDonkin - 16 Apr 2003

One Implementation

Andy,

I prototyped a bug tracker for my group and used a number of features in TWiki to make it full-featured. We didn't adopt it, because TWiki still hasn't caught hold here and there are already some packaged (read 'more structured') solutions that are easier. But here's what I did:

• Separate Web, called Bugs
• Created a custom page template to prompt for large text pieces of info we needed about the problem and solution.
• Created a form to hold the smaller text chunks, especially those we wanted to search by. Form is here:

| *Name* | *Type* | *Size* | *Values* | *Tooltip message* |
| Title | text | 80 | | Enter concise title (max 80)|
| BugClassification | select | 1 | | Classify this request |
| BugStatus | select | 1 | | Select bug's current status |
| BugPriority | radio | 4 | PayStop, High, Medium, Low | How much is this preventing the user from working |
| DateOpened | text | 20 | | Date issue opened |
| DateClosed | text | 20 | | Date issue closed or put on hold |
| Developer Assigned | text | 40 | Main.yourWikiName | Developer responsible for investigating this problem. |
| Reported By | text | 30 | Main.... | Who reported this problem |
| End User | text | 80 | Main.... | Enter the user's Wiki name or email address |
| End User Phone | text | 8 | 6- | Enter the user's extension |

• The main page, called BugList has
  • a series of Searches for the bugs of the various statuses (New, Open, Closed, etc). Each looks like the following:

| *Topic Name* | *Title* | *Priority* | *Mod. By* |
%SEARCH{"[B]ugStatus.*value\=.*[N]ewBug" scope="text" regex="on" nosearch="on" order="formfield(ProjectTitle)" casesensitive="off" format="| $topic | $formfield(Title) | $formfield(BugPriority) | $date |"}%

• a special form on it for creating a new bug page. Instructions tell them to name it starting w/ 'Bug', then the topic, and end w/ a number, in case there are duplicates. The code for it is here:

<form action="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/"> 
Create a new bug entry: &nbsp; (Use a name in TWiki.WikiNotation) <br /> 
<input type="text" name="topic" value="Bug...001" size="32" /> 
<input type="hidden" value="NewBug" name="BugStatus" /> 
<input type="hidden" name="topicparent" value="BugList" /> 
<input type="hidden" name="onlywikiname" value="on" /> 
<input type="submit" value="Create New Bug Page" /> 
</form>

-- StewStryker - 17 Apr 2003

See Sandbox.ChangeRequest, it generates a consecutive number for topic names. Can be fooled though.

A simple solution is to generate a topic name by date down to the second, it is highly unlikely that two persons create a bug entry in the exact same second. Example: BugID%SERVERTIME{$year$mo$day$hour$min$sec}% turns into BugID20260227054504.

-- PeterThoeny - 17 Apr 2003