Tracking project issues
Because you are a Project Owner, you automatically have administrative permissions in IssueZilla to manage and track your project's issues. Along with the options available to other project members, your view of the Issue Tracking page includes a Configuration Options link that will take to the Issue tracking configuration parameters for project page. Almost all administrative options are included on this page. (See "Configuring IssueZilla's administrative options" below for descriptions of the fields you can configure.) The exception to this is the assigned to field. The assigned to field is configurable only by the Host Administrator and may be configured as either a drop down box or a text box in which the user can manually type the name of the user to be assigned. As a drop down box, the user names listed have direct roles in the project.
Your role of Project Owner gives you the ability to configure almost every element of IssueZilla. Probably the most significant permission you have is the ability to edit the issue tracking permissions of all other users on your project. This can include delegating some of these administrative permissions to other users to help manage and plan the project workload. If one of your project members builds a solid track record of committing issues that get confirmed, this is probably a person who understands the project and the issue tracking system well enough to be granted the "Can confirm an issue" permission. As a project owner, you can and should use IssueZilla to track this kind of information about project participants to help you manage project issues effectively.
To learn how to assign issue tracking permissions to project members, see "Users" in the next section
You can configure Issue Attributes and Operating Parameters from the Issue tracking configuration parameters for project page. Below are descriptions of the options that you can configure:
- Issue Attributes
-
- Add/edit components
-
When a project is created an issue database is created with the name of the project as the default component in IssueZilla. Each component is a unique entity within IssueZilla. All issues must be associated with a component to be created. The component interface allows you to define subcomponents, versions and milestones.
- Subcomponents
- A subcomponent may be used to define functional areas within the component. For example, for a component called pacman you may have a set of subcomponents with the following titles; user interface, strategy, user documentation, installation, etc. A subcomponent inherits all the characteristics of the parent component. Thus, if you assign a set of version numbers to a component, all subcomponents will receive the same set of versions. A component selection screen that lets you create, define, edit, add, and delete project components and subcomponents.
- Versions
- To assist in tracking the releases and build cycle of your project you can assign versions to your component. Versions represent a full unit of a release cycle. That is, the version is used to track the process from original design, through development and final release. The version includes the development, QA and release cycles. HINT: to assist in your review process you may want to consider using the same versions as you use to tag unique code sets in CVS.
- Milestones
- Milestones are significant points in the development process which you may wish to track. For instance you may have design, scoping, development, documentation, QA and release milestones. The milestone field can be used to run reports on the progress of your project.
- Add/edit keywords
- Allows you to create, define, edit, and delete regular expression keywords to be used for issue tracking groups and queries.
- Add/edit platforms
-
Allows you to apply a sort key, mark as Closed, or Delete any of the defaults, or add new platforms. Default platforms are:
- All (happens on all platform; cross-platform issue)
- DEC
- HP
- Macintosh
- Palm PDA
- PC
- SGI
- SUN
- Other
- Add/edit operating Systems
- Allows you to apply a sort key, mark as Closed, or Delete any of the defaults, or add new operating systems. Default values include most available operating systems.
- Operating Parameters
-
- Edit users
- Allows you to access the user edit screen either by filtering for specific users or leaving it blank to access the full list of users after clicking the "Submit" button. Clicking on listed user's link displays another edit screen where you can check and uncheck permissions options.
- Add/edit groups
- Allows you to create, define, and delete groups specifically for issue tracking purposes, and assign project member users to groups. You can make changes to one, several, or all fields and submit them all at once. Your project also includes a default set of groups pertaining to issue tracking permissions.
- Edit advanced configuration options
- Allows you to edit the values of many of the keys within IssueZilla. This page should be handled with care! Checking the Reset box on any item will reset it to the default value.
- Add/edit mimetypes
- Allows you to create, define, edit or delete descriptions for attachment uploads.
- Add/edit hosts
- Allows you to create, edit or delete hosts for issue export.
- Edit issue import configuration rules
-
Allows you to set rules and field values to be used when importing issues from another project's database. The following items can be configured:
- Component
- Subcomponent
- Version
- Milestone
- User resolution
- Importing votes
- Subject prefix for imported issues
- Run sanity check
- Allows you to run an automated process that checks for and identifies any anomalies in your project's issues database, such as conflicting dependencies, committed issue errors, and correct references between issue reporters and user profiles. You can run the sanity check to check for corruption or invalid entries in your issue database.
IssueZilla is a powerful tool for managing and tracking your project's development activities down to the fine-grained details. As with most tools, users develop inevitably develop shortcuts and tricks to compensate for particular aspects of the tool, or to tailor it to their specific needs. IssueZilla is no exception.
What follows is a sampling of several tricks that have proved particularly useful to project managers or users with administrative issue tracking permissions:
- Avoid configuring the same management-level queries repeatedly by creating permanently displayed links to information you use constantly. For example, you can create a page of links for each project member's issue list, and for regularly used milestone or issue status queries.
- Because issues may not be deleted, you can create components or subcomponents named "issue graveyard" or "unknown" to collect dead or no longer applicable issues. IssueZilla's non-delete feature is actually a protective design feature since the ability to track such dead issues can sometimes come in handy, or at least preserve aspects of project history.
- Create a "not determined" milestone for project issues not yet tied to any particular project milestone date or release. Development project objectives and priorities tend to shift dynamically. This lets you identify and hold in reserve those issues affected by your project's evolution.
- Add a pseudo user known as "placeholder" (or some other equally obvious generic identity) who can "own" issues that you are not yet ready or able to assign to specific project members.
Generating issues as XML
You can get an XML representation of any issue by editing the URL in the "Location" box to include xml.cgi or xmlupdate.cgi. Xml.cgi allows you to select the issues by issue id or a comma-separated list of issue ids. For example:
- To get issue 1 as XML, use the URL http://[project].[domain]/issues/xml.cgi?id=1
- To get issues 1, 2, and 3 as XML use the URL http://[project].[domain]/issues/xml.cgi?id=1%2C2%2C3. Note: because the list is URL encoded, commas must be entered as %2C.
Xmlupdate.cgi allows you to select issues by starting date ('ts'), and returns all the issues modified since that date. You can also use an optional ending date ('ts_end'). Dates are specified in the form YYYY-MM-DD HH:MM:SS, and can specify degrees of precision from month (YYYY-MM) to second (YYYY-MM-DD HH:MM:SS). For example:
- To get issues modified since February 1, 2001, use the URL http://[project].[domain]/issues/xmlupdate.cgi?ts=2001-02-01
- To get issues modified since 5pm Feb. 7, 2001, , use the URL http://[project].[domain]/issues/xmlupdate.cgi?ts=2001-02-07%2017. Note: because the date is URL encoded, spaces must be entered as %20.
- To get issues modified between Feb. 14 and Feb. 28 2001, use the URL http://[project].[domain]/issues/xmlupdate.cgi?ts=2001-02-14&ts_end=2001-02-28
IssueZilla in-lines any attachments to issues in the XML in base64 encoding. Both scripts take an optional argument - show_attachments=[true|false] - which can be used to suppress their inclusion. Attachment information will still be included in the XML, but the files themselves will not be. To get issue 1 without the associated attachments, use the URL http://[project].[domain]/issues/xml.cgi?id=1&show_attachments=false.