The goal is to mimic the functionality of the Bugzilla connector in MediaWiki, allowing dynamic Bugzilla queries to be displayed in situ within Confluence.
Earlier release of Bugzilla supported only older API technologies, namely XMLRPC and JSONRPC. In the Summer of 2013, Bugzilla moved to a separate proxy service called BzAPI that provided a REST API using data obtained through the older RPC interfaces as well as various other Bugzilla data sources, including CSV representations. All of these APIs are now deprecated. The release 5.0 of Bugzilla introduces a new native REST API.
Given the age of the MediaWiki Bugzilla connector, it is likely based on the older XMLRPC and JSONRPC calls. Since it is no longer under active maintenance (since the Summer of 2013 with the last major update from July of 2009), it is highly likely that the connector will break with an upgrade to Bugzilla 5.x
Competed to Date
The following work has been completed to date:
- Bugzilla 5.0.1 test server brought up and populated with dummy bugs
- Various API calls tested using the Firefox add-on, RESTClient
- Simple Confluence macros created to show the ease of linking and ability to make REST calls to Bugzilla
- Preferred methodology for processing REST API calls with Velocity user macros identified (can't be tested due to limitation in the current Confluence Velocity context (tools). See Preferred Methodology.
- Attempted to use workaround methods: Java methods, ALAX to replicate the preferred methodology – experiments proved unsuccessful.
The macro below has two links, one creates a standard URL to call a specific bug as specified by the user, the second returns the JSON data via the REST API. Both links open in a new window.
These links will only work if the Bugzilla test server is up. Call before testing.
If the Bugzilla server is down, and example of the JSON output is shown below.
Most or all of the functionality of the MediaWiki Bugzilla connector can be replicated using Confluence user macros. The most efficient way to make JSON calls is using the package JSONTool. JSONTool add special Java classes and methods that greatly simplify retrieving and working with JSON data (obviates needing to parse name/value pairs). For example, the following code snippet could be used to retrieve basic bug info where
Currently JSONTools are not available within Confluence. However, they can be made available via a simple plug-in using the Velocity Context Module. Development for this plug-in should be short.
This methodology can be used to interface to any other application with a REST API (currently the industry-standard API). For example, this link is a REST call to a movie/TV database: www.omdbapi.com/?t=Battlestar%20Galactica&y=&plot=short&r=json
Plugin Build Results
I attempted to build a plugin to add JSONtool to the Velocity context, but the plugin shows disabled within the Confluence test environment. Since many of the Confluence tutorials have not been updated in the last few years, and there have been major changes in the framework and database, I assume that the guide is out of date (probably not a common use model). I have an open case with Atlassian.
As a reference, K15t (makers of Scroll PDF Exporter), clearly think that what I am proposing is doable. They provide a reference for adding to their Velocity context within Confluence:
Back-up plan is to construct a streamreader in Java (installed as a plugin) to read the API calls to Bugzilla and write the return data out as Java objects. Once the results are Java objects, the output can be formatted using Velocity into any HTML structure we desire (formatted text, table, etc.).
The ConfiDoc plugin supports REST sources and services (in JSON, RSS, XML, and CSV formats) requiring various types of authentication: Basic; Pass-through Basic; NTLM; and other connections to Microsoft Cloud services (SharePoint). It is relatively inexpensive. It works similarly to the the ServiceRocket Reporting macro, meaning it uses nested macros to filter the data returned (which can sometimes be challenging to get to work).
Because of its similar structure to the Reporting macro, user macro wrappers can be easily created to make the process much easier on the end user (simple configuration screen) – i.e., users only need a bit of documentation in the config screen; don't have to learn the complexity of building the report. Also, it means that data can be filtered/parsed and then spit out into other HTML forms.
Ignore the column width difference below. Because of the Bugzilla API has a structurally different way (think different namespaces) of access comments versus the rest of the bug information, I had to use two macros. An issue that can be fixed wither with CSS or with a macro wrapper.