Problem / context

A customer wants to feed approval data into Power BI for change-management reports. The original request asked for group status (pending/approved/rejected), issue keys, rejection details, and timestamps.

After reviewing the current webapi v2 response, most of this is already exposed — only the human-readable Jira issue key is missing:

• Group status — already present as GroupStep.status (StepStatus): SUCCESS = approved, FAIL = rejected, WAIT = step is not active yet ACTIVE = pending. Approval-level detailedStatus already returns APPROVED/REJECTED/ONGOING verbatim.

• Rejection details + timestamps — already present in GroupStep.entries[]: per-member decision(ACCEPTED/REJECTED/ABSTAINED), comment, and decisionDate; plus GroupStep.decisionDate.

• Issue key — missing. referenceId holds the numeric Jira issue ID (e.g. 10042), not the readable key (e.g. PROJ-123). The key is not stored anywhere; it is resolved only on the frontend today. So Power BI receives only the numeric id.

Solution

Add an issueKey field to the webapi v2 approval response (Approval DTO). Populate it by resolving the numeric referenceId to the Jira issue key.

Resolution should be done in batch per result page, reusing the existing issue cache (ApprovalDataCacheService) — one bulkGetIssues call per page maps id -> key. This mirrors the frontend's existing pattern and keeps the key always current. Avoid per-issue (N+1) calls.

Acceptance criteria

• webapi v2 approval response includes issueKey for Jira approvals (the readable key, e.g. PROJ-123).

• The list endpoint (GET /webapi/v2/approvals, up to 200 per page) resolves keys in batch — no more than one Jira call per page.

• The single-approval endpoint (GET /webapi/v2/approvals/{id}) also returns issueKey.

• Existing fields (referenceId, group status, entries, timestamps) remain unchanged — issueKey is additive and backward-compatible.

Notes

• Confluence: referenceId is the page id; issueKey is Jira-only and should be absent/null for Confluence approvals.

• No DB change. The key is resolved live (cached), so it stays correct even when an issue is moved between projects (which changes its key). Persisting the key in the DB was rejected for this reason.

• Status naming is out of scope. The customer can map StepStatus to pending/approved/rejected on their side. A dedicated per-group "approved/rejected/pending" field could be added later if requested, but the data is already available.