ENG-3415: New Privacy Center Form Field Types

[mikeGarifullin]

Ticket ENG-3415

Description Of Changes

Adds checkbox, checkbox_group, textarea, and file custom field types to the Privacy Center request form config. Also fixes a bug where falsy custom field values (False, 0, "", []) were silently dropped during persistence — required for checkbox fields where an unchecked False value is meaningful.

Code Changes

• privacy_center_config.py — Extended CustomPrivacyRequestField.field_type literal with checkbox, checkbox_group, textarea; added FileCustomPrivacyRequestField (with allowed_mime_types, max_size_bytes) and wired it into the discriminated union; added model_validator requiring checkbox_group to have at least one option
• redis_cache.py — Added StrictBool to MultiValue union before StrictInt (Python bool is a subclass of int, so it must be matched first to avoid True/False coercing to 1/0)
• privacy_request.py — Fixed if item.value: → if item.value is not None: in persist_custom_privacy_request_fields and migrate_hashed_fields to allow falsy values through
• attachment.py — Added AttachmentType.user_provided enum value
• clients/privacy-center/config/examples/customFields.json — Updated example config with new field types

Steps to Confirm

1. POST to /api/v1/privacy-request with custom_privacy_request_fields containing:
   • A checkbox field with value: true and another with value: false
   • A checkbox_group field with value: ["Option A", "Option B"]
   • A textarea field with a multi-line string value
2. Verify all fields are returned by the privacy request detail endpoint
3. Verify the false checkbox value persists (was previously silently dropped)
4. Confirm that field_type: "file" config entries are validated correctly: hidden: true and options both raise a ValidationError
5. Confirm checkbox_group without options raises a ValidationError

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:
  • No migrations
• Documentation:
  • No documentation updates required

[vercel]

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

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Apr 15, 2026 4:20pm
fides-privacy-center	Ignored		Apr 15, 2026 4:20pm