---
title: "FAQ"
canonical: "https://support.appfire.com/space/dataplane/455934408/FAQ"
format: markdown
---
> Macro (aura-html)
> ℹ️ **Migrating to Cloud?** Dataplane is Data Center only. [Dashboard Hub](https://marketplace.atlassian.com/apps/1223898/dashboard-hub-pro-charts-reports-time-in-status-for-jira?hosting=cloud&tab=overview&utm_source=AAN&utm_medium=appdocs&utm_campaign=dataplane-referral&utm_term=RDD) is our recommended Cloud replacement. It matches Dataplane's core reporting experience (interactive charts, JQL-based reports, scheduled sharing), plus built-in integrations and secure external sharing not available in Dataplane.
**Frequently asked questions**
## General
### Can Dataplane report on issues created before it was installed or only on those issues created or modified after installation?
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. Once the initial index is complete, Dataplane Reports tracks all subsequent changes in your Jira instance in real time.
So with Dataplane, you get the same detailed insight into past projects and team performance and metrics as you have going forward.
### How current is the data I'm viewing in Dataplane Reports?
After 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 real-time.
So all 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](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/644284660), or [in Confluence via a Dataplane Reports gadget](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455869933).
### Does Dataplane Reports modify Jira project or issue data?
No. All Jira project and issue data is treated as read-only by 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 independently 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](https://confluence.atlassian.com/display/JIRA/Using+the+Issue+Navigator), it refers to trying to do an [Excel export](https://confluence.atlassian.com/display/JIRA/Exporting+Search+Results+to+Microsoft+Excel) 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](https://confluence.atlassian.com/display/JIRAKB/Export+More+Than+1000+Results+to+Excel), but you should carefully monitor instance performance and memory usage in making any changes. Any changes made to Jira's export limit are independent of Dataplane Reports and have 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' [Issues Table Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455869776) 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' 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:
```
-Dcom.arsenalesystems.dataplane.query.result.limit=30000000
```
## > Macro (anchor)
Dashboard Gadgets
### 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](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455869933), users see a message similar to the following at the top of the gadget in Confluence:
> ℹ️ If you are a registered user, there can be more information available to you. You will need to log in and approve this gadget's access to your account. (Show Restricted URLs)
> ℹ️
> ℹ️ [Login & Approve]
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 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 approve the gadget continually or if performing one approval is too much, some alternate solutions are listed below.
#### Solution 1: Switch to Trusted Application authentication
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 **Outgoing Authentication**.
4. Click the **Trusted Applications** tab (or ensure that it is already selected), then click "Enable".
5. Click **Incoming Authentication**.
6. Click 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.
#### Solution 2: Diagnose and fix OAuth configuration
If you do not want 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 want to configure your web server 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, for example, 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 application. 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 in to **Confluence** as one of the users who are 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 in to **Jira** as the same user.
- Click 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 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:
> ℹ️ PermissionException: to access this feature, you need to log in.
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](https://confluence.atlassian.com/display/DOC/Confluence+Security+Advisory+2014-02-26))
- Jira 6.1.3 and below ([official Atlassian security advisory](https://confluence.atlassian.com/display/JIRA/JIRA+Security+Advisory+2014-02-26#JIRASecurityAdvisory2014-02-26-Issue3:Privilegeescalation))
If either your Confluence instance or your Jira instance falls into the above version range, you need to apply the official patches to **both** systems for the Trusted Applications link to work properly. For example, patching only Jira but not Confluence can lead to the above PermissionException errors, and, likely, 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.
### > Macro (anchor)
When using Dataplane Reports gadgets in Confluence, why am I getting HTTP 504 timeout errors?
By default, Confluence has only a 5-second timeout for HTTP requests made from Confluence to Jira. This timeout needs to be increased.
For Linux Confluence installations, open Confluence file `$CONFLUENCE_HOME/bin/setenv.sh` and add the following to the `CATALINA_OPTS` variable:
```
-Datlassian.HTTP.connection.timeout=60000
```
For Windows installations, follow[ Atlassian's documentation](https://confluence.atlassian.com/doc/configuring-system-properties-168002854.html) on editing Confluence JVM properties.
The units for this JVM setting are *milliseconds*, so the above change sets the HTTP timeout to 60 seconds (60,000 ms).
> ✅ If your longest-running reports require more time, adjust this value accordingly.
> ✅
> ✅ For multi-node Confluence instances, be sure to add this JVM property on **all Confluence nodes**.
> ⚠️ In Confluence, the Confluence **Administration** > **General Configuration** page has settings that would appear to change the HTTP timeout, but due to bug [CONFSERVER-51594](https://jira.atlassian.com/browse/CONFSERVER-51594), Confluence gadget macros ignore these settings. For more details, see [this Atlassian Knowledge Base article](https://confluence.atlassian.com/confkb/jira-issues-macros-timeout-in-confluence-after-5-seconds-987142819.html).
### When using Dataplane Reports gadgets in Confluence, why is the gadget blank or cannot be configured?
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 Reports gadgets in Confluence, why am I getting HTTP 504 timeout errors?](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455934408/FAQ#timeout).
### 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. This problem is not specific to Dataplane Reports. Ensuring that both Confluence and Jira use the same protocol can make it easier to set up a working app 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 [several third-party apps](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455968042), including [Jira Misc Custom Fields (JMCF)](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/1804763296), [ScriptRunner](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455902562), and [Elements Connect](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/456196130).
- all other third-party custom fields that are "stattble" (have been implemented using the Jira CustomFieldStattable class)
> 📝 For complete details, see the [Supported Jira Fields](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455968042) page.
### Why is my custom field not in the list of fields that can be reported on?
The most common reason for this is that after adding a new custom field to Jira that is supported by Dataplane Reports, you must:
1. Click the **Sync Index** button on the* Indexer* tab of **Dataplane Reports** > **Administration** > **Configuration **to inform Dataplane Reports about the new field.
2. Rebuild your Jira index so that the custom field is usable by Jira
> 📝 See also [What does Sync Index do and when is it necessary?](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455934408/FAQ#What-does-Sync-Index-do-and-when-is-it-necessary%3F)
Additional reasons the custom field may not be available in Dataplane Reports are:
1. Your custom field may not be in the list of [Supported Jira Fields](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455968042), including [supported third-party app custom fields](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455968042).
2. Your custom field may be supported by Dataplane Reports, but not in the context in which you are trying to use it in a report. For example, historical reports like the [Issues Value by Date Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455902372) 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 Reports. Additionally, only numeric fields can be used in report configuration options that require a numeric value, as with the Value option in the [Sum Numeric Field by Date Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455869802).
## 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](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455869297), [Time in Status Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455967412), or the [Sum Numeric Field Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455935189)—currently use a raw calculation of hours that makes no consideration for non-working hours.
For example:
- 21.25 hours in an [Issues Work Log Table Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455935175) is exactly 21.25 hours of actual work completed, regardless of the time of day, weekend, or holiday
- in a [Closure Time Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455869297) or [Time from Status to Status Report](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455902356), 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 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.
One of the following solutions should fix the problem:
#### Solution 1: For Linux Servers, the Font Cache is Corrupted and Must Be Reset
If running Jira on a Linux server, occasionally the Linux font cache is corrupted and must be reset. To do so:
1. Enter the following command on the server: `fc-cache -s`
2. Restart Jira
#### Solution 2: For Linux Servers, Install the Dejavu Font Packages
For Linux systems, some of Atlassian's Jira installer packages do not include the correct font families. To fix the problem:
1. Install the "yum" command on your Linux server if not already present
2. Enter the following commands on the server:
3. Restart Jira
#### Solution 3: Verify Java's Default Fonts are Installed
1. On your Jira server, copy the following code to a text file and name the file "ListFonts.java":
2. Compile the Java code using the following command: `javac ListFonts.java`
3. Run the code with the following command: `java ListFonts`
4. Review the output to make sure the font "Dialog" is installed for Java (or "LucidaSans" if on a MacOS server):
5. If the required font is not installed you’ll need to install that font. A reinstall of the Java JRE might be the most simple way.
6. Restart Jira
## Administration
### What does Sync Index do, and when is it necessary?
To provide high-performance historical reporting, 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 clicking the **Build Index** button on the *Indexer* tab of **Dataplane Reports** > **Administration** > **Configuration**—all subsequent issue changes in your Jira instance are tracked by Dataplane Reports in real time.
There are a couple of unconventional situations, however, where Dataplane Reports' index of the state of your Jira instance can not be completely up-to-date:
- If you've added issues to your Jira instance unconventionally, such as with the Jira Importers Plugin, a [third-party issue migration tool](https://confluence.atlassian.com/display/JIRA/Migrating+from+Other+Issue+Trackers), or a command-line interface
- If you've added a new custom field to your Jira instance
Under any of the above circumstances, the new issues or custom field will not be available within Dataplane Reports until you click the **Sync Index** button on the *Indexer* tab of **Dataplane Reports** > **Administration** > **Configuration**.
*Sync Index* tells Dataplane Reports to re-synchronize its real-time indexing with the current state of your Jira instance, picking up any new custom fields or unconventionally created Jira issues. This incremental synchronization is fast, typically completing in less than one minute.
### > Macro (anchor)
How do I disable the feedback and support links in Dataplane Reports?
Some Dataplane Reports pages display links to our [support portal](http://www.arsenalesystems.com/dataplane-support), enabling users and administrators to easily suggest new product features or improvements, request help, or report a possible bug.
See [Disabling Feedback and Support Links](https://appfire.atlassian.net/wiki/spaces/dataplane/pages/455967688/Activate+support+features#%5BinlineExtension%5DDisabling-Feedback-and-Support-Links) to disable this feature.
### > Macro (anchor)
Does uninstalling Dataplane Reports delete any app user data or settings?
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](https://developer.atlassian.com/server/framework/atlassian-sdk/active-objects/) in the Jira database, which are left untouched when Dataplane Reports is uninstalled. Upon reinstallation, all app user data and settings are available again within Dataplane Reports.
## 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](https://confluence.atlassian.com/security/multiple-products-security-advisory-log4j-vulnerable-to-remote-code-execution-cve-2021-44228-1103069934.html) 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 an instance administrator configure Jira in a non-default way. Please review that page in detail to determine if it applies to your Jira configuration.