Configuring Dataplane

To configure Dataplane Reports, select Dataplane Reports → Administration from the top Jira navigation bar.

Then under the Dataplane Reports section in the left sidebar, select Configuration.

Dataplane Indexing

Building the History Index

Before you can run any reports in Dataplane Reports, you must build Dataplane Reports' history index. 

This is typically a one-time operation. Once the history index is built, Dataplane Reports updates the index in real-time to ensure that reports always use the most up-to-date data.

To build the history index, from the Dataplane Reports → Administration → Configuration page select the Indexer tab and click the Build Index button.

While the history index is being built, the Configuration page is actively updated with indexing progress.

When the index build has finished, the Configuration page will confirm successful completion, or display any errors encountered.

Indexing on Jira Data Center

When 459636781 for the first time, or when incorporating incremental changes to the index, Dataplane runs its indexing operations in a background task. In a multiple cluster Jira Data Center instance, this background indexing task runs on only one cluster node at any given time.

The cluster node Dataplane Reports is currently using for indexing is called the Indexer Node, and is displayed on the Indexer tab of the app administration Configuration page.

When the Dataplane Reports app is enabled—on Jira Data Center startup, or on installation of the app—Dataplane automatically selects a cluster node to use as its Indexer Node based on node availability. If the Indexer Node is removed from the Jira Data Center cluster, Dataplane Reports automatically selects a new Indexer Node on which to perform future indexing operations.

Synchronizing the History Index

Once the history index has been built, the Sync Index button allows you to request a manual synchronization of the Dataplane Reports index.

Performing a manual synchronization of the index is not required under normal operation, however there are a few situations where a Sync Index is necessary.

When Jira Issues are Created Unconventionally

Under normal circumstances, all issues that are created and updated in Jira are automatically included in the Dataplane index in real-time. However, if an issue is created unconventionally—such as by some versions of the Jira Issue Importer, or by a Groovy-based script that does not generate system events—the issue may not be added to Dataplane Reports' index, and performing a manual Sync Index may be required in order to see the issue in reports.

In addition, data for Jira issues created or edited while the Dataplane Reports app was disabled or uninstalled may not be visible in historical reports until a manual Sync Index is run.

When Adding or Renaming Custom Fields

After adding a new custom field to Jira or renaming an existing one, a Sync Index is required to make the field available in Dataplane.

With a scripted custom field from the Jira Misc Custom Fields app or ScriptRunner app, a single Sync Index when the field is first added/renamed is sufficient to allow Dataplane Reports to make use of the field. No additional Dataplane Sync Index operation is needed when modifying the field's underlying Groovy script, however—as is standard practice with scripted custom fields from these apps—you will need to reindex Jira itself after any changes to the underlying Groovy script.

Automatically Rebuilding the History Index

Each night at midnight (00:00) server time, Dataplane Reports runs a history index maintenance task. Among other functions, this task performs validity checks on the index data and optimizes index data storage.

If the nightly index maintenance task detects a critical, unrecoverable data error in the history index, Dataplane's history index is marked invalid and a full rebuild of the index is required. Until an administrator initiates a 459636781, Dataplane Reports will display an error message to all users and administrators of the app indicating that report results may be invalid until the history index is rebuilt.

The early morning timing of this index invalidation can mean many hours go by before the issue is discovered and a Dataplane administrator is able to kick off a full rebuild of the Dataplane history index.

To limit downtime in this situation, set the following JVM property in your Jira bin/setenv.sh file to have Dataplane Reports automatically begin rebuilding its history index should it encounter any critical, unrecoverable index data errors:

-Dcom.arsenalesystems.dataplane.indexer.autoRebuild=true

Removing the History Index

If you need to uninstall Dataplane Reports permanently, you can use the Remove Index button on the same Configuration tab to remove all existing Dataplane Reports index data from your Jira database. This will drop all of the tables that Dataplane Reports created to build an index. 

Configuring Permissions

Configuring Dataplane Access Permission

Permission to use Dataplane Reports is granted under App Permission on the Permissions tab of the Dataplane Reports → Administration → Configuration page.

By default, all users in the jira-administrators and jira-users groups are given access to Dataplane. The Dataplane Reports Jira menu item will be visible to groups in this permissions list.

In general, users who are not in any group in the permissions list will not see any Dataplane menus or be able to run reports directly through Dataplane. However, if an existing Dataplane user creates a report, shares it, and adds the resulting shared report to a Jira dashboard that is visible to other users, everyone who is able to see the dashboard will also be able to view the Dataplane report, even if those individuals do not otherwise have Dataplane privileges. This allows administrators to restrict report creation to a select group of users, but still to display read-only Dataplane reports to other users on dashboards and information radiators.

To give groups permission to use Dataplane Reports, type in the group names and click Add Groups.

To remove groups of users from the permissions list, select those groups and click on Remove Selected Groups.

Configuring Customizer Script Permission

Dataplane users can modify or extend the functionality of reports with sandboxed, Groovy-based Customizer Scripts.

By default, all users in the jira-users and jira-administrators groups are granted permission to use Customizer Scripts. If you wish to prevent some or all of these users from using Customizer Scripts, you may customize the list of groups under the Customizer Script Permission section on the Permissions tab of the Dataplane Reports → Administration → Configuration page.

In order to run a report that has a Customizer Script, either the user who created the report or the user who is currently accessing the report must have Customizer Script permission. This means that a small set of users may be given Customizer Script permission, who can then create a set of reports that can be shared with a larger set of users who do not have Customizer Script permission.

When running a report, the Customizer Script permission is checked in real time. For example, if a trusted user is given Customizer Script permission and saves a report with a Customizer Script, any other user in the system (even those without Customizer Script permission) will be able to run the report. However, if Customizer Script permission is later withdrawn from the user who saved the report, only those other users who have Customizer Script permission will be able to run the report (even if the saved report itself has not been changed).

Configuring Default Report Sharing

When saving a report, Dataplane allows users to make the resulting report available to other users, other groups, or everyone (including anonymous users, if your Jira permits anonymous access).

The Default Report Sharing setting on the Sharing tab of the Dataplane Reports → Administration → Configuration page allows you to define the default sharing options for newly-saved reports. 

When users create new reports from a report template, the report will inherit the default sharing options specified in this section. Unless the administrator has made a selection in this section, the default for newly-created reports is "Not shared".

The selections made here apply only to newly-created reports that are being saved for the first time with Save As. The sharing selections of any existing saved reports will not be modified. In addition, existing reports that are copied using the Save As feature will still inherit the sharing options of the original report, rather than the default options specified here.

For a description of the Not shared option, the Everyone option and the projects/groups control, please see the documentation for Saving Reports.