Permission scope details for Daily Standup Governance for Jira

Daily Standup Governance for Jira operates entirely within the Jira ecosystem and strictly follows Atlassian’s security and permission model.

The app:

• Uses Jira REST APIs only

• Executes all API calls in the context of the logged-in user

• Does not override Jira permissions

• Does not access data the user is not authorized to view

This page describes:

• Jira APIs used by the app

• Permission scopes requested

• Purpose of each API

• How data visibility is enforced

Permission Model

Daily Standup Governance for Jira uses the User-as-User execution model.

This means:

• All API calls are executed using the permissions of the currently logged-in user

• Jira enforces:

  • Project permissions

  • Issue-level security

  • Field-level visibility

  • Sprint and board visibility

The app does not use elevated “app-as-app” permissions.

Jira Permission Scopes Used

1. read:jira-work

Purpose
Allows the app to read Jira work data that the user already has access to.

Used for

• Reading issues on a board

• Fetching issue details (key, summary, status)

• Accessing issue changelogs

• Reading sprint and board information

• Reading issue links (dependencies)

• Reading priority, estimates, story points, and due dates

Security Consideration
This scope does not grant access beyond what the user can already see in Jira.

2. read:jira-user

Purpose
Allows the app to read basic user profile information.

Used for

• Displaying participant names in standups

• Calculating participation metrics

• Identifying facilitators and board members

Security Consideration
Only basic user identity data is accessed. No private or sensitive profile information is used.

3. write:jira-work (Limited Usage)

Purpose
Allows the app to write limited data back to Jira where explicitly required.

Used for

• Linking blockers to Jira issues (when user chooses to)

• Optional issue flagging or metadata updates (if enabled by admin)

Security Consideration

• Writes are always initiated by explicit user action

• No automatic or background issue updates are performed

• The app does not modify issue workflow, status, or fields silently

4. storage:app / storage:app-data

Purpose
Allows the app to store standup-related data within Atlassian Forge storage.

Used for

• Daily standup submissions

• Blocker records

• Participation indexes

• Sprint-level retrospective signals (derived data only)

Security Consideration

• Data is scoped by board and organization

• No Jira raw payloads or changelogs are stored

• Data retention policies are configurable by administrators

Jira APIs Used

Boards & Sprints

APIs

• Jira Agile Board API

• Jira Agile Sprint API

Used for

• Identifying boards enabled for standups

• Detecting active sprint

• Fetching sprint start and end dates

Permission Enforcement

• Only boards and sprints visible to the user are returned

Issues & Issue Search

APIs

• Jira Issue Search API (JQL-based)

• Jira Issue API

Used for

• Fetching issues in active sprint

• Identifying assigned and in-progress work

• Detecting carry-forward work

Permission Enforcement

• JQL results are filtered by Jira permissions automatically

Issue Changelog

APIs

• Jira Issue Changelog API

Used for

• Detecting delivery-impacting changes such as:

  • Story point changes

  • Estimate changes

  • Priority changes

  • Acceptance or completion criteria updates

  • Sprint assignment changes

  • Dependency changes

Permission Enforcement

• Only visible changelog entries are returned

• Restricted fields or issues are omitted by Jira

Worklogs & Development Information

APIs

• Jira Worklog API

• Jira Development Information API (read-only)

Used for

• Detecting meaningful activity for “What I did yesterday”

• Identifying commits and pull requests linked to issues

Permission Enforcement

• Only development data already visible to the user is accessed

How Permissions Are Honored (Examples)

Issue-Level Security

If an issue is restricted to a specific group:

• The issue does not appear in the app

• No partial data is shown

Field-Level Security

If a field (e.g., acceptance criteria) is hidden:

• Changes to that field are not detected

• The issue may still appear for other visible changes

Multi-Project Boards

If a board spans multiple projects:

• Only issues from projects the user can access are shown

This behavior is intentional and required for compliance.

What the App Does NOT Do

Daily Standup Governance for Jira explicitly does not:

• Bypass Jira permissions

• Access issues via admin context

• Store raw Jira issue payloads or changelogs

• Track individual performance or productivity

• Attribute changes to specific users

• Expose hidden or restricted fields

User Transparency

To ensure clarity, the app displays the following note where relevant: