Just found that recent versions of Bugzilla can link to TWiki:
Bugzilla Bug 102685: Link twiki names to a twiki installation in comments
DESCRIPTION:
This patch allows to support twiki names in the bugzilla installation.. This is quite usefull of you want to link bugs to twiki pages without including full URLs in your bugs...
AUTHOR(S):
This patch has been developed by Ludovic Dubost <ludovic@netvalue.com> and Erwan Arzur <erwan@netvalue.com> for the bugzilla and twiki installations at Netvalue.
--
AndreUlrich - 07 Mar 2004
I have just installed the
BugzillaQueryPlugin and find it works well. I did run into a minor problem while installing the plugin. After I unzipped the package I went to the new
BugzillaQueryPluginDev topic but an error was displayed:
ERROR!! Not possible to connect database!! at ../lib/TWiki/Plugins/BugzillaQueryPlugin.pm line 419.
This was because the plugin had not yet been configured to access the Bugzilla database, but I couldn't do the configuration because the topic would not display. Part of the patch I have attached makes a connection failure a little less fatal - it will just show an error next to any tags that cannot be processed.
The patch also adds a new setting: BUG_TEXT. If this variable is not set then %BGQ{12}% will be displayed as the full URL to the bug (as before), if BUG_TEXT is set then it will be displayed with its value prefixing the bug number(s).
--
MikeLees - 19 Mar 2004
Just installed and starting using the plugin. Nice one! Hit the same problem as Andre. Not a major problem though!
I was wondering if "header" support could be added, so that when you do access the db to produce a table, you can stick a header on the top to make it look tidy.
This would allow to me to do this sort of thing:
%BGQ{"4640,4659,4706,4771,4845,4856,4862" data="on" header="|Id|Summary|" format="|$bug_id|$short_desc|"}%
I look forward to your thoughts.
Thanks again.
--
PhilHoffer - 24 Mar 2004
Hello installed and works nicely.
Even though the queries with product does not work. I have correctly installed it, and all queries work, but if I set something like:
%BGQ{data="on" product="Datalink" format="|$product|$bug_id|$target_milestone|"}%
I get nothing!
Do you guys know which could be the problem here?
Hi,
I try the query in my TWiki (of course, with different product :-)) and everything works fine. I can only suggest:
- don't you have misspelled product name?? (for example DataLink)
- do you have Bugzilla in version 2.16 or higher?? (there is different database schema between 2.15 and 2.16 Bugzilla)
--
RichardBaar - 07 Jul 2004
I am running Bugzilla 2.16.6 and have exactly the same problem. What I found is that the
BugzillaQueryBlugin is looking searching on a product_id and component_id when the database contains a product field and a component field. Hence the plugin is finding nothing. To fix, simply comment out lines 323 and 324 from the plugin.
# ( $tvalue, $key ) = getField( "id", "products", "name", $tvalue, "product_id" ) if ( $key eq "product" );
# ( $tvalue, $key ) = getField( "id", "components", "name", $tvalue, "component_id" if ( $key eq "component" );
The commenting of the above two lines fixed it for me.
--
ChrisParsons - 09 Aug 2004
Also noticed, searching for anything with a space in it does not work. I was searching on component "My Component" but because everything is split into an array on spaces, it was searching for "MyComponent" instead. I stuck in a quick hack to get round this, got the script to replace spaces in "My Component" with "%20" before splitting into the array and then back to spaces when needed for the search.
--
StephenTicehurst - 17 Aug 2004
Has anyone tried searching on keyword? I tried this and everything came to a halt so I looked at the debug.txt file and noted the sql coming out of this plugin was grabbing data from the tables bugs, keyworddefs, and keywords.
This resulted in a result of 5000+ records (which was not expected). Looking at the code, I noticed the line $statement .= ", keyworddefs, keywords" if ( grep( /keyword/,
@keys
) ); .
I can not see why it is bringing in the keyworddefs and keywords tables and generating a very long and incorrect result - when keywords are included within the bugs table and so the inclusion of these extra tables are not needed.
Out of interest, I have edited the script to allow the keyword "likesearch=on" - when used it adds a % wildcard to the end of the search string and does a 'like' search instead of an '=' search. This has come useful as we have bugs with milestones of "1.1.1", "1.1.2" etc... and I would like a list of all "1.1.x" issues. I will at sometime tidy it up and upload it here if anyone interested.
--
StephenTicehurst - 20 Jul 2004
.zip checked into
CVSplugins:BugzillaQueryPlugin
--
WillNorris - 23 Nov 2004
I just uploaded a patch that fixes queries for target milestones (and other things) that have a space in them. Turns out every milestone we have has spaces, so this was a big problem.
--
DavidCaldwell - 25 Feb 2005
Is there a way to format a BDG statement that includes "OR" or "AND"? (e.g. %BGQ{data="on" version="1.1" OR target_milestone="1.1"}%
--
JimSchaefer - 25 Aug 2005
I've installed the plug and it works. Does anyone have a suggestion on how to protext the
BugzillaQueryPlugin.txt file (specifically the Bugzilla username/password in that file.)? I don't want anyone to be able to see the values.
--
DinahMcNutt - 06 Sep 2005
Hello guys have a problem similar
PhilHoffer.
If I set something using data="on" I received a message:
ERROR!! Not possible to connect database!! at ../lib/TWiki/Plugins/BugzillaQueryPlugin.pm line 410.
When I remove the BUGZILLA_DB_HOST i got nothing, i.e:
- test: %BGQ{data="on" bug_status="NEW, ASSIGNED, REOPENED"}%%BGQ{data="on" bug_status="NEW, ASSIGNED, REOPENED"}%
returnes for me:
test:
More inforamtions: I work with Bugzilla 2.18
Any help, please?
--
JorgeAndrade - 21 Oct 2005
DinahMcNutt,
I'm not sure how to do it in current release. You can show a topic only to defined users or groups in Dakar (next) release like that:
- Set ALLOWTOPICVIEW = TWikiAdminGroup
--
LauriVihman - 27 Oct 2005
The ALLOWTOPICVIEW setting works also with the current
TWikiRelease01Sep2004.
I do not recommend to view-restrict the
BugzillaQueryPlugin topic since the documentation and SHORTDESCRIPTION is no longer accessible. Better to store the credentials somewhere else.
--
PeterThoeny - 01 Nov 2005
Added a patch (tested on Cairo) to allow (when
data="on")
https://twiki.org/p/pub/Plugins/BugzillaQueryPluginDev/patch--longdescs
-
$bug_href returns direcct url to bug (similar to the BUG_TEXT patch, I think)
-
$longdescs in format -- full bug comment history
-
$q for "
-
$percent for %
--
MagnusLewisSmith - 06 Feb 2006
When doing the following query on TWiki Cairo with Bugzilla 2.16.2, I get the following result in the mysql logs:
Query
%BGQ{data="on" bug_status="ASSIGNED" product="Programmers" component="Survey"}%
Log Output
278 Connect bugs@localhost on bugs
278 Query SET AUTOCOMMIT=1
278 Query SELECT id FROM components WHERE name = 'Survey'
278 Quit
279 Connect bugs@localhost on bugs
279 Query SET AUTOCOMMIT=1
279 Query SELECT id FROM products WHERE name = 'Programmers'
279 Quit
277 Query SELECT * FROM bugs WHERE bugs.bug_status = 'ASSIGNED' AND bugs.component_id = '' AND bugs.product_id = ''
277 Quit
where the
debug.txt twiki log has this to say:
12 Mar 2006 - 05:45 - TWiki::Plugins::BugzillaQueryPlugin::initPlugin( Main.TWikiSetup ) is OK
It appears as if
handleBugzillaQuery isn't parsing correctly. Any thoughts?
--
IanTegebo - 12 Mar 2006
Ah, I think I've tracked down the problem; I'm using 2.16.2 which has database schema decidedly different than 2.17 and higher. Shame on me for using old versions.
--
IanTegebo - 12 Mar 2006
Looks like
ChrisParsons had (and solved) the same problem above. I was wondering if anyone was still interested in development.
Here's a list of what people have asked for:
- Add support for headers
- Fix the 2.16.x issues
- Add support for complex queries
- Protect BugzillaQueryPlugin.txt
- Allow settings to be put in TWiki.cfg
Along those lines, I was wondering if anyone had taken a look at using
Bugzilla's modules
themselves as a way of more easily implementing all features.
--
IanTegebo - 12 Mar 2006
I'd also like to add that the handling of %BGQ{"some number"}% should actually be %BGQ{data="on" bug_id="some number" format="$bug_id"}%.
--
IanTegebo - 20 Mar 2006
I am using the
BugzillaQueryPlugin already some time and it works very fine!
However today i think i have found a bug: using the 'product' and the 'component' gives problems, if there are component's in the bugzilla database with the same name.
The reason is, that the component_id for the SQL-Statement is just derived from the given component name, the product_id is ignored.
Workaround: use different component names for each product and everything works fine.
--
GernotBelger - 21 Apr 2006
I currently have two projects that are each using the wiki in different webs for their documentation. Each project uses its own Bugzilla server. The way the settings work, it seems like I can only configure this for one project or the other and not both. Is there a way the plugin setting can be set(or overrridden) in the
WebPreferences to each web could point to a different bugzilla server?
--
RickMach - 21 Jul 2006
We currently use the
BugzillaQueryPlugin for our department's TWiki.
It has turned out to be incredibly valuable.
We've written a patch that we use for our installation. I'm attaching
it to the document.
ChangeLog
- Add lots of comments, including a header with author and updater information.
- Alter examples to use the more benign
example.com
- Move database configurations into
LocalSite.cfg
- Clean up handling of default formats
- Allow whitespace in options
patch-BugzillaQueryPlugin.pm:
Patch for
LocalSite configurations and other misc changes
I also notice the
BugzillaQueryPlugin page has been abandoned since
November 2004 -- is there any hope of having a new release?
--
ChrisCowart - 29 Aug 2006
Chris, thanks for sharing your enhancements. The author stated a modification policy of
ContactAuthorFirst. However, as you noticed, the author is not active for a long time. I suggest to send
RichardBaar an e-mail asking if you can update the plugin topic, e.g. change it to a
PleaseFeelFreeToModify policy.
--
PeterThoeny - 30 Aug 2006
Is it possible to use the table generated by
BugzillaQueryPlugin with data=on as the table referenced by the
SpreadSheetPlugin? I'd love to be able to sum up the estimated time on a project, for instance. Or to count the number of P1 and P2 issues. Currently the
SpreadSheetPlugin does not seem to even notice the table generated by
BugzillaQueryPlugin. If there are no other tables on the page, it seems to reference nothing and if there is a table earlier than the generated table, the results are pulled from that table.
--
JohnPetrangelo - 19 Mar 2007
My problem was that
SpreadsheetPlugin was running before
BugzillaQueryPlugin. Fixed my plugin order and the problem went away.
--
JohnPetrangelo - 20 Mar 2007
Regarding
PeterThoeny's suggestion on 30 Aug 2006, I've sent
RichardBaar an email with the request; how long should we wait for a response?
--
IanTegebo - 21 Mar 2007
I just received a reply from
RichardBaar and he gave us the go ahead for changing the
ModificationPolicy to
PleaseFeelFreeToModify.
--
IanTegebo - 21 Mar 2007
Not sure if this is the right place to ask this question. I just intalled this plugin and it gives the error that it can't connect to bugzilla database. I've verified that all the values are correct. I'm not using https, just http for our bugzilla. Settings are as follows, please let me know if you've any suggestions for me to try :
-
- Set URL = http://bugzilla
- Set FORMAT = | $bug_id | $bug_severity | $priority | $bug_status | $resolution | $reporter | $product | $short_desc |
- Set SHORTDESCRIPTION = This plugin is useful to display links or data results from Bugzilla.
- Set SHOWBUGSCRIPT = show_bug.cgi
- Set BUGLISTSCRIPT = buglist.cgi
- Set BUGZILLA_DB_HOST = bugzilla
- Set BUGZILLA_DB_PORT = 3306
- Set BUGZILLA_DB_NAME = bugs
- Set BUGZILLA_USER = bugs
- Set BUGZILLA_PASSWD = 123xyz
- Set DEBUG = 0
--
RavinderPalSingh - 21 May 2007
You cannot access bugzilla because the
MySQL database where bugzilla enters the bugs, denies remote user access by default. To get this plugin to work with bugzilla, grant remote user access to the
MySQL database as follows:
1. Fire
MySQL in administrator mode and type the following commands at the
MySQL prompt (replace hostname with the IP address of your TWiki Host):
GRANT ALL ON bugs.* TO bugs@'hostname' IDENTIFIED BY 'bugs';
FLUSH PRIVILEGES;
2. Restart mysqld by typing:
service mysqld restart
You should be able to view the bugzilla bugs on TWiki now.
--
AlokNarula - 22 May 2007
Thanks Alok, I tried you suggestion but it din't help. I tried the command
GRANT ALL ON bugs.* TO
bugs@10PLEASENOSPAM.1.17.62 IDENTIFIED BY 'bugs'; FLUSH PRIVILEGES;
where 10.1.17.62 is the IP address of my BUGZILLA (not Wiki) server, but getting same error.
Please let me know if there are any other things to try.
thanks alot,
Ravinder
--
RavinderPalSingh - 24 May 2007
This has been resolved. I just had to give IP of my Wiki server and not Bugzilla server. thanks.
--
RavinderPalSingh - 14 Jun 2007
I created a new mysql user "bugs_guest" that only has select permission in mysql. I use that for this plugin since I don't like the thought of it mucking about in the actual bugs database.
I watched the apache2 error log while loading the
BugzillaQueryPlugin page. It seems the milestone= query is causing trouble.
(DBD::mysql::st execute failed: Unknown column 'bugs.milestone' in 'where clause')
I assume this is because I'm running bugzilla-3.0 and the schema has changed? I think
IanTegebo mentioned using the bugzilla API which sounds like a good idea although I'm not volunteering... For now I've put a note on our twiki saying milestones doesn't work.
--
RandyMelton - 06 Jul 2007
I am getting this error after installing this plugin.
TWiki detected an internal error - please check your TWiki logs and webserver logs for more information.
install_driver(mysql) failed: Can't locate DBDpath in @INC (@INC contains: path path-linux-thread-multi path path path . path-linux-thread-multi path path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path path path path path path path path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path-linux-thread-multi path path path path path path path)
Mine is RHEL 4 running on 64 bit maching
--
AnjaniKumar - 20 Jul 2007
Anjani: you need to install perl-DBD-MySQL and perl-DBI on your machine to get this plugin to work. The error log indicates that perl-DBD-MySQL is not installed.
--
AlokNarula - 20 Jul 2007
In
BugzillaQueryPlugin, most of the examples are ok, but the 4th one under Examples uses "bugstatus" instead of "bug_status".
Also, I think the
BugzillaQueryPlug text topic should have the example items disabled (e.g. with ! before the %BGQ, or something), so that they show up (for users to see as an example), but do not execute.
--
SusanCassidy - 29 Feb 2008
New version released, supports wildcards patterns and negation. Have fun!
--
SaschaVetter - 27 Aug 2008
Oh, I forgot to link my
HowToConnectTWikiToBugzillaAPI
for the developers, how wants to integrate the bugzilla API to BQP.
--
SaschaVetter - 28 Aug 2008
Found a small bug in handling of in the 1.04 release
%BGQ{"3,33,333" data="on" format="| $bug_id | $bug_severity | $priority | $resolution | $bug_status | $reporter | $short_desc | $lastdiffed |"}%
The following patch fixed the problem i our installation.
notes the missing ! on the second defined(... )
plan:/data2/www/wiki.dbc.dk/dbcwiki# diff -c /home/ja7/BugzillaQueryPlugin.pm lib/TWiki/Plugins/BugzillaQueryPlugin.pm
*** /home/ja7/BugzillaQueryPlugin.pm 2008-10-03 19:11:08.264637781 +0200
--- lib/TWiki/Plugins/BugzillaQueryPlugin.pm 2008-10-03 19:23:48.656637743 +0200
***************
*** 306,312 ****
$params{$1} = $2;
}
! if ( ( $anonymous ne "" ) && !defined( $params{"bug_id"} ) && defined( $params{"bug_id!"} ) ) {
$params{"bug_id"} = $anonymous;
}
--- 306,312 ----
$params{$1} = $2;
}
! if ( ( $anonymous ne "" ) && !defined( $params{"bug_id"} ) && !defined( $params{"bug_id!"} ) ) {
$params{"bug_id"} = $anonymous;
}
--
JacobPoulsen - 03 Oct 2008
The new 1.04 release by
SaschaVetter introduced some problems to those upgrading from 4.1.x.
There is a bug in the makeArray subroutine that strips spaces in between values for the query
e.g. %BGQ{data="on" bug_status="NEW, ASSIGNED, REOPENED" product="My Product"}%
The makeArray subroutine will strip the space in between "My" and "Product".
Use the patch at the bottom of the comment to fix this issue.
The handling of fields in the bugzilla query was also changed. In the 1.03 version there was a tighter mapping to the field names for the bugs table. In the 1.04 version the sql statement has been made into a JOIN and field names from the bugs table are conflicting with the products table.
Example: %BGQ{data="on" bug_status="NEW, ASSIGNED, REOPENED" product_id="2"}%
1.03 sql statement: SELECT * FROM bugs WHERE ( bugs.bug_status = 'NEW' OR bugs.bug_status = 'ASSIGNED' OR bugs.bug_status = 'REOPENED' ) AND
bugs.product_id = '2'
1.04 sql statement: SELECT * FROM bugs LEFT JOIN products ON bugs.product_id = products.id WHERE ( bugs.bug_status = 'NEW' OR bugs.bug_status = 'ASSIGNED' OR bugs.bug_status = 'REOPENED' ) AND
products.name = '2'
The code that creates the WHERE statement in 1.04 simply searches for the string 'products' in the key.
Patch to fix makeArray bug:
--- lib/TWiki/Plugins/BugzillaQueryPlugin.pm.orig 2008-11-06 09:55:51.000000000 -0800
+++ lib/TWiki/Plugins/BugzillaQueryPlugin.pm 2008-11-06 10:00:26.000000000 -0800
@@ -429,8 +429,13 @@
sub makeArray
{
my ( $str ) = @_;
- $str =~ s/\s//g;
- return split( /,/, $str );
+ my @arr;
+ @arr = split( /,/, $str );
+ foreach my $tmp ( @arr ) {
+ $tmp =~ s/^\s*(\S)\s*$/\1/; # remove any beginning or ending whitespace
+ }
+
+ return @arr;
}
sub addArray
--
HermanRadtke - 06 Nov 2008
I just wrote initial version of plugin that gets Testopia test cases
to TWiki. Should this functionality implement to
BugzillaQueryPlugin,
or make different plugin for Testopia?
Benefits for separate plugin are in my opinion, that all Bugzilla users are not using Testopia, and It might keep code cleaner if no additional parameters need to be introduced.
Concerns on the other hand is, that Plugins contains quite much same code, but that code might be almost the same in many plugins.
--
JuhoSaarinen - 2009-06-26