La page comporte des questions et des réponses de FAQ avec des liens appropriés.
The Bugs Dashboard currently works with both MySQL and PostGres versions of Bugzilla 2.18.x and 2.20 through 3.0. Please note that as-of v1.4.0, Bugs Dashboard no longer supports 2.18.x versions of Bugzilla. This is in keeping with Bugzilla’s desupport notice for that version.
You must provide an account which has the authority to edit bugs. This account will be used to perform updates to the priority and/or severity. If you wish to drill down into an issue, you must also have an active account in Bugzilla. You will be prompted to login when you choose to drill down.
In the configuration of Bugs Dashboard, you can specify projects and states which you wish to exclude from reporting in the Bugs Dashboard. Doing so can make it appear as if the counts do not agree with a search in Bugzilla. For example, if you exclude “RESOLVED” and “CLOSED” statuses in Bugs Dashboard, then do a count of “open” bugs in both it and Bugzilla, they may not agree. That’s most likely because Bugzilla considers the status “VERIFIED” to be a closed bug whereas the Bugs Dashboard was not configured to exclude that status.
You can use just the Portal view, but then you burn a lot of real estate for those metrics you can view via the Classic Dashboard. The real purpose of the Portal view is to allow you to extend the Bugs Dashboard by creating and adding your own portlets. You can modify the portlets.properties file to REMOVE the default portlets after you have added other portlets. This should provide you with the best of both worlds. Of course, you can leave the default portlets there and add your own as well. You’ll just need to scroll some more.
We have seen this behavior in Internet Explorer 7 when it is maximized to the full width of the screen. Interestingly, the solution is to minimize IE7 which will cause the columns to line up correctly. You can then manually expand it back out to the width of the screen - just do not use the maximize button in the window!
The Bugs Dashboard currently works with Bugzilla releases 2.18 through 3.0, both with MySQL and PostGres. We are currently working on interfacing to Scarab. If you are interested in this work effort or have another system you would like us to investigate, please drop us an e-mail!
You must ensure that you can connect to MySQL via TCP/IP. Simply using a command-line to test can be misleading as that uses a socket. For further information, see: http://dev.mysql.com/doc/refman/5.0/en/can-not-connect-to-server.html
Step 1: shoot the guy who packaged the zip! (Wait, that’s me! Don’t shoot!!) This is an artifact of testing and we apologize for the inconvenience. The log4j.properties file was still referring to the location on our hosted server. Please open the properties file at /bugs/WEB-INF/log4j.properties and look at line 1. It should say
log4j.rootLogger=fatal, R
Then change the path on line 5 to something like
./logs/out.log
If the logs directory isn’t one level up from your Tomcat binaries, please set the appropriate path. I promise not to make you do this again. Well, not on purpose anyway!
No! The license is written in such a way as to cover a host of different scenarios. One that we have contemplated offering is an Application Service Provider (ASP) model. Large development shops have their own servers, backups, staff, etc. Smaller development efforts (e.g. “garages” and home offices) may be more comfortable with web access to a service. Thus, that portion of the license would relate to their use. (If you’d like to use a hosted service, please contact us at sales@bugsdashboard.com.) Otherwise, the fees are quite simple: a one-time $19.95 for the developer (single user reporting access) license or $199.95 for the enterprise (reporting all bugs from an instance). Ongoing support, beyond the first 30-days, is also available should you wish.
You may need to set the MySQL property “max_connections” to zero (for unlimited connections) or to the same value you set the maxConnections property. On Windows, you can do this in your my.ini file.
MySQL has a default maximum packet size of 1M. If you are entering large reports (perhaps citing a source), you may need to increase the “max_allowed_packet” size in your my.ini file. If it doesn’t exist, add it to the .ini file and use a larger setting, e.g. 20M or 32M or as appropriate for your largest updates.
If you see something like the following:
java.lang.IllegalArgumentException: timeout value is negative java.lang.Object.wait(Native Method)
com.wmpnj.statusreports.components.ConnectionPool.getConn(ConnectionPool.java:191)
com.wmpnj.statusreports.components.ConnectionPool.getConn(ConnectionPool.java:206)
com.wmpnj.statusreports.components.ConnectionPool.getConnection(ConnectionPool.java:174)
com.wmpnj.statusreports.authentication.Login.doPost(Login.java:83)
com.wmpnj.statusreports.authentication.Login.doGet(Login.java:62)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
check your db_en_US.properties file. The most probable cause for this type of error is that you’ve mistyped some part of the jdbc URL. For example, if the database instance is incorrect, you’ll see the above error.
The calculation for the Outstanding page is to find bugs entered “less than” the current date minus any days you specify. If you wish to see bugs older than 30 days, you enter 30. That will give you bugs entered 31+ days ago. To see today’s bugs, enter a -1 for the days. (Current date - (-1) = tomorrow, meaning you’ll see all bugs older than 1 day from today or, in other words, all bugs including today’s.)
We have a forum for sharing portlets and those portlets WE post are free for your use. If others wish to develop significant portlets and charge for them, we’re happy to announce them and will let the market determine the best cost, etc.
Locate the portal.css file in the deployed css directory (e.g. /webapps/bugs/css). Open it with a text editor. You’ll see three columns defined as “#widget_col_0″, “#widget_col_1″, and “#widget_col_2″. Each of these have a “width” property. The defaults are: 30, 50 and 20% respectively. You may change the width of the columns by adjusting the “width” property of one or more columns. Now, locate the “page.css” file in the same directory. Open it with a text editor and find the same three widget_col entries. Change their width properties as well, saving both files. Changes to these files may necessitate a restart of your web application server.
You cannot increase the number of columns in v2.0, but you can decrease them, thus giving you larger columns if you wish. Locate the portal.css file in the deployed css directory (e.g. /webapps/bugs/css). Open it with a text editor. You’ll see three columns defined as “#widget_col_0″, “#widget_col_1″, and “#widget_col_2″. Each of these have a “width” property. The defaults are: 30, 50 and 20% respectively. Setting the width of #widget_col_2 to 0% will cause it to not appear on the portal. You should remember to not only increase the remaining columns, but also update the portal.properties file (i.e. /webapps/bugs/WEB-INF/classes/portal.properties) so that the portlets appear in the proper column of those that remain. You may also set #widget_col_1 to 0% if you wish to have only one large column on the portal. Now, locate the “page.css” file in the same directory. Open it with a text editor and find the same three widget_col entries. Change their width properties as well, saving both files. Changes to these files may necessitate a restart of your web application server.
When you drag your Issue over the empty container (as represented by an empty box), it will expand to incorporate your Issue. Simply drop the Issue while the container is expanded in the background.
We first check to see that the account provided in our configuration has the authority to edit issues in the issue tracking system you use. We then use that account to update the issue, setting the new priority. We also log an entry into the history file with your comments. Finally, we trigger an e- mail notifying the users configured in your issue tracking system of the change (assuming you have this configured properly.
We’ve noticed that after recent updates to Firefox, dragging and dropping bugs in both Priorities and Severities can seem a little sticky. That is, you click on the bug and drag it just fine, but when you release the mouse, the bug continues to follow you around. If this happens to you, double-click when releasing the mouse.
This is most likely due to the “bugURL” property not being set to match your installation of Bugzilla. Go to any bug in Bugzilla and note the url to display the bug. It will typically end in something like ?id=. Open your db_en_US.properties (or localized copy) file from /bugs/WEB-INF/classes and look for the bugURL property. Set the bugURL to be that which matches your installation of Bugzilla. For example, the default is /bugzilla/show_bug.cgi?id=, but one of our testing platforms would require this to be changed to: /bugzilla313/show_bug.cgi?id=.
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Plugin by Taragana | ||||||