Depends on (merged to dev first): AP-2487 (General settings step-update texts and the Start / Parametrize permission labels), AP-2450 (JSM settings page reads the stored permissions; permissions load error).

Problem

• Changing the user or email of a step (reassign) is allowed only to the user who started the approval, and only when they also pass a check that depends on the view they are in:

  • work item / page view: the Start approval (Jira) or Start new Approval Path (Confluence) permission when the app's permissions are on; everyone when they are off;

  • space view: space or global administrators only;

  • global view: global administrators or users with access to the work item / page.

  Jira: JSM agents in the portal always pass when JSM agent access is on. Since AP-2487 the General settings step-update texts name the Start permission, but not the space and global view rules; the Permissions page says nothing about it. Every starter sees the change control; those who fail the check get "No permission to reassign step."

• Jira, Permissions page, work item list:

  • it leaves out Notify approver and Archive approval, both checked on the work item (AP-2059, only on ap_qa, adds Archive approval);

  • the listed names ("Start new Approval", "Parametrize new Approval", "Delete existing Approval") are not the names admins find in the Jira permission scheme;

  • the default text AP-2059 adds says "To manage the path or submit decisions, users must have the Edit Issues permission". That is wrong: with the scheme off every user who can view the work item can do every action; Edit Issues only decides whether the app acts as the user or as itself.

• Jira and Confluence: "Manage Approvals in space" / "View space settings page" only opens the space page with its approvals, activity and definitions, where users can decide on steps assigned to them. Deleting, archiving, notifying and changing the user or email of steps there stay with space and global administrators. "Edit existing Approval definition" also allows deleting.

• Jira, JSM: the portal display conditions disagree with the server and the JSM settings page:

  • with nothing saved (every fresh install) the server and the JSM settings page treat JSM access as off, but the portal shows the Approval Path panel on requests to agents and customers: the panel stays empty and the portal menu item shows "Approval Path is not enabled for your account in this portal. Contact your administrator.";

  • with saved permissions without the JSM fields the server and the JSM settings page give agents access (the JSON default of JiraPermissions), but the portal hides the panel from agents.

Change

