Release Notes

Enhancements

Audit Export — Filter by Issue List (BSOA-91)

• Audit CSV exports now support two filter modes: the existing Date Range mode, and a new Issue List mode that pulls the complete audit history for a specific set of issues, regardless of when their events occurred
• Supports a compliance sampling workflow: identify a set of issues (for example, everything closed in a given period) using Jira’s own search, then export the full audit evidence for just that list in one pass, instead of guessing a date range wide enough to catch every relevant event
• Accepts up to 50 issue keys per export

Audit Export — Integrity Verification (BSOA-90)

• Audit CSV exports can now include an automatic check that compares every audit record against a second, independently maintained copy that cannot be edited by any user, including administrators, through Jira’s own interface or APIs
• Detects and reports exactly which record was altered after it was first written and how, giving an administrator a specific, actionable starting point rather than a plain pass/fail result
• Included by default; can be turned off per export with an “Include Integrity Verification” option
• A record that was legitimately redacted to fulfill a privacy request is labeled as such, rather than reported as unexplained tampering
• Updated the Trust & Security page and Admin Guide to describe this capability

More Complete Audit Trail — Overall Status Changes (BSOA-92)

• The approval history now records a dedicated entry whenever an issue’s overall approval outcome changes, in either direction, including when an outcome moves out of Approval Passed or Approval Failed (for example, after an approver is removed from an already-approved issue). Previously, only the individual approver action was recorded, with nothing explaining the resulting change to the overall outcome
• These entries appear in the issue panel’s Audit History, in the tamper-evident compliance trail, and in the CSV export
• Overall-status entries in Audit History now display friendly labels (“Approval Passed”, “Awaiting Decisions”, etc.), matching every other surface that shows approval status

Bug Fixes

Custom UI — Momentary Raw Label Flash (BSOA-73)

• Fixed: Some admin and workflow configuration screens could briefly display raw internal label text instead of the real label for a moment after opening, most noticeable on a slower connection
• Affected screens now show correct labels from the first frame

Audit History Unreachable With No Current Approvers (BSOA-92)

• Fixed: The Audit History button disappeared from the issue panel whenever an issue had no current approvers, even if it had approval history, for example after every approver had been removed. This made past history unreachable from the panel
• The button now stays available whenever an issue has any history, regardless of its current approver list

Audit CSV Export — Ambiguous Empty Results (BSOA-92)

• Fixed: An audit export whose filter matched no records produced a CSV with a header row and nothing underneath, which could look like an error rather than a valid empty result
• The export now prints an explicit message stating that no records matched the selected criteria

Issue Panel — Redundant Refresh After Approver Actions (BSOA-98)

• Fixed: The issue panel could visibly refresh more than once after approving, adding, removing, or notifying an approver, causing a brief flicker
• The panel now refreshes once per action, as expected

Upgrade Notes

• No new OAuth scopes or permissions. The upgrade is silent on installed tenants, with no admin re-approval prompt
• No configuration changes required, and no saved setting values are altered
• One behavior change to be aware of. Issues with approval history now keep a visible Audit History button even after every approver has been removed, and new “Approval status changed” entries will begin appearing in Audit History whenever an overall outcome changes going forward. Both are visibility improvements to information the app already tracked, not new data being collected

Code Quality

• Consolidated three separately maintained internal copies of the audit-history write path into one shared function, so a future change to that path only needs to be made once
• Consolidated two internal lists of decision-related event types that had drifted out of sync, which had caused inconsistent output in one CSV export column
• Removed an internal panel helper with zero remaining callers that had twice caused raw internal label text to reach production, and corrected the internal engineering documentation that had prescribed it
• Added lightweight, Forge-native usage counters covering feature-level adoption (for example, how often approvals or exports are used). Counts only — no personal data, and nothing leaves Atlassian’s infrastructure, consistent with the app’s existing no-external-data-transfer design
• Routine dependency maintenance (in-range version updates only, no major version changes) reduced the number of open security advisories in development tooling; residual advisories trace to transitive dependencies of the Atlassian Forge SDK and are tracked for a future release

Test Coverage

• Backend and frontend test suites green; all checks pass: TypeScript (backend and frontend), ESLint, Prettier, Vitest, Forge manifest lint
• 1,859 backend and 184 frontend tests passing, with 85.6% overall code coverage (SonarQube)
• New unit and integration tests added covering the issue-list export mode, cross-trail integrity verification (including privacy-redaction labeling), the overall-status audit trail across every path that can change an approval outcome, the Custom UI translation fix, and the panel’s SoD-refresh signature logic
• SonarQube Quality Gate: Passed, with A ratings for security, reliability, and maintainability, and zero open bugs, vulnerabilities, or security hotspots
• Gitleaks secrets scan: clean across the full commit history
• npm audit: no advisories originate in application code. The remaining advisories are confined to development and build tooling that is not shipped, or are transitive dependencies of the Atlassian Forge SDK packages, and are tracked for resolution in a future release
• Manifest scope-change check confirms no new OAuth scopes or permissions are introduced in this release, so the upgrade is silent on installed tenants with no re-approval prompt

Security Improvements

Consistent Access Control on Admin Surfaces (BSOA-76, BSOA-81)

• The audit export tools (start, view, delete) now explicitly require Jira administrator permission, matching the admin page they live on
• Project search used by the audit export and admin audit log now carries the same administrator requirement as the surrounding page

Issue-Level Permission Verification (BSOA-77, BSOA-78, BSOA-79)

• Actions and lookups scoped to a specific issue now confirm the caller has permission to view that issue before returning any data
• Recording a decision now checks the Edit Issues permission at the issue level rather than the project level, which matters only for projects using issue-level security schemes
• Project selections passed to the dashboard gadgets and the audit export are now validated more strictly, so malformed input cannot widen the set of issues a request can return

