...
Can Dataplane report on issues created before it was installed or only on those issues created or modified after installation?
Arsenale Dataplane reports on the entire history of your Jira instance, providing a comprehensive analysis of even those issues created or modified before Dataplane Reports was installed.
When Dataplane Reports 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 Reports in realtime.
So with Dataplane you get the same detailed insight into past project and team performance and metrics as you have going forward.
How current is the data I'm viewing in Dataplane
...
Reports?
After Arsenale Dataplane Reports does an initial index, upon installation, of your Jira instance history, all subsequent changes in your Jira instance are then tracked by Dataplane Reports 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 reportsReports, whether those reports are viewed within Dataplane, on Jira dashboards, or in Confluence via a Dataplane Reports gadget.
Does Dataplane Reports modify Jira project or issue data?
No. All Jira project and issue data is treated as read-only by Arsenale Dataplane Reports.
For its performance-optimized reporting and storing of saved reports and other app user data and settings, Dataplane Reports creates and maintains its own separate database tables within the Jira database.
Is Dataplane Reports subject to the same 1000 issue export limit as the Jira Issue Navigator?
No. Dataplane Reports 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 Reports and has no effect on your export of issues from Dataplane.
With Dataplane Reports you can easily run reports on and export results containing tens of thousands of issues. Dataplane Reports'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 Reports' 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:
...
| Anchor | ||||
|---|---|---|---|---|
|
When using Dataplane Reports gadgets in Confluence, why am I getting an authentication prompt?
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:
...
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 using Dataplane Reports gadgets in Confluence, why am I getting a PermissionException error?
When viewing a Dataplane Reports gadget in Confluence, users may get a message such as the following, even though they are correctly logged into both Confluence and Jira:
...
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.
| Anchor | ||||
|---|---|---|---|---|
|
When using Dataplane Reports gadgets in Confluence, why am I getting HTTP 504 timeout errors?
This is caused by Confluence's short default By default, Confluence has a short timeout when making HTTP HHTP requests to Jira from a Confluence macro. The default timeout in Confluence 6+ . x and above 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.
| Info |
|---|
Confluence's Administration » General Configuration page has settings that would appear to change the applicable HTTP timeout, however due to Confluence bug CONFSERVER-51594 Confluence gadget macros ignore these settings. For more details, see this Atlassian Knowledge Base article. You must instead use the JVM parameters listed below. |
For you change the default settings in your instance.
How to change the timeout settings
- In your Confluence instance, click on the settings icon
. - In Configuration, select General Configuration.
- In Connection Timeouts, select Edit to adjust the settings.
If the problem persists, you need to edit the JVM system parameters for Confluence.
Editing the JVM parameter - Linux
- Go to
$JIRA_HOME/bin/setenv.sh - Edit the
CATALINA_OPTSvariable. For Confluence 6 and above, add the following parameter to
CATALINA_OPTS:-Datlassian.
...
HTTP.connection.timeout=60000For Confluence 5. x and below, add the following parameter to
CATALINA_OPTS:-Dhttp.socket.timeout=60000
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.
When using Dataplane gadgets in Confluence, why is the gadget blank or cannot be configured?
We are aware of two possibilities:
Long-Running Reports Cause Timeouts and Blank Gadgets in Confluence
When a Dataplane report takes a long time to generate, the Confluence gadget may appear to be loading for a few seconds but then stop and render as a blank gadget.
To fix this, adjust Confluence's default HTTP timeout as described above in When using Dataplane gadgets in Confluence, why am I getting HTTP 504 timeout errors?.
...
Gzip Compression Causes Issues and Blank Gadgets with Jira 5.1 to 6.2.4
If you are using Jira 5.1 through 6.2.4 inclusive, a Jira bug (JRA-29795) requires that you disable Jira's built-in gzip compression feature in order to use the Dataplane gadget in Confluence. Jira 5.0.x and Jira 6.2.5+ are not impacted.
Atlassian already recommends disabling gzip compression if you are using Jira behind an Apache httpd server with mod_proxy, and they indicate that you may actually experience a performance gain by turning it off.
To disable gzip compression, access the Jira administration panel and select System » General Configuration » Edit
For Windows installations, follow Atlassian's documentation on editing JVM system parameters.
If you're running Confluence Data Center, do ensure to add this parameter in all of your Confluence nodes.
| Info |
|---|
Confluence's Administration → General Configuration page has settings that would appear to change the applicable HTTP timeout, however, due to Confluence bug CONFSERVER-51594 Confluence gadget macros ignore these settings. For more details, see this Atlassian Knowledge Base article. You must instead use the JVM parameters listed below. |
When using Dataplane Reports gadgets in Confluence, why is the gadget blank or cannot be configured?
We are aware of two possibilities:
Long-Running Reports Cause Timeouts and Blank Gadgets in Confluence
When a Dataplane report takes a long time to generate, the Confluence gadget may appear to be loading for a few seconds but then stop and render as a blank gadget.
To fix this, adjust Confluence's default HTTP timeout as described above When using Dataplane gadgets in Confluence, why am I getting HTTP 504 timeout errors?.
| Anchor | ||||
|---|---|---|---|---|
|
Gzip Compression Causes Issues and Blank Gadgets with Jira 5.1 to 6.2.4
If you are using Jira 5.1 through 6.2.4 inclusive, a Jira bug (JRA-29795) requires that you disable Jira's built-in gzip compression feature to use the Dataplane gadget in Confluence. Jira 5.0.x and Jira 6.2.5+ are not impacted.
Atlassian already recommends disabling gzip compression if you are using Jira behind an Apache httpd server with mod_proxy, and they indicate that you may experience a performance gain by turning it off.
To disable gzip compression, access the Jira administration panel select System → General Configuration → Edit Configuration, and then disable the "Use gzip compression" feature. Failure to disable Jira's gzip compression will result in Dataplane gadgets failing to display in Confluence.
If you use Jira behind a web server proxy, you may still be able to leave gzip compression enabled on the proxy.
I'm still having problems with rendering Dataplane Reports gadgets in Confluence. Help!
Some customers have reported issues with the Application Links configuration when one application is configured to connect over regular HTTP, but the other application is configured to connect over HTTPS, and that this problem is not specific to Dataplane. Ensuring that both Confluence and Jira use the same protocol may make it easier to set up a working application link.
Jira Issue Fields
What Jira issue fields are supported by
...
Dataplane Reports?
Dataplane reports on a wide variety of Jira field types including:
- the majority of built-in Jira fields
- the majority of standard Jira custom fields
- custom fields from a number of several third-party apps including Elements Connect and ScriptRunner
- all other third-party custom fields that are "stattablestable" (have been implemented using the Jira CustomFieldStattable class)
...
The most common reason for this is, that after adding a new custom field to Jira that is supported by Arsenale Dataplane Reports, you must:
- click the "Sync Index" button on the Dataplane Administration page to inform Dataplane about the new field, and
- rebuild your Jira index so that the custom field is useable by Jira
...
- your custom field may not be in the list of Dataplane's Supported Jira Fields, including supported third-party app custom fields.
- your custom field may be supported by Dataplane, but not in the context in which you are trying to use it in a Dataplane report. For example, historical reports like the Issues Value by Date Report, support a different set of fields than reports based only on an issue's current field values, since not all Jira fields are indexed historically by Dataplane. Additionally, only numeric fields can be used in Dataplane report configuration options that require a numeric value, as with the Value option in the Sum Numeric Field by Date Report.
Calculations and Values
When reporting on time durations, are the calculated total, average, max, and min times adjusted for non-working hours?
No. All reports that include time duration statistics—such as the Closure Time Report, Time in Status Report, or the Sum Numeric Field Report—currently use a raw calculation of hours that makes no consideration for non-working hours.
...
- 21.25 hours in an Issues Work Log Table Report is exactly 21.25 hours of actual work completed, regardless of the time of day, weekend, or holiday
- in a Closure Time Report or Time from Status to Status Report, a display of 36 hours for the average transition time in a reporting interval means 36 hours on a regular 24-hour clock, or 1.5 calendar days, rather than 4.5 working days of 8 hours each.
Fonts
Why are Dataplane Reports charts displaying unreadable font characters for axis labels and values?
Under some circumstances, after installing a new Jira instance or upgrading an existing Jira instance, the font characters displayed on Dataplane chart axes and labels are unreadable.
Dataplane Reports assumes there is a font named "Dialog" installed and available to Java, or "LucidaSans" if on a MacOS server. These are default fonts that come with Java. The Java runtime may be unable to locate this font, or a mangled alternate version is overriding the default installed with Java. If you search your Jira server log file (logs/catalina.out) there may even be a mention of not finding this font.
...
What does Sync Index do and when is it necessary?
In order to To provide high performance historical reporting, Arsenale Dataplane Reports builds and maintains its own optimized index of every change made to the issues in your Jira instance. Once Dataplane's index is built—after initial installation, on upgrade, or after manually clicking the Build Index button in Dataplane Administration—all subsequent issue changes in your Jira instance are tracked by Dataplane in realtimereal time.
There are a couple unconventional situations, however, where Dataplane's index of the state of your Jira instance may not be completely up-to-date:
...
Under any of the above circumstances, the new issues or custom field will not be available within Dataplane until you click on the Sync Index button on the Dataplane Reports → Administration page→ Configuration page.
Sync Index tells Dataplane to re-synchronize its realtime indexing with the current state of your Jira instance, picking up any new custom fields or unconventionally created Jira issues. This incremental synchronization is very fast and should complete in under a minute on most instances.
| Anchor | ||||
|---|---|---|---|---|
|
...
feedback and support links in Dataplane Reports?
Arsenale Dataplane includes a number of links in the application to allow users to easily open a support ticket with Arsenale: to suggest new features or product improvements, to request help with a feature or report, or to file a Some Dataplane Reports pages display links to our support portal, enabling users and administrators to easily suggest new product features or improvements, request help, or report a possible bug.
If See our documentation on Disabling Feedback and Support Links if you wish to disable this feature, hiding all product feedback links in Arsenale Dataplane:
Scroll down until you find the listing for Arsenale Dataplane, and click on it to expand the add-on listing.
Click on the link labeled "xx of yy modules enabled" on the right-hand side of the listing. Then scroll down to see the list of individual components ("modules") of the Dataplane add-on.
Find the "Issue Collector Web Resources (issueCollectorWebResources)" module and click on the Disable button that appears when you hover your cursor over that module listing.
The feedback module is now disabled, and Arsenale Dataplane product feedback links are no longer visible to users.
...
No. Uninstalling Dataplane is perfectly safe, and does not delete any Dataplane user data or settings.
Dataplane user data and settings are stored in an app-specific set of Active Objects tables in the Jira database, which are left untouched when Dataplane is uninstalled. Upon reinstallation of Dataplane, all app user data and settings are available again within Dataplane.
Security
Is Dataplane vulnerable to CVE-2021-44228 Apache Log4j2 exploit ("Log4Shell")?
No. Dataplane is not vulnerable to CVE-2021-44228, which is based on an exploit of the Java log4j2 (v2.0+) library.
Dataplane does not use log4j2. For logging, Dataplane uses the log4j v1.2.17 API provided by Jira; but this log4j version is not vulnerable to CVE-2021-44228.
The Atlassian CVE-2021-44228 disclosure page details some specific circumstances in which a Jira instance, and apps like Dataplane that use Jira's log4j v1.2.17 API, could be exposed to a CVE-2021-44228-like exploit should Jira be configured in a non-default way by an instance administrator. Please review that page in detail to determine if it applies to your Jira configuration.
Licensing
...
Why is Dataplane no longer available upon expiration of my paid license maintenance period?
If you are running Dataplane 1.8 or lower, a bug in the Atlassian Add-On Manager (UPM) (UPM-4565) causes Jira to stop Dataplane from running upon license maintenance expiration, rather than letting you continue using Dataplane outside of your maintenance period (as your perpetual license allows). This also affects impacts users who are in the process of upgrading from Dataplane 1.8 or lower to a more recent release. We apologize for this inconvenience.
To resolve the issue while running Dataplane 1.8 or lower, you will need to:
1) Upgrade to Dataplane 1.9 or newer, and
2) Remove and reinstall your Dataplane license. This will correct the licensing condition immediately.
If you are already running Dataplane 1.9 or later, these special instructions do not apply and no action is needed.
To resolve the licensing bug, after upgrading to a new version of Dataplane, visit the Manage Add-ons section of Jira Administration:
...
Delete your license string so that the License key text box is empty, and click Update.
...
.
| Anchor | ||||
|---|---|---|---|---|
|
No. Uninstalling Dataplane Reports is perfectly safe, and does not delete any Dataplane Reports user data or settings.
Dataplane Reports user data and settings are stored in an app-specific set of Active Objects tables in the Jira database, which are left untouched when Dataplane Reports is uninstalled. Upon reinstallation of Dataplane Reports, all app user data and settings are available again within Dataplane.
Security
Is Dataplane Reports vulnerable to CVE-2021-44228 Apache Log4j2 exploit ("Log4Shell")?
No. Dataplane Reports is not vulnerable to CVE-2021-44228, which is based on an exploit of the Java log4j2 (v2.0+) library.
Dataplane Reports does not use log4j2. For logging, Dataplane uses the log4j v1.2.17 API provided by Jira; but this log4j version is not vulnerable to CVE-2021-44228.
The Atlassian CVE-2021-44228 disclosure page details some specific circumstances in which a Jira instance, and apps like Dataplane Reports that use Jira's log4j v1.2.17 API, could be exposed to a CVE-2021-44228-like exploit should Jira be configured in a non-default way by an instance administrator. Please review that page in detail to determine if it applies to your Jira configuration.