Student projects/Integrated bug tracker
Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Student projects/Integrated bug tracker.
- 1 Bug Tracker Module
- 2 Progress
- 3 Customer Relationship Management Module
Bug Tracker Module
I've just added (a few of what I consider the most essential) feature requests. If you object to me doing this, just delete the bits I added.
- Use Moodle authentication and user accounts to login/report bugs/assign bugs/resolve bugs
- Link related/dependent bugs and the status of related/dependent bugs
- Allow the dependancy to be created from either end (like bugzilla) -- Tim.
- Display the dependancy information in both bugs (like bugzilla) -- Tim.
- View a particular bug as an external user (not logged in) using a simple URL (e.g. http://moodle.org/mod/tracker/view.php?issue=3455)
- All fields capable of using Moodle rich text editor as appropriate
- Subscribe/unsubscribe to receive bug emails
- I don't think that the person who reported the bug should be allowed to unsubscribe. There is nothing more annoying than trying to investigate a bug, adding a comment requesting more information, and the oringinal reporter never responding. -- Tim.
- Generate bug reports by user/severity/build/status
- Generate Release Notes
- Create and save common reports/queries
- Automatically turn the text bug 1234 into a link to that bug. -- Tim.
- Whenever a link to another bug is printed, add a tooltip giving summary information (like bugzilla) -- Tim.
System Development Lifecycle
- Report a Bug Page
- Allow users to report a bug
- Requires that users be logged in to report a bug
- View Page
- Browse Subpage
- Allow users to browse through bugs ordered according to bug number
- View bug information on one page. Click on the next or previous link will display the next or previous bug according to bug number. Next and previous by bug number is useless. It must be next and previous by last search results. --Tim.
- If the user is specfied as a developer or as the instructor of the course, then certain fields will be editable such as status and comments. Anyone (logged in) should be allowed to comment. Anyone who can contribute to undesrstanding the problem should be able to. -- Tim.
- Search Subpage
- Reports Subpage
- The reports page will display a list of predetermined queries that the instructor of the course or developers can create. A report will be customizable to display summaries only, the full report, or compiled in a format similar to release notes. There will also be a printer-friendly version of a report (and hopefully a downloadable version as .txt or .csv / .xls)
- Browse Subpage
- Admin Page
- The Admin Page will allow instructors of a course to administrate the bug tracker. The page will allow instructors to create new bug categories. The Admin page will also allow the instructors of a course to specify which users are developers (a new type of user). When users are specified as a developer for a bug tracker, they will then be able to edit a developer profile.
- In an effort to make the bug tracker as generic and customizable as possible, administrating the bug tracker is similar to administrating a quiz. In a quiz, there are three parts: the quiz body, the quiz category, and the quiz questions. In the bug tracker, there are two parts: the bug tracker and the bug category.
- The bug tracker is analogous to the quiz body in that both contain settings that are considered common to all bug trackers and quiz bodies respectively.
- The bug category is analogous to the quiz QUESTION, in that there will be multiple types (drop-down menu, radio buttons, text fields, checkboxes) and each type will have their own settings. For example, a drop-down menu will have category items that will require user input to specify the items in the drop-down menu whereas the text field is simple and may not require any setup.
- The profile page will allow users specified as the developer of a bug tracker to be able to change certain preferences like email subscriptions and so forth.
- a tracker module is placed by the instructor / administrator (tracker admin: TA)
- the TA then gives the tracker a name and a description of its function as well as specify whether login is required to enter a bug
- the TA saves changes
- The TA then needs to specify which categories the tracker will use. Categories are customizable HTML widgets that a TA can place on a tracker.
- For example, if the TA wants to track browser types on an issue, the TA can create a Browser category. Once a category is created, it is saved and can be used with any tracker in a single class.
- Rather than defining new categories, the TA can use categories from a set of predefined categories (which include browser, os, resolution, etc.)
- The TA will now need to select the categories (either predefined or ones that the TA defined) to associate with this tracker
- This is all done on the admin tab, which is only appears for the TA
- The TA will also need to specify which users in the course (or system) are eligible as developers. This is done on the admin tab.
- The TA can also grant administrative privileges to other users. However, only instructors in the course can create new TAs.
- At this point, the tracker is setup
- Users can now submit issues to the tracker.
- Normal, regular users (USERS) will see two tabs: Report an issue tab and the View tab. USERS can report an issue using the Report an issue tab or look through the issues db using the View tab (which include browse and search)
- Developers (DEV) can see three tabs: Report an issue, View, and Profile. Once an issue is submitted, developers can view the issues via the View tab using the search or browse functionality. For DEV there is also reports functionality available on the View tab. Reports are saved search queries. Reports are associated to a developer or TA. Reports created by a DEV can only be seen by the DEV. However, the TA has the option to publish reports the TA has created for everyone to use.
- When viewing a report, the DEV can modify the fields that the TA specified as well as comment on the issue. This may include fields like resolution and status.
- DEV can also view their profiles where they can specify whether to enable or disable their email. When an issue is assigned to DEV, they will receive an email telling them they have a new issue assigned to them (as well as listing the entire issue in the body of the email) unless they disable their email.
- When TA views a bug, they will be able too do everything DEV can do as well as assign issues. DEV should not be able to assign issues. I disagree. Developers should be able to reassign issues to other developers. For example, I am quiz module maintainer. All issues come to me initially. However, Howard deals with all import and export bugs, so I (developer) regularly reassign bugs to him. Don't take that feature away from me. -- Tim.
(bugzilla probably goes over the top). Can't we have sligtly more fine-grained control? -- Tim.
- Data Dictionary
- Create database, tables, etc.
- Create bug database access library
- Getter, setters, etc.
- Create bug submission form
- Submit to database
- Create View bug form
- Incorporate Moodle Authentication
Tentative Timeline / Milestones
June 28, 2006
- First Deliverable - Prototype
July 7, 2006 - July 14, 2006
- User Testing
July 14, 2006
- Start migrating old Moodle Bugs
July 28, 2006
- Second Deliverable - Prototype 2
July 28, 2006 - August 14, 2006
- QA & Fix bugs
- Accessibility Compliance?
August 7 - August 21, 2006
August 21, 2006
- Final Deliverable - Finished Product
- First exploratory iteration
- Created bug tracker class
- Tabs layout structure with report a bug, search, browse, admin tabs, reports
- Submit bug
- View bug