Internal Safeguards (BSOA-80, BSOA-83)

• Corrected an internal permission cache that was not properly scoped per user, which could in rare cases apply one admin’s cached permission state to another user’s request
• Dashboard gadget configuration is now correctly isolated per widget placement, closing a rare case where two placements of the same gadget on different dashboards could share a configuration

CSV Export — Formula Injection Protection (BSOA-82)

• Audit CSV exports now neutralize characters that Excel, Google Sheets, and LibreOffice can otherwise interpret as the start of a formula, protecting anyone who opens an exported file

Enhancements

Reduced Data in the My Approval Queue Gadget (BSOA-84)

• The My Approval Queue dashboard gadget now sends a shorter issue summary (50 characters) from the server, rather than truncating only for display. This reduces the data included in the gadget’s response as a general data-minimization improvement

Clearer Audit Trail Documentation (BSOA-85)

• Updated the wording describing the audit trail’s SHA-256 hash chain across the Admin Guide, End User License Agreement, Data Processing Addendum, and Privacy Policy to describe what it actually does: detect accidental corruption or casual editing of historical records. Previous wording describing the trail as “immutable” or “tamper-evident” overstated what a hash chain alone guarantees, since the underlying Jira issue properties can still be edited by any user with Edit Issues permission
• The Trust & Security page is now the single canonical description of how record integrity works; the legal documents point to it rather than restating the mechanism independently

Bug Fixes

Audit CSV Export — Non-English Content (BSOA-87)

• Fixed: An audit CSV export could permanently fail, with no way to retry successfully, whenever the exported content included a large amount of non-English text (for example, Japanese, Cyrillic, or other non-Latin scripts) in an issue summary or approval comment
• Exports with non-English content now complete normally; exports of purely English/ASCII content are unaffected

Decision Recording — Invalid Status Values (BSOA-86)

• Fixed: Recording an approval decision did not validate the decision value itself, so a malformed request could write an unrecognized status into the audit trail and understate an issue’s approval percentage
• Decision values are now validated before they are recorded; a malformed request is now rejected with a clear error instead of being written

Upgrade Notes

• No new OAuth scopes or permissions. The upgrade is silent on installed tenants, with no admin re-approval prompt
• No configuration changes required, and no saved setting values are altered
• One behavior change to be aware of. The audit CSV export is now restricted to Jira administrators. This was always the intended access level given the feature’s placement on the admin page: anyone who was not a Jira administrator should not have been able to reach it, and this closes that gap

Code Quality

• Added a shared issue-visibility permission check used across every resolver that returns issue-scoped data, so browse-permission enforcement cannot drift between call sites (BSOA-78)
• Consolidated project, group, and role lookups behind access rules that match each endpoint’s actual consumer: administrator-only where the caller is an admin tool, filtered to the caller’s own access where the caller is configuring a personal dashboard gadget (BSOA-81)
• Replaced the audit CSV export’s character-count chunk sizing with a byte-budget algorithm that matches Forge Storage’s own size validation exactly, closing a class of Unicode-related export failures by construction rather than by widening a safety margin (BSOA-87)

Test Coverage

• Backend + frontend test suites green; all checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• 1,719 backend and 173 frontend tests passing, with 84.6% code coverage
• New unit tests added covering permission checks on every hardened resolver, CSV formula-injection escaping, dashboard gadget configuration isolation, decision-status validation, and Unicode-safe audit export chunking
• SonarQube Quality Gate: Passed, with A ratings for security, reliability, and maintainability, and zero open bugs, vulnerabilities, or security hotspots
• Gitleaks secrets scan: clean across the full commit history
• npm audit: no advisories originate in application code. The remaining advisories are confined to development and build tooling that is not shipped, or are transitive dependencies of the Atlassian Forge SDK packages, and are tracked for resolution in a future release
• Manifest scope-change check confirms no new OAuth scopes or permissions are introduced in this release, so the upgrade is silent on installed tenants with no re-approval prompt

Enhancements

Add Several Approvers at Once (BSOA-63)

• The panel’s Add Approver dialog now accepts multiple people in a single action. Search, select everyone you need, and add them together, instead of repeating the dialog once per approver
• A selection that partly fails no longer clears. The dialog stays open with your choices intact, and tells you who was not added

Clearer Approval Status When Someone Returns (BSOA-67)

• Where an approval can still reach its threshold, the status now reads Awaiting Decisions rather than Approval Failed. Previously a single return marked the approval as failed even when the remaining approvers could still carry it over the line
• This only affects projects using a threshold below 100%. At the default 100% threshold, one return does settle the outcome, and behavior is unchanged
• The Audit History panel now shows a Max Possible figure alongside the overall status whenever an approver has returned, so it is clear whether the threshold is still reachable and why an approval has failed

Approver Changes by Workflow Now Notify Consistently (BSOA-68)

• When a workflow post-function removes an approver and that changes the overall outcome, the reporter and assignee are now emailed, following the Email Reporter on Approval Outcome and Email Assignee on Approval Outcome project settings. Previously those emails were sent only when the same change was made from the issue panel
• Each setting is honored independently, so a project can notify one party and not the other

More Complete Approval History (BSOA-68)

• When an approver is removed, the history now records what that approver had decided at the time. An approval discarded by a removal is visible in the trail and in the CSV export, rather than leaving the removal unexplained
• Removals recorded from the issue panel and from a workflow post-function now read identically, apart from who performed them

Panel Messages Explain Refusals (BSOA-69)

• When the app declines an approver change, the panel now states the reason. For example, approvers cannot be changed once an issue reaches a Done status, and the dialog now says so
• Messages no longer suggest trying again when repeating the action cannot succeed

