Scopes Justification

Below we explain why the app requires each of the permissions (scopes) declared in manifest.yml. The descriptions are concise and refer to real usage in the code and the available gadgets.

read:cmdb-object:jira

• Fetch Jira Service Management Assets objects to display custom asset columns on the portal layout.

manage:servicedesk-customer

• Fetch user organizations and system application roles to accurately verify scope access.
• Note: This scope is subject to change in the future to more granular alternatives (read:organization:jira-service-management and read:application-role:jira) as the app only retrieves organization and role details without modifying any customer data.

read:instance-configuration:jira

• Read the current user identity and active application role counts on the local instance.
• Process background license checking, validate subscription tiers, and load individual user settings.

read:jira-user

• Look up Jira users by their account ID to verify if a user belongs to the target instance.
• Identify the connected user within the secure OAuth authentication flow.

read:jira-work

• Search issues and retrieve available projects, custom fields, and statuses across environments.
• Power the core JQL function (accessibleRequests), handle daily cache refreshes, and feed the portal request display interface.

read:servicedesk-request (allowImpersonation: true)

• Fetch customer requests directly on behalf of portal users to aggregate cross-instance ticket data.
• Note: Impersonation is technically mandatory because unlicensed customers do not have a native Forge execution context.

storage:app

• Store global application configurations, encrypted secure OAuth tokens, synced request data, and system event logs.
• Keep temporary records within the Key-Value Store (KVS) and Object Store modules - all data, including logs, stays within Atlassian’s Forge infrastructure.