Table of contents
...
| Info |
|---|
This section does not apply to Jira Cloud users due to the nature of Jira Cloud hosting. More information on the differences between cloud and server versions of the App can be found here. |
This section allows you to perform basic troubleshooting actions or (whenever required) extract information that you can later send to the Support Team.
If you've encountered any issues with the App and the problem persists after updating to the latest version, please contact our Support Team via our ServiceDesk, providing as many details describing the error as possible.
Please remember that the more details we have on the issue, the higher the chance that we will be able to help you resolve it in the first reply. We are always more than happy to receive screenshots showing the problem, preferably with highlighted areas where the problem occurs.
Along with the above, we need you to send us information on the version of Jira you are currently using, the version of our application (if you are not using the latest release) as well as the fine-grained logs.
Security and access
Only Jira administrators can access this page.
Click the "wrench" icon at the top right and select "Advanced" from the drop-down list. Next, go to the "Technical info" tab.
...
| Note |
|---|
The features for checking and clearing the cache are available under the App Configuration > Advanced > Plugin cache page. |
Feature | Description |
|---|---|
Download all locks data | Generate locks report to identify performance issues. |
Download all cluster lock data | Generate locks report to identify performance issues for Data Center clusters. |
Release all clusters locks | Release all locks on all Data Center clusters. In Jira Data Centre, some operations require a lock to be placed across all nodes for operations that should only be operated on one node at a time, for example, taking a backup of the index. Info: While releasing the locks might resolve the performance issues on your instance, this information must identify the root cause of the problem and do not release the locks before contacting the Support Team. |
Release current node cluster locks | Release the current node's cluster lock. |
Show Integrity checker | The integrity check is the process of comparing the current state of stored data and/or programs to a previously recorded state to detect any changes. |
Fix integrity checker errors | Fix the identified integrity errors. The most common problem resolved by fixing integrity errors is when the App revers date fields mapped as start/end dates once they are cleared. |
Lock logging | Enable/disable the lock logging. |
Maximum tasks to load | Specify the maximum number of tasks in each Box scope. There is no maximum limit. |
Synchronization time interval | System job checking and synchronizing changes made in Jira (a process known as partial-sync) are configurable. The allowed time interval is 1-10 seconds. |
Generate thread dumps | A log informing about the processes and threads currently running within the Java Virtual Machine. Used in solving support tickets, in particular, in diagnosing performance problems. |
Download Task Relations report |
Generate a zip file containing the report. The file is automatically downloaded to your computer.  state_versions.csv - history of changes of parent/child task relationships and/or dependencies |
...
product | Can statistic collection be deactivated? | ||
|---|---|---|---|
Jira Data Center | YES | ||
Jira Server | YES | Jira Cloud | NO |
| Anchor | ||||
|---|---|---|---|---|
|
...
This section allows you to perform basic troubleshooting actions or (whenever required) extract information that you can later send to the Support Team.
If you've encountered any issues with the App and the problem persists after updating to the latest version, please contact our Support Team via our ServiceDesk, providing as many details describing the error as possible.
Please remember that the more details we have on the issue, the higher the chance that we will be able to help you resolve it in the first reply. We are always more than happy to receive screenshots showing the problem, preferably with highlighted areas where the problem occurs.
Along with the above, we need you to send us information on the version of Jira you are currently using, the version of our application (if you are not using the latest release) as well as the Fine-grained Log.
Feature | Description |
|---|---|
Detailed logging | Three logging levels specify the amount of information that will be stored in our application's logs:
Info: Any information logged here may be crucial when investigating App's errors. Therefore when reproducing an error, always set it to a "Fine-grained" level. |
Support data | Send logs to our Support Team directly using the app or via our ServiceDesk. |
Logs button on App screens | Enable/disable the send and download logs button on error notifications. |
...
| Anchor | ||||
|---|---|---|---|---|
|
Synchronization
Technical user
Jira Cloud limitations
When BigPicture is hosted on Jira Cloud the technical user is created automatically and is then used by the app - the technical user defaults to the anonymoususer and can't be changed.
Jira Server/ Data Center
...
Technical
...
user
...
When the person responsible for a change cannot be put down as the person responsible, the selected technical user is listed as the user making changes to your tasks (instead of an anonymous user (Jira Server fallback user)).
For example, when a task change is committed from BigPicture to an integration instance (such as Jira) and the known user context fails due to lack of user permissions, then the same action is retried using the technical user (that typically should have higher permissions).
Changes made as a result of a scheduling cascade will be pushed out, even if the user doesn't have permissions for the tasks in cascade, as long as the user has the permissions for the first task that is moved
Changes made as a result of administrative actions (eg. changing the sub-scope sync field) will be pushed out, even if the user doesn't have permissions for all the tasks
Beyond these two cases, this change should not allow the user to commit any action that they weren't able to make before
Changes, where the user had permissions to edit the task but lost them between the permission check and the actual commit, will be pushed out
...
Jira Cloud limitations
When BigPicture is hosted on Jira Cloud the technical user is created automatically and is then used by the app - the technical user defaults to the anonymoususer but and can't be changed.
...
Scheduled synchronization
Jira does not always notify the BigPicture App about changes (for example, no events are triggered when a project is removed) - the scheduled synchronization mechanism assures that the scope of your work is always up to date.
...
Task grouping limit
Set a limit on how many tasks a box can handle to allow grouping. The maximum number is set to 50000 tasks.
...
Performance
Set the maximum number of tasks that a single Box can hold to limit BP's performance impact on your Jira instance. The default value is 100,000 tasks, and there is no maximum limit.
For more information, see our BigPicture Sizing Guide.
...
Jira Data Center
The Technical user drop-down feature provides more visibility into updates done by the App during auto-scheduling and field synchronization. You can create a user that will be used by the App (for example, "BigPicture") to easily know that the App itself was responsible for changes.
On Jira Data Center the technical user defaults to the anonymoususer but can be changed.
...