Bug Fixes

Duplicate Outcome Emails (BSOA-67)

• Fixed: The reporter and assignee received a repeated “Approval Failed” or “Approval Passed” email each time a further decision was recorded on an issue that had already reached its outcome. One email is now sent when the outcome is reached, and again only if the outcome genuinely changes

Approval History After a Partial Failure (BSOA-64)

• Fixed: When notifying approvers partly succeeded, no record was written at all, so the trail was silent about notifications that had in fact been sent. The history now records the approvers who were successfully notified

Upgrade Notes

• No new OAuth scopes or permissions. The upgrade is silent on installed tenants, with no admin re-approval prompt
• No configuration changes required, and no saved setting values are altered
• Two behavior changes to be aware of. Projects using an approval threshold below 100% will see fewer approvals marked as failed, because an approval that can still pass is now reported as awaiting decisions. And a workflow post-function that removes an approver may now send outcome emails to the reporter and assignee, where previously it sent none. Both follow your existing project notification settings, which can be changed in Project Settings → Business Sign-off

Code Quality

• Consolidated the separate add, notify and remove approver paths into single shared operations, so an action taken from the issue panel and the same action taken by a workflow post-function can no longer drift apart in what they record or who they notify (BSOA-63, BSOA-64, BSOA-68)
• Reduced repeated role and group membership lookups when a workflow resets or filters approvers on issues with many approvers, so those transitions complete faster (BSOA-64, BSOA-68)
• Reduced the storage and Jira calls made when approvers are removed, from one set per approver to one set per operation (BSOA-68)
• Consolidated the panel’s error handling into a single shared mapping, so the three dialogs cannot disagree about what a given failure means (BSOA-69)

Test Coverage

• Backend + frontend test suites green; all checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• 1,612 backend and 169 frontend tests passing, with 83.7% code coverage
• New unit tests added covering approval-threshold reachability, outcome-notification gating, the consolidated add, notify and remove operations, and the panel’s error messages
• A full manual verification pass was run on a staging site for the approver-removal and panel-message changes, covering the issue panel, all workflow post-function modes, email delivery, custom field and JQL updates, and the audit CSV export
• SonarQube Quality Gate: Passed, with A ratings for security, reliability, and maintainability, and zero open bugs, vulnerabilities, or security hotspots
• Gitleaks secrets scan: clean across the full commit history
• npm audit: no advisories originate in application code. The remaining advisories are confined to development and build tooling that is not shipped, or are transitive dependencies of the Atlassian Forge SDK packages, and are tracked for resolution in a future release
• Manifest scope-change check confirms no new OAuth scopes or permissions are introduced in this release, so the upgrade is silent on installed tenants with no re-approval prompt

Enhancements

Clearer Workflow Reset Notifications (BSOA-48, BSOA-55)

• Emails sent when a workflow transition resets an approval now inform rather than instruct. The message names the status the issue moved to, and no longer asks the recipient to review an issue that may have just been paused or parked
• The Reset Approval Status post-function now notifies affected approvers by default. A post-function where notification was deliberately turned off keeps that setting

More Readable Audit Trail (BSOA-58, BSOA-59)

• Actions taken automatically by workflow post-functions are now attributed to System in the approval history and CSV export, in place of an internal identifier or a blank name
• Entries recording that approvers were notified after a reset now name those approvers, rather than only counting them

Consistent “Reporter” Naming (BSOA-56)

• Two project settings previously labelled “Email Requestor on ...” are now labelled Email Reporter on ..., matching the Jira Reporter field they act on and the wording already used everywhere else in the app. Saved values are unchanged, and the published admin documentation has been updated to match

Bug Fixes

Licensing (BSOA-57)

• Fixed: The “License expires in N days” countdown appeared on subscriptions in good standing. Monthly subscribers saw this permanently, and annual subscribers saw it for the last 30 days of every year. A notice still appears if a license has genuinely expired

Add Approvers Post-Function (BSOA-47)

• Fixed: Approvers added by the Add Approvers workflow post-function now receive the “you have been added as an approver” email when the project’s Email Approver When Added setting is on. Previously that email was sent only when an approver was added from the issue panel
• Those additions are now also recorded in the issue’s approval history, so an approver added by a workflow appears in the trail alongside one added manually

Audit Trail (BSOA-54, BSOA-60, BSOA-62)

• Fixed: Approval resets triggered by a workflow transition are now recorded with the correct source and action, so they can be distinguished from a manually requested re-review
• Fixed: Notification entries now record the outcome of the send, and note when a delivery was refused, instead of leaving the result unrecorded
• Fixed: Configuration changes now show option names exactly as they appear on the settings screens. Some values previously appeared as internal codes such as APPROVED_OR_RETURNED

Personal Data Reporting (BSOA-61)

• Fixed: The app’s Personal Data Reporting response no longer reports an internal system identifier to Atlassian as though it were a user account

Upgrade Notes

• No new OAuth scopes or permissions. The upgrade is silent on installed tenants, with no admin re-approval prompt
• No configuration changes required, and no saved setting values are altered. The “Reporter” rename above changes labels only
• One behavior change to be aware of. A Reset Approval Status post-function that was configured before notification became an option will now notify the approvers whose decisions it resets. Any post-function where notification was explicitly switched off is unaffected. To change this, edit the post-function in the workflow editor

Code Quality

• Reduced the work performed when a reset clears decisions on issues with many approvers, so the transition completes faster (BSOA-53)
• Removed a redundant user lookup that ran for every automated audit entry, cutting one external call per recorded row (BSOA-58)
• Cleared the outstanding complexity and maintainability findings from the static analysis profile, with no change in behavior (BSOA-52)
• Locked the audit trail’s setting names and option labels to the same source the settings screens render from, so the two can no longer drift apart (BSOA-56, BSOA-62)

Test Coverage

• Backend + frontend test suites green; all checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• 1,445 backend and 169 frontend tests passing, with 83.3% code coverage
• New unit tests added covering the notification and audit records written by the workflow post-functions, the system actor label, the audit trail’s option wording, and the licensing display states
• SonarQube Quality Gate: Passed, with A ratings for security, reliability, and maintainability, and zero open bugs, vulnerabilities, or security hotspots
• Gitleaks secrets scan: clean across the full commit history
• npm audit: no advisories originate in application code. The open advisories are transitive dependencies of the Atlassian Forge SDK packages, and are tracked for resolution in a future release
• Manifest scope-change check confirms no new OAuth scopes or permissions are introduced in this release, so the upgrade is silent on installed tenants with no re-approval prompt

Enhancements

More Flexible Reset Approval Status Post-Function (BSOA-12)

• The Reset Approval Status workflow post-function now offers a Reset Mode option: reset all decisions, returned decisions only, or approved decisions only. The default is “reset all decisions,” which matches the previous behavior — existing workflow configurations are unchanged
• “Returned decisions only” mode supports phase-gate workflows — combined with Decision Locking, a phase transition can clear stale rejections from a previous phase without disturbing the approvals carried forward
• Role/group filtering is now built directly into the Reset Approval Status post-function , so a single post-function can filter by decision status and/or by approver role/group membership in any combination
• Reset notifications follow the same filter as the reset itself. When a reset mode or a role/group filter narrows a reset to a subset of approvers, only those approvers are notified, and the notification describes what was actually reset rather than implying every decision was cleared
• The separate Selective Reset post-function is now labeled as deprecated in the workflow editor, guiding admins to the consolidated Reset Approval Status post-function. Existing workflows that use Selective Reset continue to work unchanged

Consistent Issue-Type Eligibility & In-Flight Grandfathering (BSOA-37)

• When a project restricts approvals to specific issue types, that restriction is now enforced consistently across both the workflow Add Approvers post-function and the panel’s Add Approver action — new approvers are no longer added to issue types that aren’t eligible for sign-off
• If an issue already has approvers when its issue type later becomes ineligible, the Business Sign-off panel now stays available on that issue — in-flight approvers can still record their decisions, and admins can complete or clean up the approval. Previously the panel was hidden in this situation
• A brief, clear banner on those issues indicates the issue type is no longer eligible for new approvals, while existing decision, reset, and remove actions remain available
• No configuration changes required — the improved behavior applies automatically on upgrade

Bug Fixes

Admin Audit Log

• Fixed: Expanding an entry to view its details could show those details against the wrong entry after the audit list was filtered or re-sorted

Upgrade Notes

• No new OAuth scopes or permissions — the upgrade is silent on installed tenants, with no admin re-approval prompt
• Reset Approval Status default behavior is unchanged. Existing Reset Approval Status and Selective Reset workflow configurations continue to work without any edits — the new reset modes and role/group filtering are opt-in

Code Quality

• Consolidated the two reset post-functions onto a single shared role/group matching utility, removing duplicated filtering logic and giving both decision-status and role/group filtering one well-tested code path
• Added the minimum issue-panel string-localization primitive used by the new eligibility banner, laying groundwork for broader panel internationalization in a future release
• Added a lint rule that catches a class of list-rendering defect in admin tables at build time, preventing recurrence of the audit-log issue fixed in this release

Test Coverage

• Backend + frontend test suites green; all checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• New unit and component tests added covering the reset-mode options, role/group filter combinations, and issue-type eligibility / grandfathering behavior
• npm audit: clean (root + frontend)
• Gitleaks secrets scan: clean
• SonarQube Quality Gate: Passed, with A ratings for security, reliability, and maintainability, and zero open bugs, vulnerabilities, or security hotspots
• Manifest scope-change check confirms no new OAuth scopes or permissions are introduced in this release — upgrade is silent on installed tenants, no re-approval prompt

Enhancements

Locked, App-Managed BSO Custom Fields (BSOA-24)

• The BSO - Approvers and BSO - Status custom fields are now declared as app-managed Forge custom fields. Both fields appear in the Jira Fields admin UI with a LOCKED indicator, and the Edit and Delete options are no longer available on them — preventing accidental modification or deletion that would disconnect the live plugin state from existing approval data on issues
• Both fields are now provisioned automatically when the app is installed on a Jira site. No admin action is required to add them, and they are immediately available for use in JQL filters, issue navigator column display, dashboards, and the Business Sign-off panel
• Existing tenants where the BSO fields were previously created keep their same field identifiers and field values — the upgrade reclassifies the existing fields as app-managed without any data migration or admin action required
• No user action required — the change takes effect automatically on upgrade

Code Quality

• Retired the original setupCustomFieldContexts startup helper that ensured a global context on the BSO fields — this responsibility is now handled by the Forge platform via the app-managed custom field declaration, and the equivalent code is no longer needed
• Added a pre-release verification step that detects any changes to the app’s manifest permissions block between releases — gives advance notice if a future release would prompt installed customers to re-approve permissions
• Added a reset:staging-dev npm script that uninstalls, redeploys, and reinstalls the app on a designated cold-install verification tenant in a single command — supports a release checklist step for catching install-path regressions on a fresh tenant

Test Coverage

• Backend + frontend test suites green; all checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• npm audit: clean (root + frontend)
• SonarQube Quality Gate: Passed
• New manifest scope-change check confirms no new OAuth scopes or permissions are introduced in this release — upgrade is silent on installed tenants, no re-approval prompt

Enhancements

Faster Panel & Gadget Loads for Large Approver Lists (BSOA-11, BSOA-21)

• The Business Sign-off panel and both dashboard gadgets (“My Approval Queue” and “My Approval Requests”) now load noticeably faster for issues, projects, and users with large approver lists
• Workflow post-function “Add Approvers” — when configured to add a large project role or group — completes in a fraction of the time previously required, especially for transitions that add 15+ approvers at once
• Gadget auto-refresh is gentler on the platform for power users who are approvers on many issues, reducing the chance of intermittent load failures under heavy use
• Internal cleanup consolidated duplicated approver-loading logic so all approver-list reads share a single, well-tested code path

Bug Fixes

GDPR Personal Data Report — Endpoint Routing (BSOA-22)

• Fixed: The weekly scheduled Personal Data Report job was failing with an INVALID_TARGET_URL error, preventing the report from being delivered to Atlassian’s Personal Data Reporting service
• Migrated the report submission to Forge’s official Privacy API, which handles endpoint routing and request batching natively
• GDPR compliance reporting now runs reliably on its weekly schedule
• No customer action required — the next scheduled run after upgrade will complete successfully

Log Hygiene — Issue Panel on Deleted or Inaccessible Issues (BSOA-23)

• Fixed: Error-level log entries appeared when the issue panel attempted to load for a deleted issue or one the app no longer had permission to read
• 404 responses from Jira are now treated as expected control flow — the panel simply doesn’t render, with no error logged
• Non-404 errors continue to log and surface as before
• Mirrors the same log-hygiene pattern applied to the field-sync handler in Rel 1.0.1, closing the equivalent gap on the panel resolver path

Code Quality

• Added a shared batched-read helper in the storage service layer; new unit tests cover empty input, single batch, batch boundaries, multiple batches, and result-ordering preservation
• Refactored addApproversToStorage (workflow post-function path) to read the issue index once, write approver records in parallel batches, and write the index once — with partial-failure isolation so a single failed write doesn’t block the rest
• Consolidated a duplicate approver-loading function inside the “My Approval Requests” gadget resolver, replacing it with a call to the canonical service function (which now inherits the batched-read behavior)
• Added focused test coverage for the custom-field-sync service: error paths for field-key resolution failures, non-OK PUT responses, and diagnostic logging — bringing service-level branch coverage above the 80% gate threshold

Test Coverage

• Backend + frontend test suites green; all checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• npm audit: 0 vulnerabilities (root + frontend)
• SonarQube Quality Gate: Passed — Security A, Reliability A, Maintainability A, 81.3% coverage, 0 security hotspots

Enhancements

Hide Panel Header When Disabled (BSOA-20)

• The Business Sign-off panel (header, icon, chevron, and body) is now fully hidden on projects where the plugin is disabled — no more empty “Business Sign-off” entry on every issue in projects that don’t use sign-off
• Visibility is evaluated by Jira server-side via a Forge manifest displayConditions block, so the panel never mounts and main-resolver never executes for disabled projects — saving invocation cost on top of the UX improvement
• Works uniformly on Jira Software, Jira Service Management, Jira Work Management, and Jira Product Discovery — any project type where jira:issueContext would otherwise render
• Finishing mode is honored — projects in finishing mode keep the panel visible so in-flight approvers can complete their decisions; the existing in-panel status messages handle “no approvers / finishing” and “issue type not eligible” cases as before
• Resolves the v1.0.0 “Known Limitation: Panel visibility on disabled projects” item

How it works

• A new Jira project entity property bso-panel-visible is the source of truth for the manifest’s display condition (project.properties['bso-panel-visible'] == true)
• The property is computed from the project’s effective config: panelVisible = effective.enabled || effective.finishingMode
• The property is synced automatically:
  • After every successful project-config save (updateProjectConfig)
  • After every successful project-config delete (deleteProjectConfig)
  • After every global-config save that changes enabled or finishingMode — fanned out across all stored project configs in parallel
  • On project-deleted events (best-effort cleanup alongside the existing config delete)
• Property writes are fail-safe: a Jira API failure logs and returns rather than throwing, so a flaky property write cannot break the upstream config save
• Defense in depth: the existing visible: false status-message path in the getIssuePanelData resolver is preserved — a motivated user calling the resolver directly via dev tools still gets the same “plugin disabled for this project” response

Required Permissions

This release adds two new granular OAuth scopes that the project-properties endpoint requires (the classic write:jira-work scope does not cover this endpoint):

• write:project.property:jira
• delete:project.property:jira

When customers upgrade, Atlassian will prompt site admins to approve the new permissions before the upgrade applies. The app cannot write bso-panel-visible (and therefore cannot hide the panel) until consent is granted.

Upgrade Notes

One-time backfill required on existing installations. When this release applies to an existing site, projects that were previously enabled will lose their panel on the next issue load — because the bso-panel-visible property has not yet been written for those projects. The property is written automatically the next time an admin saves the project’s BSO settings.

Recovery is trivial: for each enabled project, open Project Settings → Business Sign-off → click Save. Each save writes the property and the panel reappears on the next issue load. No data is lost; this is purely cosmetic state.

Alternatively, a Jira admin can PUT the property directly via REST for known projects:

PUT /rest/api/3/project/{projectIdOrKey}/properties/bso-panel-visible
Body: true

Already-open issue tabs will pick up the visibility change on their next refresh — displayConditions is evaluated by Jira on page load, not live.

Code Quality

• New internal service encapsulates the panel-visibility property write and delete, along with the enabled/finishing-mode derivation; 15 dedicated unit tests covering the pure compute function, sync success and failure paths, and delete-treats-404-as-success semantics
• Existing tests updated to assert the new side-effects: per-save sync, fan-out only on relevant global-config field changes, project-delete property cleanup
• Admin UI help text added under both the global and per-project “Enabled” toggles explaining the “applies on next issue load” refresh behavior, and fully internationalized

