Background

Extend the approvals list dashboard gadget (AP-626) with an optional mode where the gadget renders a single space with the configuring user's permissions, instead of the default per-viewer visibility. This lets an admin share a dashboard exposing a whole space's approvals to users who would otherwise see only their own. Depends on AP-626 (shares the presentation layer, configuration, and visibility model).

Owner-permissions mode

• Required permission: configuring owner-permissions mode is gated by a dedicated custom global permission defined by the app via Forge's jira:globalPermission module (e.g. "Configure shared Approval Path dashboards"), managed by Jira admins in the native global permissions UI and checked with has_global_permission. Default grant is restricted to jira-administrators. Two-layer model: the global permission gates whether a user may configure such gadgets at all, and the space-admin / global-admin check restricts configuration to the specific selected space. Holding the global permission alone does not let a user configure owner mode for a space they do not administer.

• Scope: exactly one space, optionally narrowed by a JQL filter within that space. Never multiple spaces or the whole instance.

• Who can configure it: only a user who, at configuration time, is admin of the selected space or a global admin. The configured owner identity (accountId) and the selected space are stored in the gadget instance configuration.

• Re-validation on every render: the backend re-checks that the configured owner still has admin rights to the configured space. If not, the gadget shows no approvals and a message that the configured owner no longer has access.

• Data vs. voting are independent: approvals shown are those visible under the owner's permissions for that space. Voting is never performed with the owner's permissions; a vote (approve / reject / abstain) is cast as the viewing user and only when that viewing user is themselves an approver of the step. Others see the approval read-only.

• No anonymous exposure: owner mode never renders approval data for an anonymous viewer (e.g. a publicly shared dashboard).

• Transparency: the gadget indicates that it is showing data shared with the configured owner's permissions, not the viewer's own.

Acceptance criteria

• Owner-permissions mode can be configured for a single space (optionally narrowed by JQL), only by a space admin of that space or a global admin at configuration time.

• Configuring owner-permissions mode requires the dedicated custom global permission (jira:globalPermission); users without it cannot enable the mode.

• The global permission gates the capability; the per-space admin check still restricts configuration to the selected space (holding the permission does not bypass the space-admin requirement).

• In owner-permissions mode, viewers see the configured space's approvals as permitted by the configured owner; on every render this re-validates that the owner still has admin access, otherwise no approvals are shown.

• In owner-permissions mode, a viewer can vote only on steps where they are themselves an approver; all other approvals are read-only.

• Owner-permissions mode never shows approval data to an anonymous viewer.

• The gadget clearly indicates when it is operating in owner-permissions mode.

Notes / open points

• Audit logging (server-side): record which space's approvals were rendered and under whose configured permissions, since data is shown beyond the viewer's own permissions. To be scoped.

• The jira:globalPermission module status should be verified as GA on the target platform version at implementation time.