Hi – I’ve just released an update to the bugzilla reports extension for MediaWiki – see BugzillaReports @ MediaWiki. We use this internally and find it very useful for generating slice and dice reports of our activities. Feel free to give it a try and contact me if you have any questions.
UPDATE: You can report issues or raise enhancements @ http://code.google.com/p/bugzillareports/issues/list
Hi Ian – me again I’m afraid. I’m including the following argument:
|milestone=—
But am receiving this:
Warnings were generated during the execution of function
1. Special match not recognised target_milestone=—
Is there any workaround? I want a report to identify bugs for which the user hasn’t specified a milestone (and the default value is “—”)
Ian,
Greetings once again. I sure appreciate your extension. Thank you for the release *8 cache fix.
I am trying to use your extension in a template which receives a number of parameters when called. Unfortunately the parameters are not being expanded before being fed to BugzillaReports, so BugzillaReports does what is can with the literal strings {{{1}}}, {{{2}}}, etc rather than their values.
I read up on this a bit yesterday, the information I found (and very well may have mis-interpreted) suggested what I am trying to do — calling and extension from within a template — may not be possible. Is this suggestion hooey (technical term), or is it true? If hooey, can you explain how I need to represent/encapsulate the {{{1}}} parameter when calling BugzillaReports from within a template?
Thank you very much!
If I understand you correctly, that sounds a little strange. I use the #bugzilla function in templates with parameters in several place, e.g.
{{#bugzilla:product=live |keywords=headline |milestone={{{version}}} |depends=* |lastcomment=1 |heading=headlines |noresultsmessage= |columns=+to,+deadline,+modified,-version }}which is used in a template called “Product” and called by, e.g.
{{Product |summary=bemoko live platform |extends=bemoko Live |segment=service |version=1.2 |mobile=Yes |archive=No }}Is this the kind of thing you are trying to do?
Pete – on the “-” support. At the moment I use “-” to indicate null (or empty value). Unfortunately the logic that’s doing this is picking up “—”. I’ll fix this up in the next release.
Ian — I found my mistake. I had also embedded the BR query within tags for the ToggleDisplay extension… which messed up the parsing — thanks for writing back.
Hi Ian,
Your extension has been working perfectly since last summer. I decided to upgrade after it broke due to an issue that was fixed a later release. That issue is now fixed but I now see that the ‘modified’ column no longer displays the date as expected. I see either an empty field or 1-3 ‘+’ symbols. My template snippet is below:
{{#bugzilla:
|status=NEW,ASSIGNED,REOPENED
|to={{{Bugzilla Person Email}}}
|columns=id,modified,status,summary,product
|sort=id
|lastcomment=1
}}
Thanks
Dean
Dean, by default the modified is displayed in short hand (see http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports#Modified). If you want to display the date at is was before you should set the parameter “modifiedformat=date”,
Cheers, Ian
Hi Ian!
Thanks for the great extension!
We were wondering if it is possible to use it to take a “snapshot” of the state of the bugs in a specific page, as in: every week create a page with a report of open bugs, priorities, etc., so that if we look at a page from 4 or 5 months ago we will see how the bugs looked then.
I think I am looking for some way to “expand” the Wiki markup generated by the extension, and store that one in the database instead of the {{#bugzilla:…}} query that generated it.
Is there a way to do that???
Thanks!
Filipe
Hi Filipe – that’s a great idea. I’ll put it down on the list, but it does sound non-trivial. I looked around for other extensions that do something similar, but couldn’t find any. I’ll see what I can do on this front.
Cheers, Ian
Thanks Ian…another case of RTFM.
Hi Ian!
Thanks, that’s great news. It’s really a wonderful piece of software! I will let you know if I find an extension that does something similar, so that you can use the same mechanism.
Cheers,
Filipe
Hi,
I have a bug to report: custom field names do not work unless they are in a “column=+…” list.
For instance, this works:
{{#bugzilla:columns=id,priority,severity,to,summary|columns=+estimated:Est
While this does not:
{{#bugzilla:columns=id,priority,severity,to,summary,estimated:Est
I also upgraded from 0.9.5 to 0.9.9 and noticed that the estimated hours now show as a blank when they are zero. Is there any way to customize this behaviour? We were used to having zeros and liked the old way better…
Thanks!
Filipe
Filipe – I’ll take a look at that bug and sort it out.
On the estimated hours – thanks for the feedback and, sorry for the unexpected change from your point of view – it was done to reduce the amount of content in the report assuming that “0″ was not relevant for printing. I’ll create a configuration operation in the next release so we support both modes.
Thanks a lot, Ian!
Hi Ian,
One more. I couldn’t have my custom field shown in the results by only including it in the columns=… parameter. I looked at the code, and it seems that custom fields will only be considered if they are also in the filter=… parameter. I hacked it to add my specific custom field, by calling $this->addCustomField(“cf_notes”); in getSQL() of BugzillaQuery.php, just before the foreach($this->customFields as $column)…
I’m sure there would be a better way to detect the fields properly, so please have a look at that if you have some time for that.
I also could not change the header for the custom field, it is showing as cf_notes for me, while I would like to rename it to “Notes”. Using “cf_notes:Notes” did not work, but I guess that is the same I reported to you before about the “estimated:Est”.
Thanks!
Filipe
OK – I’ll take a look at improving that area of functionality.
Cheers, Ian
Hi Ian!
Man, sorry that I’m bugging you about so many things, but we love the extension so much that we are going to use it instead of Bugzilla itself for our weekly meetings…
One more thing we would like to do is to be able to style the bugs on the table based on severity (as Bugzilla does) instead of priority. We would like to mark “critical” bugs in red and “blocker” bugs in bold and red, the same as Bugzilla does. The problem is that that information is not stored in the CSS styles, so it is not possible to pick that up. Would it be possible to, when including the severity column in a search, include that information on the CSS style as well? That way it would be trivial to implement colors by using a custom CSS only.
Thanks one more time for the great software you created!!!
Cheers,
Filipe
No probs. It’s good to get some good feedback. I’ll need to start clearing the backlog and get the next version out. I’ll get those style rules in place for severity.
I’m going to be cutting the v1.0 release in the next week or so – I’ll finally be calling this “stable” since this extension is now extensively used and seems to be behaving itself. Currently I have the following fixed and going through test …
* Style class for severity set for the the tr element (row element) containing the bug details, so that (if you want) you can style based on severity. Style classes used are the exactly the same name as the severity value, e.g. “enhancement”, “normal”, “major”, etc
* Support for parameter “zeroasblank=false” to display numbers as “0″ if it is actually 0. The default setting is to hide 0s
* You can now set default parameters in the $wgBugzillaReports array defined in the LocalSettings.php for the whole wiki. This is great if you don’t like the defaults out-of-the-box and you want to override, e.g. ‘default’ => “debug=1|zeroasblank=false|lastcomment=1″. Note that if the parameter is set in the function call (i.e. on the wiki page) then this will override the default setting in the LocalSettings.php
* BUG : milestone=— matched as Special match. This is fixed so you can now filter on “—”
* BUG : Correct the help link
and the following outstanding (but expected to be done)
* “Couldn’t have my custom field shown in the results by only including it in the columns”
* “custom field names do not work unless they are in a “column=+…” list.”
If you have any requests for minor changes / fixes beyond those listed above, now is a good time to ask as they’ll get picked in my pre-release testing.
Hi Ian,
That’s great news! Congrats on seeing your baby reaching v1.0!
Count on me for any testing, whenever you have a snapshot that fixes the two outstanding at the end I can do the tests in my environment and tell you about them.
Cheers!
Filipe
Hi!
Bug report (v1.0): In the table header, Summary (N tasks), N is quite often equal to the number of rows in the table plus one.
Regards, Greger
Cheers Greger – I’ll take a look at that one in my next sweep up.
Is it possible to display bugs based on date? For example, only show bugs resolved in the past 7 days.
When I use Bugzilla search it uses:
chfieldfrom=-7d&chfieldto=Now
So I tried to use the filters which didn’t work:
filters=chfieldfrom%3D-7d%26chfieldto%3DNow
Is this possible? If so, what am I doing wrong?
You can use formats like +1w for deadline and modified to do relative date selection e.g.
deadline=+1w (anything with a deadline in less than a week), modified=-1m (anything modified in the last month), deadline=-5d:+5d (anything with deadline in the past 5 days or in the next 5 days)
So resolved/verified/closed in the last 7 days would be
{{#bugzilla:debug=1
|modified=-1w
|columns=+modified,status
|modifiedformat=date
|sort=modified
|order=desc
|status=resolved,verified,closed}}
Thank you Ian! Worked great. Love the extension!
The solution in #74 did not work for me. It seems to look for changes in any field and not just the status.
As far as I can see, the information about which specific field was changed at a certain time is in another table in the bugzilla database (bugs_activity).
Greger – yes you’re right that report does report on changes for any field – changes for a specific status change are not supported yet.
Ian
BugzillaReports now in google code repository and I welcome anyone to get involved in pushing this forward. If you find issues or want the extension to be better, faster and shinier – raise a ticket at http://code.google.com/p/bugzillareports/issues/list.
Cheers, Ian
I am trying to use the filters parameter on a custom field but it seems to only be able to do “=” comparisons.
Is there anyway to do a “!=” or “>” or “<” comparisons.
Sorry, but the filters parameter only supports “=” at this time. I’ve raised a ticket on this @ http://code.google.com/p/bugzillareports/issues/detail?id=16 to support “=”, “>” and “<“
We try to use the hardware (platform) field to filter bugs like this:
{{#bugzilla:
|component=XY
|hardware=windows
|severity=!P3
|status=NEW
}}
But we get a warning:
Warnings were generated during the execution of function
1. Setting parameter hardware is not supported
Do we use the wrong fieldname? We tried also:
“platform” and “rep_platform” (this is how bugzilla calls the field when i look at the field value page: “Select value for the ‘rep_platform’ field”)
but it didn’t work.
Is this field not supported yet?
We use bugzilla 3.0
Otherwise, thanks for the great tool
That parameter is not supported yet – I’ve added it to my task list @ http://code.google.com/p/bugzillareports/issues/detail?id=21
Thank you for the fast response! Looking forward to the new release
Hi Ian, its me again…
I like the feature to use wiki markup language in bugzilla comments. But if I use headlines (‘=’), my pages index renders them out, too.
I think the problem is clear to me, because the text is rendered to the html and is shown by java script onMouseOver (basically…). But WIKI Software creates the index out of h1-4 tags or so, and so it finds the headlines from the bug comment, too.
Is there an other solution beside not using headings in comments?
Thanks in advance, Volker
I’ll get the “=” supported under the task http://code.google.com/p/bugzillareports/issues/detail?id=22. I’ve got a little bit of a back log of tasks to sort out … I need to find a free evening to blast through a few.
Thank you for taking over my feedback
Ian,
Thanks for this very useful extension. Is there a way to report on bug creation date?
For example, I want to show bugs opened in the last 7 days by user or product, etc.
I’d also like to report bugs by specific status change (closed/resolved/reopened) in last 7 days. The only option I see is modified, which tracks any change.
Thanks.
Chris – sorry, I’ve not got this in place yet, it’s on the list @ http://code.google.com/p/bugzillareports/issues/detail?id=13
Thanks, Ian. Looking forward to seeing it.
Hi there
i have an Error with the extension
aus der Funktion „SearchMySQL::update“. MySQL meldete den Fehler „126: Incorrect key file for table ‘./wikidb/mw_searchindex.MYI’; try to repair it (localhost)“.
it apears while saving any Site!
MediaWiki 1.13.2
PHP 5.1.2 (apache2handler)
MySQL 5.0.26
Anyone Any Ideas?
Ok Sorry
i got the problem sloved by reparing the table!
cya Neppi
Hi, Ian
If I request for only one bug, it will not have column on the table.
i.e. {{#bugzilla:id=1}}
Thanks ^^
Column headers are automatically hidden when you explicitly set just one id. You can force the header to show with
{{#bugzilla:id=1|headers=show}}
Hi Ian,
I’m running the 1.1 beta, and thanks for the filtering feature.
Regarding issue #13 (filters on status change). Filtering appears to work properly on Created, Resolved, Verified, and Reopened. On Assigned and Closed, however, I get syntax errors.
Closed: {{#bugzilla:closed=2009-05-01:2009-05-31}}
Check for the right syntax to use near ‘and added=’CLOSED’ GROUP BY bug_id) as closedactivity on bugs.bug_id=closedactiv’ at line 1
Assigned causes essentially the same error, ending:
near ‘and added=’ASSIGNED’ GROUP BY bug_id) as assignedactivity on bugs.bug_id=assigne’ at line 1
chris – thx for the feedback – I’ve raised this issue at http://code.google.com/p/bugzillareports/issues/detail?id=31
Hi Ian,
Does 1.1 support reporting on status change + user (e.g., Verified btwn x and y by User1)?
Also, is there a way to report on custom flag status (e.g., give me all verified bugs on product X with myCustomFlag=+)?
Thanks.
Chris – BugzillaReports doesn’t support that functionality yet. Put it on the list at http://code.google.com/p/bugzillareports/issues/list and I’ll get around to it – Ian
Thanks, Ian. I’ll add it.
Ian,
I just setup your extension, it’s a pretty tool. I really appreciate your work!
From your release note, one new feature ‘created filters’ are added. ‘[#13] – Added support for created filters, e.g. {{#bugzilla:created=-1m|createdformat=date}}’. I’m not understand the syntax, what’s the meaning of ‘-1m’? I want to create one filter like ‘ all bugs opened during last 24 hours’ or ‘all bugs opened on 2009-10-28′, is it supported? Could you give me some sample? thanks very much!
I’ve added some extra documentation to cover date field filters here,
ian