Test Coverage

• 1,180 backend tests + 143 frontend tests (1,323 total) — added 24 new tests
• All checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• SonarQube Quality Gate: Passed — 0 new code smells, coverage on new code increased the overall project coverage by ~1%

New Features

My Approval Queue Dashboard Gadget (BSOA-4)

• New Jira dashboard gadget surfaces open issues where the user is currently an approver
• Configurable approver-status filter: Added, Pending, Approved, Returned, or All
• Optional per-project filter (or All projects)
• Configurable display page size: 10, 25, 50, or All
• Optional auto-refresh interval: Never, 15 minutes, 30 minutes, 1 hour, 2 hours
• Columns: Type, Key, Summary, Issue Status, My Decision, Decided (X of Y approvers), Days in current status
• Help tooltip on the gadget directs users to JQL with the BSO custom fields for closed-issue or historical reporting
• Cancel button on the configuration form lets users exit without saving changes
• Per-account index (bsf:account-issues:{accountId}) backs the lookup so the gadget always sees every issue the user is/was an approver on

My Approval Requests Dashboard Gadget (BSOA-5)

• New Jira dashboard gadget surfaces open issues the user submitted (reporter or assignee) that have approvers attached
• Configurable user axis: Reporter, Assignee, or Either
• Configurable approval-state filter: Open (Not Started + Awaiting Decisions), Returned, Approved, or All
• Optional per-project filter (or All projects)
• Configurable display page size: 10, 25, 50, 100, or All
• Optional auto-refresh interval: Never, 5 minutes, 15 minutes
• Columns: Type, Key, Summary, Issue Status, BSO Status, Decided (X of Y approvers), Days in current status
• Expandable rows show each approver’s status, decision date, and days waiting; click the issue key to view full decision comments in context
• Issues without any approvers attached are hidden — they aren’t approval requests
• Truncation banner appears when the user has more than 500 in-progress issues that match the JQL; the banner directs users to refine filters

Gadget Configuration Persistence

• Both gadgets persist their configuration to Forge Storage keyed by the dashboard gadget’s localId, so settings survive dashboard reloads, browser sessions, and plugin redeploys
• Configuration form initializes from the persisted values on edit; defaults fill in only on first configure

Bug Fixes

This release tightens the BSO approval panel’s visual fidelity: it now reflows correctly in narrow detail columns, and it surfaces eligibility conflicts on previously-decided approvers. Backend approval logic, data integrity, and security guards are unchanged — these fixes close visual gaps where the panel didn’t fully communicate backend state.

BSO Panel — Narrow-Column Responsiveness (BSOA-14)

• Fixed: BSO approval panel content overflowed the right edge of its container when rendered in narrow Jira issue detail columns (e.g., resized browser windows, side-detail slide-out views)
• The “Add Approver” button, per-approver action buttons (Remove, Re-notify), and footer buttons (Audit History, Notify Approvers) were clipped or pushed off-screen
• Added shouldWrap to the affected panel rows so children reflow onto additional lines when there isn’t enough horizontal room
• At wide widths the layout is unchanged — single-line rendering is preserved with no wasted vertical space

Approver Ineligibility Indicator (BSOA-15)

• Fixed: Two related visual issues with how the panel displayed ineligible approvers (SoD violation, eligibility-rule mismatch, or assignee/reporter conflicts that tripped after a decision was made):
  • Decided approvers (APPROVED or RETURNED) who later became ineligible showed only their decision lozenge with no visible indication of the new conflict
  • Undecided approvers (ADDED or PENDING) who were ineligible had their status label replaced by an “Ineligible” lozenge, hiding whether they were Added or Pending
• The panel now consistently displays a small 🚫 (no-entry) icon as a trailing decoration after the status lozenge for all ineligible approvers — same pattern as the existing 🔒 lock icon
• Status lozenge (Added / Pending / Approved / Returned) is now always shown as the primary, with 🚫 and/or 🔒 trailing as decorations
• Tooltip on the 🚫 icon carries the specific reason (e.g., “SoD Conflict: Assignee cannot approve work they are assigned to complete”)
• Visual order on the row: [Status] 🚫 🔒 when all three apply
• Saves significant horizontal space versus the prior lozenge — materially improves narrow-column rendering
• Backend behavior was already correct (decision changes blocked when sodViolation is true via the canDecide flag, with server-side re-validation and friendly error messages via parseErrorMessage); this release closes the visual gap

Code Quality

• 75 new backend tests covering gadget resolvers, JQL pagination + truncation detection, decided-count rollups, “All” sentinel pagination, and gadget configuration persistence
• BSOA-5 resolver implements internal JQL pagination (via Jira’s nextPageToken) up to a hard cap of 500 issues per request; bounded latency for users with very large reporter/assignee sets
• BSOA-4 resolver batches per-project effective-config reads across the displayed page (was previously fetching per-item)
• Cancel button added to both gadget configuration forms
• Auto-refresh keeps the existing table visible while reloading, instead of blanking to a spinner every interval
• License-inactive state on both gadgets now uses error SectionMessage appearance (previously warning)

Gadget Code-Sharing Refactor (BSOA-17)

