Bugs Dashboard

How-to Configure

Estimated Time Required

10-20 minutes

Business Value

One time setup

Prerequisites

Process

1. Open the Bugs Dashboard directory in your Servlet container's deployment directory (e.g. webapps/bugs)
2. Open the WEB-INF sub-directory and the open the classes sub-directory (e.g. webapps/bugs/WEB-INF/classes)
3. There are four configuration files to edit. The Bugs Dashboard uses the current Locale to load the proper properties. If you are anything other than English (en), United States (US), then make a copy of each of the four property files and change them to the proper Locale, e.g. fr_CA for French, Canada.
   1. Edit the Bugs Dashboard "strings" (i.e. strings_en_US)
      1. If you are using the en_US Locale, you must set the title you wish to see in the header of each Bugs Dashboard page
      2. If you are installing Bugs Dashboard in a Locale other than en_US, copy the strings_en_US.properties file and rename appropriately, then edit each string.
   2. Edit the dashboard_en_US.properties file (or the copy you made for your Locale)
      1. If you have a large number of open issues in your repository, the Dashboard page can take a bit to open as it does all its counts. You can minimize this by turning off some of the features. For example, while it's nice to know what has occurred since your last visit (the "new bugs"), you could also get this information by using a date range on the Old Bugs page that is 0.
      2. set the five priorities you wish to display in the thermometers (usually P1, P2, etc. for Bugzilla and Hot, Medium, etc. for Scarab). If you changed the default priorities in your issue tracking system, set these values to the same as your database.
      3. set the URL to your issue tracking system, but do not include the actual id of a bug. The Bugs Dashboard will insert the id of the bug in the hyperlink using the URL you provide here. For Bugzilla, this would be something like /bugzilla/show_cgi?id=
      4. set the default for the number of days at which you wish to beginning tracking backwards on old issues that are not closed. This is provided because Bugs Dashboard will attempt to load all open issues that are at least this many days outstanding since opened. If you have a large number of issues in your repository and this is set to 0, Bugs Dashboard will first query the repository, load all open issues, then display this page.
   3. Edit the db_en_US.properties file (or the copy you made for your Locale)
      1. set the database type you are using. (Note: currently only MySQL is supported.)
      2. set the username you wish to log into the issue tracking system's database with.
      3. set the password for the above username
      4. set the JDBC URL for connecting to your issue tracking database. An example is provided in the default configuration. You should set the server (e.g. localhost), user (e.g. bugs) and password (e.g. wmpnj1) to match the appropriate values of your issue tracking installation.
   4. Edit the sql_queries_en_US.properties file (or the copy you made for your Locale)
      1. 1. set the name of your issue tracking system (Note: currently only Bugzilla is supported.)
         2. set the version number of your issue tracking system. Currently, this will be one of two values. Use 2.20 if you use any version 2.20 to 2.23.2. Use 2.23.3 for that version (Bugzilla enacted a schema change which affects the Bugs Dashboard in 2.23.3). Use 3.0 for the latest release, including 3.0rc1 and 3.0.
         3. set the excluded "states" you do not wish to see listed in the Bugs Dashboard. For example, your focus is generally on those issues still open. Thus, you would "exclude" any issue whose state is set to "RESOLVED" and/or "CLOSED".
         4. set any list of excluded projects as appropriate. Many customers use the same issue tracking system for multiple projects. If you do not wish to have your external group of customers and stakeholders viewing issues belonging to these other projects, exclude them here. If you must support two distinctly separate groups of customers from the same issue tracking system, make a copy of the bugs.war file in your deployment directory, rename it, set the configuration files appropriately there (to exclude the projects you include here) and pass out the different URL for managing those issues.
         5. set the login name which will be used to update issues when you set priorities and severities. This must be a valid user in your issue tracking system with the privilege to "editbugs".