FAQ

Arsenale Dataplane reports on the entire history of your Jira instance, providing a comprehensive analysis of even those issues created or modified before Dataplane was installed.

When Dataplane is first installed, it automatically indexes your entire Jira instance history including every issue creation, workflow transition, and field value change ever made. Once the initial index is complete, all subsequent changes in your Jira instance are tracked by Dataplane in realtime.

So with Dataplane you get the same detailed insight into past project and team performance and metrics as you have going forward.

After Arsenale Dataplane does an initial index, upon installation, of your Jira instance history, all subsequent changes in your Jira instance are then tracked by Dataplane in realtime.

So all Arsenale Dataplane reports reflect the most current state of your Jira issues.  There is no delay between Jira issue changes and those changes being reflected in Dataplane reports, whether those reports are viewed within Dataplane, on Jira dashboards, or in Confluence via a Dataplane gadget.

No. All Jira project and issue data is treated as read-only by Arsenale Dataplane.

For its performance-optimized reporting and storing of saved reports and other app user data and settings, Dataplane creates and maintains its own separate database tables within the Jira database.

No. Dataplane works completely independent of the Jira Issue Navigator and is not subject to this limitation.

If you have not yet run into this limitation in the Jira Issue Navigator, it refers to trying to do an Excel export of the results of a Jira search and being limited to a maximum of 1000 issues (rows) that can be exported at any one time. This can make it difficult to pull comprehensive Jira data into Excel for additional analysis. The limit built into the Jira Issue Navigator is due to potential performance and memory issues with larger exports.  You may increase this limit via a Jira configuration parameter but should carefully monitor instance performance and memory usage in making any changes. Any changes made to Jira's export limit is independent of Arsenale Dataplane and has no effect on your export of issues from Dataplane.

With Dataplane you can easily run reports on and export results containing tens of thousands of issues. Dataplane's Issues Table Report is an excellent substitute for viewing and exporting issues from the Jira Issue Navigator. 

Dataplane's report queries are run directly against the Jira database rather than Jira's internal issue cache.  So that Dataplane's database queries are not completely unbounded in result size, Dataplane places a soft limit on database query results of 20 million result items (20,000,000 rows x columns of data). While we expect this limit should be more than sufficient for the majority of Jira instances, if running a Dataplane report produces an error indicating this limit has been reached, you may tune the limit with the following JVM parameter:

On some systems, after you add a Dataplane report to a Confluence page, users see a message similar to the following at the top of the gadget in Confluence:

This message instructs users to confirm their identity to the Jira server. (The confirmation is performed using the industry-standard OAuth protocol.) When the user clicks "Login & Approve", they will be sent to the Jira server in order to confirm the connection, and they are then returned to Confluence to see the Dataplane report. This authentication prompt is a general feature of all Atlassian Gadget that require user authentication, so it is not specific to Dataplane.

In general, users should only have to perform this approval once. If users need to continually approve the gadget, or if even performing one approval is too much, some alternate solutions are listed below.

The easiest way to work around the problem is to configure the Application Link between the two applications to use Trusted Applications authentication. When Trusted Applications authentication is in use, authentication is automatic and users will never be asked to approve the gadget. To enable Trusted Applications:

1. In Jira, go to Toolgear » Add-ons » Application Links.

2. Find the Application Link corresponding to your Confluence server, then click "Edit".

3. Click on "Outgoing Authentication".

4. Click on the "Trusted Applications" tab (or ensure that it is already selected), then click "Enable".

5. Click on "Incoming Authentication".

6. Click on the "Trusted Applications" tab (or ensure that it is already selected), then click "Enable". You may need to scroll to the bottom of the dialog window to find the Enable button.

This procedure will enable Trusted Applications authentication for all gadgets, and the confirmation dialog should no longer appear.

If you do not wish to use (or cannot use) Trusted Applications for your Application Links, but you still receive the approval confirmation dialog more than once per user session, something is likely broken with your OAuth configuration.

Some of the following issues are known to cause problems with the OAuth confirmation:

• accessing Confluence (or Jira) with a URL other than the base URL configured in the application's configuration page. For example, if Jira is configured with a base URL of "http://jira.mycompany.com" but users typically access Jira using a shortcut of "http://jira", OAuth may not work properly. To correct this issue, ensure that the base URL is configured correctly in the Jira system configuration, and then ensure that all users are accessing it with that name. (If you run Jira behind a web server, you may wish to configure your web serfver to redirect all nonstandard URLs to the canonical URL.)

• configuring both Confluence and Jira on the same hostname, only differentiated by a context path or port. OAuth may not always work as desired if (say) your Confluence server is accessible at http://tools/confluence and Jira is accessible at http://tools/jira. Similarly, trying to access Jira as http://tools:8080 and trying to access Confluence as http://tools:8090 may also cause problems. In this scenario, consider creating different hostnames for each applications. (Both services can still continue to be run on the same physical or virtual machine, but they should be given their own distinct hostnames and URLs.)

One additional tool for investigating OAuth problems is the OAuth authentication tokens page in the user's profile. To access this tool:

• First, log onto Confluence as one of the users who is having authentication problems.

• Try to display pages containing Dataplane gadgets a few times. Make sure that you authenticate the gadgets more than once.

• Next, log into Jira as the same user.

• Click on the user profile icon in the top right corner and select "Profile".

• Click the "Tools" dropdown in the top right corner of the page, and select "View OAuth Access Tokens".

The subsequent OAuth Tokens page will show a list of all of the approved OAuth Access Tokens for the specified user. If you see a large number of tokens that were all approved at around the same time, you may need to go back and double-check the URL configurations.

When viewing a Dataplane gadget in Confluence, users may get a message such as the following, even though they are correctly logged into both Confluence and Jira:

This typically happens when using Application Links that are configured with Trusted Applications, but you are using incompatible versions of Jira and Confluence. In particular, Atlassian published a number of security advisories on 2014-02-26 that impact the following versions of Jira and Confluence:

• Confluence 5.4.1 and below (official Atlassian security advisory)

• Jira 6.1.3 and below (official Atlassian security advisory)

If either your Confluence instance or your Jira instance fall into the above version range, you need to apply the official patches to both systems in order for the Trusted Applications link to work properly. For example, patching only Jira but not Confluence can lead to the above PermissionException errors, and it is likely that other parts of the Application Link will not work correctly either.

If only one of your applications falls into the above version range, that application still must be patched, since the Application Links in later versions of Confluence and Jira are not compatible with earlier versions in the above range that do not have the patch.

This is caused by Confluence's short default timeout when making HTTP requests to Jira from a Confluence macro. The default timeout in Confluence 6+ is only 5 seconds, and in Confluence 5.x and below it is 15 seconds.

To solve the problem, edit the JVM system parameters for Confluence. For Linux installations, this is done by editing the CATALINA_OPTS variable in $JIRA_HOME/bin/setenv.sh. For Windows installations, follow Atlassian's documentation on editing JVM system parameters.

For Confluence 6 and above, add the following parameter to CATALINA_OPTS:

For Confluence 5.x and below, add the following parameter to CATALINA_OPTS:

Timeout parameter values are in milliseconds, so the above change sets the HTTP timeout to 60 seconds (60,000 ms). If your longest-running Dataplane reports require more time, adjust this value accordingly.