Permissions, data and limits

What the app can access, where values are stored, and troubleshooting.

Permissions the app requests

Scope	Why it is needed
`read:jira-work`	Run the Issue Picker query, read field values, read field and project configuration.
`write:jira-work`	Store field values, create and remove the issue links the picker manages, and publish checklist progress for JQL.
`read:jira-user`	Resolve names and avatars for checklist assignees and picker columns.
`manage:jira-configuration`	Read and edit field contexts and select list options — the delegation feature.
`storage:app`	Store the app's own configuration.

The app declares no external network access at all. There is nothing outside Atlassian for it to call. It also does not declare report:personal-data, and that is not an omission — see below.

What is stored where

Almost everything belongs to Jira. The app's own storage holds a single value.

Data	Stored by	What that means
Field values: selected issues, checklist items, masked text	Jira	They follow the issue's permissions, exports, backups and deletion, like any other custom field.
Checklist progress values used by JQL	Jira	Stored as an issue property so Jira can search them.
Field configuration: the JQL query, checklist settings, mask patterns, custom statuses, default items	Jira	Held in the field's own context configuration, per context. It travels with the field, not with the app.
Which field contexts are delegated to project admins	The app	One key-value record, and the only thing the app stores. Deleted when the app is uninstalled.

Personal data: there is none

This app stores no Atlassian account ID anywhere, no display name, no email address and no user-generated content. The one record it keeps is a map of custom field ids to context ids — configuration identifiers, with no person attached.

That is why it declares no report:personal-data scope and runs no Personal Data Reporting cycle: an app that holds no account identifier has nothing to report and nothing to erase on a closed-account request. A checklist assignee or a picker column showing somebody's avatar is read from Jira when the field renders and thrown away; it is never written to the app's storage.

Note

The consequence for your privacy review: a subject access request against this app has no records to return, and a deletion request has nothing to delete. What holds a person's data is the issue, and that is Jira's to answer for. The privacy policy is the authoritative version.

Uninstalling

Uninstalling runs a handler that empties the app's storage — in practice, that one delegation record. It sweeps repeatedly until a pass finds nothing left, because deleting under a cursor leaves keys behind and “no more pages” is not the same statement as “the store is empty”. Independently, Atlassian detaches the installation's data and destroys it under its own retention policy; see Where your data goes.

This only became true recently

The handler existed for months wired to avi:forge:uninstalled:app, an event Forge does not publish, so it had never run once. It is a preUninstall module now, and it actually deletes.

Field values stay in Jira, because Jira owns them, but the app's field types stop rendering — so if you are removing the app from a production site, export the values you need to keep readable first.

Troubleshooting

The field does not appear on the issue: It is not on the screen. Add it in Settings → Issues → Screens, or through the field's own configuration.
The Issue Picker dropdown is empty: Run Test JQL. Usual causes: the query returns nothing, it is scoped to the wrong project, or Limit field options to current project is on and you are looking at an issue in a different project.
A user sees fewer issues than I do: Expected. The query runs with their permissions unless Use App Permissions is enabled.
The transition is not blocked: The Checklist Completion Validator is not on that transition, or the workflow was not published after you added it.
Checklist JQL returns nothing: Put the name in quotes: "Checklist-Progress" >= 80. Also, the values only exist for issues whose checklist has been saved at least once since the app was installed — and they stop being refreshed while the app has no active licence.
The mask let a bad value through: Check where it was typed. The mask is enforced where the app draws the editor — the issue view, create, transition screens and the portal. A bulk edit, the issue navigator or a REST write gets Jira's plain editor, which only enforces a length cap.
An option button says it needs a licence: The four option writes — add, edit, reorder, delete — are the only things in this app gated on the licence. Your fields and their values are unaffected.
The field behaves differently in two projects: Two contexts, two configurations. Check which context covers each project and issue type.

Still stuck? Open a ticket with the field name, the project key and what you expected to happen.