• Extracted ~685 lines of duplicated code from the two gadget pages into shared modules: a generic useGadgetView hook (state machine, refresh listener, pagination, dynamic gadget chrome title) and a generic GadgetConfigForm component (wrapper-form pattern with project / max results / refresh-interval selects, plus a render-prop slot for gadget-specific filter dropdowns)
• Both gadget pages shrank from ~547 lines to ~270-290 lines and now consume the shared abstractions
• Added shared style and utility modules (gadgetTableStyles, gadgetUtils) to deduplicate table chrome and click handlers across the two table components
• Frontend test coverage went from 0% to ≥87% on every gadget-related component, hook, and form (73 new component tests added)
• Closed the v1.1.0 SonarQube quality-gate failure: New Code coverage now 95.5% (gate ≥80%), duplication 0.15% (gate ≤3%), 0 new issues
• Wired @vitest/coverage-v8 into the frontend so its lcov report is now fed to SonarQube alongside the backend’s (previously the gate only saw backend coverage)
• Polish: the “My Approval Requests” gadget no longer renders decision comments inside the expanded sub-rows — comments are still visible on the issue itself when clicked through

Test Coverage

• 1,156 backend tests + 143 frontend tests (1,299 total)
• All checks pass: TypeScript (backend + frontend), ESLint, Prettier, Vitest, Forge manifest lint
• SonarQube Quality Gate: Passed — 95.5% coverage on new code, 0.15% duplication on new code, 0 new issues, 0 security hotspots (Rating A)

Enhancements

License — Graceful Finishing Mode on Expiry (BSOA-13)

• When a Business Sign-off license expires, the plugin now automatically enters finishing mode for affected projects
• In-flight approval decisions can still be recorded, withdrawn, or reset, allowing pending approvals to complete cleanly
• Adding new approvers and other new-work operations remain restricted until the license is renewed
• New requireActiveOrFinishing() license guard introduced alongside the existing requireActiveLicense() for finer-grained control
• Workflow post-function handlers (add, remove, reset, selective reset, notify, selective notify) now apply the appropriate license guard based on whether the action creates new work or progresses in-flight work

Compliance Carve-Outs (BSOA-13)

• GDPR — Personal Data Reports: The Data Subject Access Request endpoint (getUserDataReport) now functions regardless of license state, ensuring continuous regulatory compliance
• SOC 2 — Audit Export: Audit history export (start and cleanup) now functions regardless of license state to support customer SOC 2 audits and ongoing compliance obligations
• Each compliance carve-out is documented inline with explanatory comments at the resolver site

Issue Panel UX (BSOA-13)

• License-expired banner copy updated to clarify the finishing-mode behavior: existing approvals can still complete; new approvers blocked
• Trial-specific banner messaging: trial-ended customers see an “Upgrade to continue full access” message instead of the generic “Renew” message intended for paid-license expiry
• Decision buttons (Approve, Return, Change Decision) are now correctly enabled when the project is in finishing mode, matching the new backend behavior
• Notify Approvers button respects the same in-flight permission model
• License-specific error message added to the decision modal when an action fails mid-session due to license expiry, replacing the previous generic error fallback

Code Quality

• Added 28 new tests covering all four license states (no license, active trial, active paid, expired) across affected resolvers and workflow handlers

Test Coverage

• 1,064 backend tests + 72 frontend tests (1,136 total)
• 80.5% line coverage (SonarQube analysis)
• SonarQube Quality Gate: Passed (Security A, Reliability A, Maintainability A — 0 security issues, 0 reliability issues, 0 security hotspots)

Bug Fixes

Notification Recipients — Empty Recipient Guard (BSOA-1)

• Fixed: Jira /notify endpoint returning HTTP 400 when called with recipients that resolve to nobody (empty users array, or { assignee: true } / { reporter: true } when the issue has no assignee/reporter)
• Added empty-recipient guard in the core sendNotification function — silently returns false when no recipients are defined
• Added assignee/reporter field checks before sending decision and outcome notifications
• No behavior change when recipients are present; notifications continue to send normally

GDPR Personal Data Report — Path Manipulation Error (BSOA-2)

• Fixed: Weekly scheduled personal data report handler failing with “Disallowing path manipulation attempt” error
• Root cause: Forge’s route tagged template was rejecting the entire /app/report-accounts/ path when passed as an interpolated variable
• Fix: Replaced the interpolated variable with a literal string in the route template
• GDPR personal data reporting now functions correctly

Log Hygiene — Suppress Expected 404s on Deleted Issues (BSOA-6)

• Fixed: Noisy console.warn entries appearing in logs when an issue is deleted, caused by the field-sync handler racing with the issue-deleted handler
• The syncAllFields function now silently returns when a 404 JiraApiError is caught, since the issue no longer exists
• Non-404 errors continue to be logged as warnings
• No impact on the issue-deleted handler, which already cleans up correctly

Code Quality

• Refactored IssuePanel component to extract license warning logic, reducing cognitive complexity to meet SonarQube threshold
• Added pre-release verification script (scripts/pre-release.sh) with 10 automated checks: TypeScript, ESLint, Prettier, tests with coverage, npm audit, frontend build, Forge lint, Gitleaks, and optional SonarQube scan
• Added .prettierignore to exclude generated report files from formatting checks

Test Coverage

• 1,036 backend tests + 72 frontend tests (1,108 total)
• 86.2% coverage on new code
• SonarQube Quality Gate: Passed (Security A, Reliability A, Maintainability A)

Approval Workflow Management

• Approver management — Add, remove, and notify approvers on any Jira issue via the Business Sign-off issue panel
• Approval decisions — Approvers can approve, return, or withdraw decisions with optional comments
• Approval status calculation — Configurable approval threshold (percentage-based), with statuses: Not Started, Awaiting Decisions, Approval Passed, Approval Failed
• Bulk add approvers — Add multiple approvers at once with per-user eligibility validation
• Three-mode notify action — Notify new approvers only, send reminders to all undecided, or request full re-review (resets decided approvers)
• Decision locking — Optionally lock approved decisions when the issue transitions to a new status, preventing changes after workflow progression
• Comment requirements — Configurable per decision type: require comments on all decisions, approvals only, returns only, or none

