ENG-2784: Auto-populate rules and targets on DSR policy creation

[JadeCara]

Ticket ENG-2784

Description Of Changes

Add support for auto-generating rules and default data-category targets when creating DSR policies via PATCH /api/v1/dsr/policy.

The policy creation endpoint now accepts two new optional fields (mutually exclusive):

• action_type — auto-generates a rule (named {policy_name} Rule) and seeds default data-category targets:
  • Access/Erasure: all user.* 2nd-level categories excluding user.financial, user.payment, user.authorization (same defaults that ship OOTB)
  • Erasure: masking strategy set to HMAC
  • Consent: rule only, no targets (matching seed data pattern)
• rules — creates explicitly provided rules with optional inline targets, using the existing RuleCreate schema extended with a targets field

Backward compatible: if neither field is provided, behavior is unchanged. Existing policies being updated ignore both fields.

Code Changes

• src/fides/api/schemas/policy.py - Added RuleCreateWithTargets schema, added action_type and rules fields to Policy schema with mutual exclusivity validator
• src/fides/api/api/v1/endpoints/policy_endpoints.py - Added _create_rule_and_targets() and _auto_create_rule_and_targets() helpers; modified create_or_update_policies to auto-create rules/targets for new policies
• tests/ops/api/v1/endpoints/test_policy_endpoints.py - Added TestCreatePolicyWithAutoPopulatedRules class with 7 parametrized/standalone tests

Steps to Confirm

1. Create an access policy with auto-population:

   curl -X PATCH http://localhost:8080/api/v1/dsr/policy \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '[{"name": "My Access Policy", "action_type": "access"}]'

   Verify: response includes a rule named "My Access Policy Rule" with default user.* targets

2. Create an erasure policy:

   curl -X PATCH http://localhost:8080/api/v1/dsr/policy \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '[{"name": "My Erasure Policy", "action_type": "erasure"}]'

   Verify: rule has masking_strategy.strategy == "hmac" and default targets

3. Create a consent policy:
   Same pattern with "action_type": "consent" — verify rule created with no targets

4. Create a policy with explicit rules and targets:

   curl -X PATCH http://localhost:8080/api/v1/dsr/policy \
     -H "Authorization: Bearer <token>" \
     -H "Content-Type: application/json" \
     -d '[{"name": "Custom Policy", "rules": [{"name": "Custom Rule", "action_type": "access", "targets": [{"data_category": "user.name"}]}]}]'

   Verify: rule and target created as specified

5. Verify mutual exclusivity: passing both action_type and rules returns 422

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:
  • No UX review needed
• Followup issues:
  • 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	Feb 27, 2026 9:43pm
fides-privacy-center	Ignored		Feb 27, 2026 9:43pm

[greptile-apps]

Greptile Summary

This PR successfully implements auto-population of rules and targets when creating DSR policies, with two mutually exclusive input options: action_type for automatic generation with sensible defaults, or rules for explicit rule/target specifications.

Key changes:

• Added RuleCreateWithTargets schema extending RuleCreate with inline targets
• Enhanced Policy schema with transient action_type and rules fields (excluded from responses)
• Implemented helper functions _create_rule_and_targets() and _auto_create_rule_and_targets() with proper error handling
• Auto-creation only applies to new policies; existing policies ignore these fields
• Default erasure policies use HMAC masking strategy and exclude sensitive categories (financial, payment, authorization)
• Proper transactional cleanup: policies are deleted if rule/target creation fails
• Comprehensive test coverage validates all scenarios including edge cases

Implementation quality:

• Clean separation of concerns with helper functions
• Proper validation at schema level (mutual exclusivity) and endpoint level (supported action types)
• Maintains backward compatibility - no breaking changes
• Good error handling with clear messages for bulk operation failures

Confidence Score: 5/5

• This PR is safe to merge with only minor style improvements needed
• The implementation is well-designed with proper error handling, validation, and backward compatibility. Code follows established patterns and includes comprehensive tests. The only issue is a minor testing best practice violation (manual database cleanup) that doesn't affect functionality.
• All files are production-ready. The test file has manual cleanup calls that can be removed as a minor style improvement, but this doesn't block merging.

Important Files Changed

Filename	Overview
src/fides/api/schemas/policy.py	Added RuleCreateWithTargets schema and transient action_type/rules fields to Policy with proper validation and response exclusion
src/fides/api/api/v1/endpoints/policy_endpoints.py	Added helper functions to auto-create rules/targets, enhanced endpoint with proper validation, error handling, and transactional cleanup on failure
tests/ops/api/v1/endpoints/test_policy_endpoints.py	Comprehensive test coverage for new functionality, but includes manual database cleanup that should be removed per testing best practices

_{Last reviewed commit: 95bf52e}

[greptile-apps]

_{4 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[vcruces]

Looks great to me! The code is easy to follow and the key cases are well covered by tests

[vcruces]

Are these explicit deletes necessary? Don’t these instances get cleaned up automatically after each test?

[JadeCara]

Good call! Thanks :) - removing.