1. Reassign (Jira and Confluence): the change control is shown only when the server allows the change, per decision 1: on the work item / page to starters with the Start permission (every starter when the app's permissions are off), on the space page to starters who are space or global administrators, in the global view to every starter who sees the approval, and in the portal to JSM agents when JSM agent access is on.

2. Jira, work item permissions list, using the Jira permission scheme names:

   • "View approval path on work item page: see the Approval Path panel and decide on assigned steps"

   • "Start approval: start approvals, and change the user or email of steps in approvals you started"

   • "Parametrize approval: change the approval options when starting (needs Start approval)"

   • "Notify approver: email the approvers of the current step"

   • "Delete approval: delete approvals"

   • "Archive approval: archive approvals"

   The default text becomes "By default, all users who can view the work item can see the Approval Path panel and perform all approval actions on it." This replaces the dev texts and, if AP-2059 lands first, its Edit Issues text and Archive line the same way.

3. Space permissions:

   • Jira list: "View space settings page: open the space's Approval Path page with its approvals, activity and definitions. Deleting, archiving, notifying and changing the user or email of steps there stay with space and global administrators.", "Add approval definition: add definitions in the space", "Edit approval definition: edit and delete the space's definitions".

   • Confluence labels: "Manage Approvals in space" becomes "View Approval Path space page" with the tooltip "Open the space's Approval Path page with its approvals, activity and definitions. Deleting, archiving, notifying and changing the user or email of steps there stay with space and global administrators."; "Edit existing Approval definition" becomes "Edit or delete existing Approval definition". Stored groups are kept.

   • Jira and Confluence space defaults ("By default, all space or global administrators can view Approval Path space settings page and manage definitions." in Jira, "all space and global administrators" in Confluence) become "By default, all space and global administrators can view the Approval Path space page and manage definitions.", the name the space operation now uses.

   • Jira permission scheme description of Edit approval definition (Forge manifest): "Ability to edit and delete existing approval definitions.".

4. Jira, JSM: one default for "nothing saved" and "saved without the JSM fields", applied the same way by the portal display conditions, the server and the JSM settings page, per decision 2: agents on, customers off. The portal user menu item (Approvals and Activity) follows the same rule as the request panel: it shows to users with Jira Service Management access when agent access is on, and to other users only when customer access is on. Customers no longer see it, with "Approval Path is not enabled for your account in this portal.", when only agents have access.

5. Wording:

   • Jira: "The settings of this page work for both team-managed or company-managed spaces." becomes "These settings work for both team-managed and company-managed spaces."

   • Jira: "Note that enabling the toggles on this page will initially make the Approval Path sections not visible or read-only respectively." becomes "Turning on a scheme hides the Approval Path space page or work item panel from users who don't have the matching permission."

   • Jira: the flag after turning a scheme on, "Permission enabled. You can now configure who can access Approval Path workitem operations." ("space operations" for the space scheme), becomes "Permission enabled. Grant the Approval Path permissions in each space's permission settings."

   • Confluence: the error flag "Approval Path Page page permission scheme could not be changed…" becomes "Approval Path page permission scheme could not be changed. Try again later." (and "space" for the space scheme).

   • Confluence: the page default becomes "By default, all users who can view the page can view the Approval Path section and perform all approval actions on it."

   • Confluence: the default text is shown once per scheme (in the information message with Read more), not again under the toggle.

   • Jira: the work item default text and the "Enabling the toggle…" sentence after it are separated by a space (they ran together).

Decisions

1. Reassign rule: (a) keep it: starter plus the view check above; the control is hidden where it fails. The AP-2487 texts stay.

2. JSM default when nothing is saved: (a) agents on, customers off, as the server and the JSM settings page already gave sites with saved permissions without the JSM fields. Customers stay opt-in.

3. The portal user menu item is hidden from users without Jira Service Management access when customer access is off (Change 4).

Out of scope

• Web API Start and Parametrize checks: AP-2488.

• Two admins saving permissions at the same time can overwrite each other's change.

• Already done in AP-2450: a failed permissions load shows an error and nothing can be saved; the unused JSM customer toggle handling is gone.

• Existing behaviour, unchanged: with the work item scheme on, the portal request panel needs View approval path on work item page for customers, while the server and the portal menu item don't.

• Stored data, unchanged: sites whose stored permissions have agent access off keep it off. On some of them it was stored only as a side effect: saving another permission setting while nothing was saved also stored the earlier default, agents off. Admins turn it on with Show for Agents in JSM settings.

Acceptance criteria

• Per decision 1 (a): with work item / page permissions on, a starter without Start sees no change control on user and email steps; a starter with it can change them. In the space view the control shows only to starters who are space or global administrators.

• The Jira work item list names all six permissions exactly as the Jira permission scheme shows them, and the default text does not mention Edit Issues.

• Jira, fresh install and saved permissions without the JSM fields: agents see the portal request panel with its approvals and the portal menu item; customers see neither; the JSM settings page shows agents on, customers off.

• Customers don't see the portal menu item while customer access is off.

• Every text in Change 2, 3 and 5 is replaced; e2e page objects that match the old texts are updated.

Manual tester notes

Checked by the developer on a Jira Free site (no JSM, no editable permission schemes): the change control with the app's permissions off (work item, space page as an administrator, global view), and a change from the global view with the work item scheme on. The notes below cover the rest.

• Jira, paid site: in General settings turn on User steps and Email steps updates. Start an approval with a user step and an email step that allow changes, as a user with View approval path on work item page and Start approval.

  • Turn on the work item scheme. As that user, the change control (click on the step's user or email) works.

  • Remove Start approval from that user in the space's permission scheme and reload the work item: there is no change control on either step. The global Approvals view still offers it and the change saves.

  • Turn on the space scheme. As a non-admin starter with View space settings page, open the space's Approval Path page: no change control. As a space administrator: the control works.

• Confluence: the same with the page permission scheme and the Start new Approval Path group (a starter outside the group sees no change control on the page; a non-admin on the space page sees none).

• Jira, site with JSM, before any permission is saved (new site, or ask the developer to clear them):

  • As an agent, open a portal request with an approval: the Approval Path panel shows the approval, and the user menu has the Approval Path item with working content.

  • As a portal customer: no Approval Path panel and no Approval Path item in the user menu.

  • JSM settings: Show for Agents on, Show for Customers off.

• Jira, site with JSM whose stored permissions have no JSM fields (ask the developer to set them up): the same three checks give the same results.

• Jira, JSM settings: agents off and customers on: agents see neither the panel nor the menu item, customers see both. Both off: nobody sees them.

• Jira permission scheme: Approval Path's Edit approval definition reads "Ability to edit and delete existing approval definitions."

• Read every changed text on the Jira and Confluence Permissions pages (information message, list items, labels, tooltip, default texts, flags; in Confluence the default text is no longer repeated under the toggles).