Permissions settings: descriptions that match the checks, reassign control and JSM defaults
Description
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 and notifying 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
-
Reassign (Jira and Confluence): the change control is shown only when the server allows the change, per decision 1.
-
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.
-
-
Space permissions:
-
Jira list: "View space settings page: open the space's Approval Path page with its approvals, activity and definitions. Deleting, archiving and notifying there stay with space and Jira 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 and notifying there stay with space and Confluence administrators."; "Edit existing Approval definition" becomes "Edit or delete existing Approval definition". Stored groups are kept.
-
Jira permission scheme description of Edit approval definition (Forge manifest): "Ability to edit and delete existing approval definitions.".
-
-
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.
-
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 the permission scheme of each space."
-
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.
-
Decisions needed
-
Reassign rule. (a) Keep it: starter plus the view check above; hide the control where it fails. The AP-2487 texts stay. (b) Starter only, in every view where they can see the approval (the AP-2487 texts change too). Recommended: (a), today's server rule.
-
JSM default when nothing is saved. (a) Agents on, customers off: what the server and the JSM settings page give sites with saved permissions without the JSM fields; the portal panel then shows to agents on a fresh install and on those sites. (b) Both off, as the server and the JSM page treat a fresh install today: the portal panel is hidden until an admin turns access on in JSM settings, and agents on sites with saved permissions without the JSM fields lose the access the server gives them today. Recommended: (a), customers stay opt-in and agents keep the access the server gives existing sites.
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.
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: the portal panel either shows working content or is hidden, per decision 2, for agents and customers; the JSM settings page shows the same state.
-
Every text in Change 2, 3 and 5 is replaced; e2e page objects that match the old texts are updated.
Manual tester notes
-
Jira: turn on user step updates in General settings and work item permissions, start an approval with a user step (value change allowed) as a user with Start approval, then remove Start from that user and reload: the change control is gone. Repeat on the space page, with the space scheme on, as a non-admin starter with View space settings page.
-
Confluence: the same with page permissions and the Start new Approval Path group.
-
Jira: on a new site with JSM, open a portal request as an agent and as a customer before saving any setting. Repeat on a site whose stored permissions have no JSM fields (ask the developer to set them up).
-
Read every changed text in Jira and Confluence.