Jira ticket status column in privacy request manager

[jpople]

Ticket ENG-2648

Description Of Changes

Adds frontend support for the pending_external privacy request status and surfaces
Jira ticket metadata on privacy request cards, both gated behind the
alphaJiraIntegration feature flag.

When a privacy request has an associated Jira ticket (jira_ticket_key,
jira_ticket_url, jira_ticket_status), users will see a clickable Jira ticket
link and status tag in the request list item header. The pending_external status
is available as a filter option and renders with the "Marble" badge color throughout
the UI.

Code Changes

• Added pending_external to PrivacyRequestStatus, RequestStatusBadge, and
  SubjectRequestStatusMap with "Marble" badge color
• Added pending_external to the bulk delete allow-list in helpers.ts
• Added Jira ticket link and status tag to the privacy request list item header,
  gated behind alphaJiraIntegration
• Added pending_external as a filter option in usePrivacyRequestsFilters
• Added new API types: JiraTicketSummary, PrivacyRequestResponseExtended,
  PrivacyRequestVerboseResponseExtended

Steps to Confirm

With alphaJiraIntegration flag off:

1. Confirm Pending External does not appear in the status filter dropdown
2. Confirm no Jira UI is visible on request cards

With alphaJiraIntegration flag on:
3. Confirm Pending External appears in the status filter dropdown with the Marble badge style
4. With a request that has jira_ticket_key/jira_ticket_status populated: confirm
the ticket key renders as a clickable external link and the status tag appears in the header
5. Confirm a pending_external request can be bulk-deleted

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • No migrations
• Documentation:
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ready	Preview, Comment	Mar 25, 2026 4:32am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
fides-privacy-center	Ignored		Mar 25, 2026 4:32am

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 4a16d5f4-3e7b-47ed-b16d-248a8d496742

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch jpople/eng-2648/jira-status-column

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR adds frontend support for the pending_external privacy request status and surfaces Jira ticket metadata (link + status tag) on privacy request list item cards, both gated behind the alphaJiraIntegration feature flag. The status additions are consistently applied across badge components, filter hooks, constants, and helpers. The overall approach and feature flag gating are well-implemented.

However, two issues in the new auto-generated Extended type files need to be resolved before merging:

• Build-breaking missing module: Both PrivacyRequestResponseExtended.ts and PrivacyRequestVerboseResponseExtended.ts import fides__api__schemas__privacy_request__IdentityValue from a file that does not exist anywhere in the types/api/models directory. This will cause TypeScript compilation to fail. The existing IdentityValue type (already used in PrivacyRequestResponse) has the same structure and should be used instead.
• custom_privacy_request_fields type regression: The extended types define custom_privacy_request_fields?: null, discarding the manually-maintained Record<string, {label, value}> type that exists in PrivacyRequestResponse (with an explicit comment explaining the override). Since ListItem.tsx now uses PrivacyRequestResponseExtended, the getCustomFields() call will always receive null at the type level, meaning custom privacy request fields will never render properly in the list view.

Confidence Score: 2/5

• Not safe to merge — the PR introduces a TypeScript build error via a missing module import in both new Extended type files.
• The feature logic, flag gating, and status registrations are all correct, but the two new type files import a non-existent module (fides__api__schemas__privacy_request__IdentityValue) which will break the TypeScript build. Additionally, the custom_privacy_request_fields type regression silently breaks custom field rendering in the list view for all requests. These are blocking issues that need to be fixed before the PR can merge.
• PrivacyRequestResponseExtended.ts and PrivacyRequestVerboseResponseExtended.ts both require fixes to their IdentityValue import and custom_privacy_request_fields type.

Important Files Changed

Filename	Overview
clients/admin-ui/src/types/api/models/PrivacyRequestResponseExtended.ts	New extended response type with two issues: imports a non-existent module (fides__api__schemas__privacy_request__IdentityValue) causing a build error, and narrows custom_privacy_request_fields to null instead of carrying over the proper manually-typed Record.
clients/admin-ui/src/types/api/models/PrivacyRequestVerboseResponseExtended.ts	Same build-breaking import of the non-existent fides__api__schemas__privacy_request__IdentityValue module, and custom_privacy_request_fields is also wrongly narrowed to null.
clients/admin-ui/src/features/privacy-requests/dashboard/list-item/components/Header.tsx	Adds Jira ticket link and status tag behind alphaJiraIntegration flag. Logic is correct; ticket_url is required on the type so href is always a string. Clean implementation.
clients/admin-ui/src/features/privacy-requests/dashboard/list-item/ListItem.tsx	Switches prop type to PrivacyRequestResponseExtended; the call to getCustomFields(item.custom_privacy_request_fields) will always receive null due to the narrowed type, silently suppressing custom field rendering.
clients/admin-ui/src/features/privacy-requests/helpers.ts	Adds PENDING_EXTERNAL to the bulk-delete allow-list. Correct and complete.

_{Reviews (2): Last reviewed commit: "Merge branch 'main' into jpople/eng-2648..." | Re-trigger Greptile}

[greptile-apps]

Ticket link renders as non-functional when URL is absent

The outer condition only checks for jira_ticket_key, but jira_ticket_url is separately optional. When a request has a ticket key but no URL (e.g., the integration stores the key before the URL is available), the Typography.Link receives href={undefined} and renders as a styled clickable element that does nothing on click — which is confusing for users.

Consider either guarding the link on the presence of both fields, or falling back to plain text when the URL is missing:

Suggested change

	{flags.alphaJiraIntegration && privacyRequest.jira_ticket_key && (
	<Flex gap={4} align="center">
	<Typography.Link
	href={privacyRequest.jira_ticket_url ?? undefined}
	target="_blank"
	rel="noopener noreferrer"
	>
	{privacyRequest.jira_ticket_key}
	</Typography.Link>
	{flags.alphaJiraIntegration && privacyRequest.jira_ticket_key && (
	<Flex gap={4} align="center">
	{privacyRequest.jira_ticket_url ? (
	<Typography.Link
	href={privacyRequest.jira_ticket_url}
	target="_blank"
	rel="noopener noreferrer"
	>
	{privacyRequest.jira_ticket_key}
	</Typography.Link>
	) : (
	<Typography.Text>{privacyRequest.jira_ticket_key}</Typography.Text>
	)}

[claude]

Code Review — PR #7619: Jira ticket status column in privacy request manager

Overall this is a clean, focused PR. The feature flag gating is applied consistently, the new status is wired into all the right places (badge maps, filter options, bulk-delete allow-list), and the rel="noopener noreferrer" on the external link is a good catch.

One functional concern worth addressing before merge (inline): the PrivacyRequestResponseExtended type is a full copy of PrivacyRequestResponse rather than an intersection, and in doing so it drops the manually-overridden custom_privacy_request_fields type that was carefully preserved in the base type. The other inline comments are style/clarity suggestions.

Summary of findings

Suggestions

• PrivacyRequestResponseExtended loses the manually-overridden custom_privacy_request_fields type from the base. Using an intersection type (PrivacyRequestResponse & { jira_tickets?: ... }) avoids this drift and keeps the two in sync.
• "Pending External" uses title case; the rest of the status map uses sentence case ("Requires input", "In progress", etc.).
• Only jira_tickets[0] is shown — either add a comment that one ticket per request is a deliberate constraint, or render all tickets.

Nice to have

• The old Page_Union_PrivacyRequestVerboseResponse__PrivacyRequestResponse__ export in index.ts appears to be dead code now that the slice uses the extended variant.