Problem

• The Web API v2 create request documents approval options: name, priority, decision deadline, reminders, abstain and approve current page version.

• Since the Bugcrowd fix in AP-1961 (January 2026) the Web API ignores them. The create request applies options only when canParametrize is set, and the Web API never sets it, so every Web API start takes the definition's settings.

• The UI applies the options only when the user may parametrize the approval and is not a JSM customer (ApprovalRestController: canParametrizeApproval(ctx) && !isJsmCustomer). With the app's work item or page permissions on, that means the Parametrize approval permission.

• AP-2380 first turned the options on for every non-JSM Web API start. The PR review pointed out that an API key with the "Change performer origin" privilege could then set options for a performer who cannot set them in the UI. AP-2380 keeps the old behaviour; this ticket applies the options with the same rule as the UI.

Change

• A Web API create applies the request's options only when the performer:

  • is not a JSM customer, and

  • may parametrize the approval on that work item or page, by the same rule as the UI's canParametrizeApproval (always allowed while the app's work item or page permissions are off).

• Otherwise the definition's settings are used, as today.

• Applied options stay limited to what the global and definition settings allow.

• The permission is read with the reference grants the Web API access check already loads:

  • Jira: the Parametrize approval key joins the bulk permission call of the access check. No extra call for keys with "Change performer origin"; one call for other keys, which skip that check today.

  • Confluence: the user's groups, through the existing 60 s cache, only when page permissions are on.

Decisions needed

1. A request that sets options for a performer without the permission: ignore the options (what the UI does with a crafted request), or refuse it? Recommended: ignore them, as the UI does, and name the ignored options in the response so an integration can tell.

2. The Web API does not check the performer's Start approval permission either; the UI does (canStartApproval). Check it in this ticket too? It changes behaviour for existing integrations: starts that work today would be refused.

3. Performers that are no active user (the app, a deactivated account, a document-based origin that resolves to nobody): options ignored. Recommended, matches "no permission".

Out of scope

• Rovo starts: they always take the definition's settings.

• JSM customer starts: unchanged, the definition's settings.

Acceptance criteria

• A non-JSM performer who may parametrize: name, priority, deadline, reminders, abstain and the page-version option from the request are applied, within the global and definition settings.

• A performer who may not: the definition's settings are used, and decision 1 is followed.

• A JSM customer start: the definition's settings.

• Work item or page permissions off: options are applied for every non-JSM performer.

• Jira keys with "Change performer origin" make no extra Atlassian call; other keys make at most one.

• The Web API schema (CreateApprovalRequest) says when the options apply; today it documents options the Web API ignores.

Manual tester notes

• On qa with the app's work item permissions on, create approvals through the Web API with a key whose performer has the Parametrize approval permission and with one whose performer lacks it. Compare name, priority, deadline and reminders with the request and with the definition.

• Repeat with a "Change performer origin" key for each performer origin (user chosen by the key owner, user from the API client, work item field, page creator, page last modifier).

• Repeat on Confluence with page permissions on.

• Start as a JSM customer: options ignored.

• With the app's permissions off: options applied for every non-JSM performer.