Context

Approval Path keeps approval state in an issue property and in JQL functions, but it does not expose native Jira fields. As a result users cannot place the approval status as a board column, use it in a filter, sort by it, or use simple JQL without knowing our custom functions. We want to provide clear, computed fields that show the approval state directly on the work item.

Goal

Add read-only Jira custom fields that present the approval state, ready to use on boards, in filters, sorting and JQL.

Scope, proposed fields

1. Approval Status: aggregate status of the approvals on the issue (In Progress, Approved, Rejected, empty when none). Searchable in JQL, usable as a column and for sorting.

2. Approval Progress: progress shown as Step: {stepsDone}/{stepsCount}, matching the format used on the approvals list.

3. Approval Percentage: completion percentage instead of a step count, for example 50%.

4. Pending Approvers: people awaiting a decision on the active steps, covering users (accountId), groups (name) and external user emails.

Handling multiple approvals on one work item

Less common but required. When a work item has more than one approval, each field prefixes the value with the approval name, entries separated by commas:

• Approval Progress: Security Review: Step: 1/2, Budget Sign-off: Step: 2/2

• Approval Status: Security Review: In Progress, Budget Sign-off: Approved

• Approval Percentage: Security Review: 50%, Budget Sign-off: 100%

When there is a single approval, the field shows the value only.

Technical solution

• A jira:customFieldType module in the manifest, with the resolver as a Forge Remote endpoint on our backend (consistent with the other modules). The value function runs on every issue view and during reindex.

• The value function reads data from our database by reference id, without REST calls to Jira and without extending the entity property.

• Approval name and status come from existing flat columns on the approval config record.

• Progress denormalization: add steps_done and steps_count columns to the approval config, populated on the write path that already runs on every decision (the path object already carries the computed values). Percentage is derived from these columns (round(stepsDone * 100 / stepsCount)), without an extra column.

• Read is a single flat, indexed select by reference id, with no joins to the step table, safe under a reindex burst.

• Pending Approvers: account ids, group names and external emails are taken from the step tables by id; the field presents all three kinds of recipient.

• Status is derived from the current database state, so it is not affected by a stale rejected marker after a relaunch.

• The existing entity property stays unchanged.

Acceptance criteria

• Approval Status, Approval Progress, Approval Percentage and Pending Approvers are available to add through the standard custom fields administration.

• Values are correct for: a single approval, multiple approvals, parallel steps, and after relaunching a rejected approval (current status, not historical).

• The multiple-approval format matches the section above (name, value, commas).

• Approval Progress uses the Step: x/y format consistent with the approvals list (same steps done and steps count values).

• Approval Percentage matches the progress percentage currently computed for the approvals list.

• Approval Status is filterable in JQL (= Approved, etc.) and usable as a column and for sorting.

• Pending Approvers shows users, groups and external emails, without REST calls to Jira in the value function to determine the recipients.

• Read is a single flat select by reference id (no joins to the step table on the read path), verified under reindex.

• The steps_done and steps_count columns stay current after every step decision (Liquibase migration and backfill of existing approvals).

• The entity property and existing JQL functions are unchanged (no regression).