Improve manual task conditions pickers

[lucanovera]

Ticket ENG-2014

Description Of Changes

When setting up request fields conditions, it will now show the proper input depending on the field selected.

Some examples:

1. If I choose the created_at field I should see a date picker
2. If I choose a has_access_rules boolean field I should see a radio button with true/false options

Code Changes

• AddConditionForm.tsx moved code to utils file and render new input component
• ConditionValueSelector.tsx added this component that switches to the appropiate input
• Remove alpha flag

Steps to Confirm

1. Go to the conditions settings of a manual task integration like here

2. Click Add Condition and select "Privacy request field" in field source

3. Try selecting different options in the Field selector and check the value selector is correct
   For a date field you should see a datetime picker
   For a boolean, you should see radio buttons with True/False option
   For policy name, you should see a policy selector
   For location you should see a location country/city picker
   For location country you should see a location country picker
   For location group should show groups (and operator can only be list contains)
   For location regulations should show regulation select (and operator can only be list contains)

4. Try adding the field and then editing, check the edit modal shows the saved value correctly.

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • 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:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

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

Project	Deployment	Preview	Comments	Updated (UTC)
fides-plus-nightly	Ready	Preview	Comment	Dec 10, 2025 5:06pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
fides-privacy-center	Ignored			Dec 10, 2025 5:06pm

[greptile-apps]

Greptile Overview

Greptile Summary

This PR improves the user experience for configuring manual task conditions by dynamically rendering appropriate input components based on the selected field type. When users select a field like created_at, they now see a date picker; for boolean fields like has_access_rule, they see radio buttons with True/False options; for location fields, they see location pickers; and for policy fields, they see a policy selector.

Key changes:

• Created new ConditionValueSelector component that switches between input types (boolean radio buttons, date picker, location selects, policy selector, and text input)
• Extracted field type detection, value parsing, and formatting logic into utility functions
• Automatically sets operator to LIST_CONTAINS and disables operator selection for location_groups and location_regulations fields
• Added support for new convenience fields: location_country, location_groups, and location_regulations
• Exported ISO 3166 data from fidesui for location selection

Issues found:

• Minor syntax issue: boolean radio button uses shorthand value prop instead of explicit value={true}

Confidence Score: 4/5

• This PR is safe to merge after fixing the minor syntax issue with the boolean radio button
• The implementation is clean and well-structured with good separation of concerns. The only issue is a minor syntax error where <Radio value> should be <Radio value={true}>. The logic is sound, the utility functions are well-designed, and the component properly handles different field types with appropriate UI controls
• ConditionValueSelector.tsx needs the boolean radio syntax fixed before merge

Important Files Changed

File Analysis

Filename	Score	Overview
clients/admin-ui/src/features/integrations/configure-tasks/components/ConditionValueSelector.tsx	4/5	New component that renders appropriate input types based on field type (boolean, date, location, policy, etc.) - contains minor syntax issue with boolean radio value
clients/admin-ui/src/features/integrations/configure-tasks/AddConditionForm.tsx	5/5	Refactored to extract utility functions and integrate the new ConditionValueSelector component, with automatic operator fixing for location groups/regulations
clients/admin-ui/src/features/integrations/configure-tasks/utils.ts	5/5	Added field type detection, value parsing/formatting functions, and operator options to support dynamic input rendering based on field types

[greptile-apps]

_{5 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[gilluminate]

This type guard is somewhat weak. The check "toISOString" in rawValue doesn't guarantee it's a Dayjs object (native Date objects also have toISOString). Consider using:

Suggested change

	if (rawValue && typeof rawValue === "object" && "toISOString" in rawValue) {
	return (rawValue as Dayjs).toISOString();
	}
	if (dayjs.isDayjs(rawValue)) {
	return rawValue.toISOString();
	}

[lucanovera]

Excelent suggestion, that is a much better guard! Applied

[lucanovera]

@gilluminate Thanks for the review! I've applied both your suggestions.
And regarding the unhandled error with Dates I've added 2 protections:

1. An additional dayjs.isDayjs check to prevent the unhandled error
2. Clearing values when the Field value changes

it is now ready for a re-review.

[gilluminate]

Excellent work! Tested and works well. It's fun to use!