Permissions and Data Access

StatusPath Reports runs inside Jira Cloud. Report results depend on the Jira data that is available to the app and to the current Jira user.

Use this page to understand why two users may see different results, why some work items may be missing, and what configuration data the app may store.

How Jira permissions affect reports

Jira permissions are the first boundary for report data. If Jira does not return a project, work item, field, board, sprint, filter, or changelog entry to the current user, StatusPath Reports cannot include that data in the report.

This can affect:

• Project, Saved filter, JQL, Sprint, and Epic scopes.
• Work item fields shown in the table.
• Status and assignee history used for duration and count calculations.
• Dashboard Gadget results viewed by different dashboard users.
• Issue Activity results on a work item page.

Data the app reads from Jira

Depending on the module and report setup, the app may request Jira data such as:

• Work item keys, summaries, types, priorities, statuses, assignees, reporters, dates, and selected fields.
• Status and assignee changelog entries used for Time in Status, Time in Assignee, Status Count, Status Entry Date, and Transition Count reports.
• Project, Saved filter, board, sprint, and epic information used to build a work item scope.
• Jira status and workflow metadata used to label status columns and transitions.
• Single-work-item details, complete accessible changelog pages, and status-change actor details when a Journey is opened from a Report Center Average participating-work-item table.
• Jira users and fields used by Columns Manager and grouping controls.
• JQL validation results when a JQL scope is configured.
• Dashboard item properties used by the Dashboard Gadget.

The app should be treated as a reporting layer over Jira data. If Jira permissions, filters, or API responses exclude data, the report will reflect that boundary.

Data the app stores

The current implementation can store configuration data needed to make the app usable across sessions:

• Saved report presets and preset state.
• Recent or active unsaved report setup.
• Work calendars, business-hour rules, exceptions, and admin settings.
• Dashboard Gadget configuration.

Issue Activity reads site calendars and admin defaults and keeps the current selections while the module remains mounted. It does not persist a separate per-user Issue Activity preference set across fresh page loads.

Saved report presets store report configuration. They are not frozen copies of Jira result rows. Exported CSV or XLSX files are generated for the user action and are not stored as saved report data by the saved report feature.

Saved report visibility

Saved reports have an owner account id stored when created, but current resolver routes do not enforce complete owner-based isolation for list, update, or delete operations. Do not use saved reports as a privacy boundary unless your Jira site has verified the exact behavior you require.

Jira permissions still apply when a saved report is restored and run. A user may restore the same setup but receive different results if their Jira access differs.

App-level permission controls

The current code does not implement a separate project-level report access model for StatusPath Reports. Permission helper code exists, but report access enforcement is not currently implemented as a product permission layer.

Use Jira project permissions, issue security, filter sharing, dashboard sharing, and app installation controls as the authoritative access controls until a dedicated StatusPath Reports permission model is implemented and documented.

Issue drill-down permission and data boundary

Average Time in Status participating items are derived from the retained snapshot for the report result. The snapshot contains only the work items and grouping data available when that report ran; opening the list does not grant access to anything else.

Opening one participating work item’s journey is a separate operation. It requests that one work item’s current accessible details, complete accessible changelog, and workflow status metadata. A user can therefore see an item in the older snapshot but be unable to open its journey if issue security, project access, or changelog availability changed.

Status-change actor names and avatars depend on what Jira returns for the changelog and what the current user is allowed to see. A missing identity can be shown as Unknown user; the first timeline interval can show — because there is no preceding transition actor. Actor identifies the user recorded on a status change, not the current assignee.

The journey’s Report contribution comes from the report row. Status timeline and History path use full accessible status history up to report generation and do not apply the report’s Trim History range. See Issue drill-down and Work item status journey before comparing those two scopes.

Module notes

Main report page: The main report page runs the selected report against the configured work item scope. Missing work items are usually caused by scope, date range, Trim History, Jira permissions, or unavailable history.

Issue Activity: Issue Activity analyzes only the current work item. It depends on Jira providing the current work item context, work item details, and relevant changelog data used by its analysis reports.

Dashboard Gadget: Dashboard Gadget stores a compact report setup with the dashboard gadget and renders results in the dashboard tile. Different dashboard viewers may see different results if their Jira access differs.

Exports: Table export uses the current report configuration, columns, supported filters, sorting, Format, and Calendar. It does not grant access to work items the user cannot access in Jira.

Why a work item may be missing

Common reasons include:

• The selected Project, Saved filter, JQL, Sprint, or Epic does not include the work item.
• The Work item date range excludes it.
• Trim History removes the history needed by the selected report.
• The current user cannot view the work item in Jira.
• The current user can view the work item but cannot access enough fields or history for the selected report.
• The work item has no relevant status or assignee changes for the selected report.
• A dashboard viewer has different Jira permissions than the person who configured the gadget.

When in doubt, confirm that the work item is visible in Jira for the current user, then run a narrow main report scope for that work item or a small known set of work items.