Configurable Rules & Permissions

• Global configuration — Centralized admin page with tabbed layout for all plugin settings
• Project-level overrides — Per-project configuration with optional overrides for threshold, SoD, eligibility, comments, and decision locking
• Approver management permissions — Control who can add/remove approvers: issue reporter, assignee, and/or Jira administrators
• Eligible approver filtering — Restrict who can be assigned as an approver by project role and/or group membership (ALL_USERS or SELECTED_USERS mode)
• Separation of Duties (SoD) — Prevent the issue assignee and/or reporter from being an approver, with real-time re-evaluation when fields change
• Decision authority — Optionally require Jira Edit Issues permission to record a decision
• Panel visibility — Show the approval panel on all standard issue types (excludes subtasks) or selected issue types only
• Finishing mode — Non-destructive plugin disable that preserves existing approvals while preventing new ones

Workflow Integration

• Workflow conditions — Block transitions based on approval status (e.g., require Approval Passed before closing)
• Workflow validators — Validate approval state during transitions with configurable error messages
• Workflow post-functions — Automatically add approvers (from users, roles, groups, or custom fields), remove approvers, reset decisions, and notify approvers on transitions
• Selective notify post-function — Notify only approvers matching specific role/group filters
• Selective reset post-function — Reset decisions only for approvers matching specific role/group filters
• Notification rate limiting — Prevents duplicate notifications within the same UTC day

Audit & Compliance

• Immutable audit trail — SHA-256 integrity-protected history records stored as Jira issue properties, providing tamper-evident audit evidence
• Approval history — Append-only audit log viewable in the issue panel with full decision context (actor, action, timestamps, comments, SoD status)
• CSV audit export — Export approval history to CSV with date range and project filtering, async background processing with progress tracking
• Admin audit log — Tracks all configuration changes (global config, project config, debug logging toggles) with actor and timestamp
• Diagnostic logging — Admin-controlled toggle with auto-expiry (1–8 hours) for production troubleshooting via the Atlassian Developer Console

Custom Fields & JQL

• BSO - Approvers — Read-only multi-user custom field showing current approvers on each issue, synced automatically from the approval panel
• BSO - Status — Read-only text custom field showing the current approval status (Not Started, Awaiting Decisions, Approval Passed, Approval Failed)
• JQL support — Filter and search issues using standard JQL:
  • "BSO - Approvers" = currentUser() — find issues where you are an approver
  • "BSO - Status" = "Approval Passed" — find approved issues
  • Issue property queries for advanced filtering (threshold, percentage, counts)

Email Notifications

• Approval requested — Notify approvers when added or when review is requested
• Decision notifications — Notify assignee and/or reporter when decisions are recorded
• Outcome notifications — Notify assignee and/or reporter when approval passes or fails
• Re-review notifications — Notify all approvers when decisions are reset and re-review is requested
• Per-project notification settings — Enable/disable each notification type independently per project

Data Privacy & GDPR

• Personal Data Reporting — Weekly scheduled job reports stored account IDs to Atlassian’s Personal Data Reporting API
• Account pseudonymization — Automatically pseudonymizes approver records, history entries, admin audit entries, and issue properties when Atlassian reports an account as closed
• DSAR support — Admin endpoint generates a complete personal data report for any account ID
• No data egress — All data remains within Atlassian’s Forge infrastructure; no data transmitted to external services
• Minimal PII storage — Stores Atlassian account IDs (opaque identifiers) only; display names and emails resolved at runtime via Jira APIs

Licensing

• Atlassian Marketplace licensing — Standard Marketplace paid app licensing with trial support
• Graceful degradation — Expired licenses restrict write operations while preserving read access to existing approval data
• License status display — License state shown in the admin page and issue panel

Platform Details

• Runtime: Atlassian Forge (Node.js 22.x)
• Frontend: React 18 (Custom UI) + Forge UI Kit (issue panel, admin pages)
• Storage: Forge Storage (key-value) + Jira issue properties
• Authentication: Forge app identity (asApp()) for all Jira API calls; asUser() for admin permission verification
• Scopes: storage:app, read:jira-work, write:jira-work, read:jira-user, manage:jira-configuration, write:app-data:jira, report:personal-data

Test Coverage

• 982 backend tests + 72 frontend tests (1,054 total)
• 88.7% line coverage, 88.2% branch coverage
• ESLint security scan, npm dependency audit, Gitleaks secrets scan — all clean

Known Limitations

• BSO - Approvers field is read-only — Approvers are managed exclusively through the Business Sign-off panel. The custom field is for display and JQL queries only.
• Panel visibility on disabled projects — The panel header (“Business Sign-off”) appears even when the plugin is disabled for a project. The panel body is empty, but the header cannot be suppressed due to Forge platform behavior.
• No custom JQL functions — Forge does not support custom JQL functions. Use the built-in custom field JQL and issue property queries instead.
• Eventual consistency — Forge Storage has eventual consistency characteristics. In rare cases, rapid sequential operations may see stale data.
• Forge cold start — First invocation after idle may take 500–1000ms longer due to Forge runtime cold start.
• Frontend bundle size — The Custom UI bundle is ~1.1MB (313KB gzipped). This is within Forge limits but may be optimized in future releases.

Migration from Data Center

This is a new Forge app, not a direct migration tool. Data Center customers moving to Jira Cloud will need to:

1. Install the Forge app from the Atlassian Marketplace
2. Configure global and project settings (settings are not migrated from DC)
3. Re-add approvers on existing issues (approval data from DC is not transferred)

A data migration tool is planned for a future release.

Support

• Email: support@cahabaforge.com
• Website: https://cahabaforge.com/contact
• Documentation: https://cahabaforge.com/docs
• Security issues: security@cahabaforge.com