Add data_purposes support to datasets

[galvana]

Description Of Changes

Update fideslang dependency to version 3.1.3, which includes data_purposes field support. This enables purpose-based access control (PBAC) at dataset, collection, field, and sub-field levels via existing dataset CRUD endpoints.

Code Changes

• Updated pyproject.toml to pin fideslang==3.1.3 (from 3.1.4a1)

Steps to Confirm

1. Upsert a dataset with data_purposes at all levels via POST /api/v1/dataset/upsert
2. GET the dataset back and confirm data_purposes persists at all levels
3. Verify backward compat: existing datasets without data_purposes still work

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:
  • 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	Mar 25, 2026 8:25pm
fides-privacy-center	Ignored		Mar 25, 2026 8:25pm

[greptile-apps]

Greptile Summary

This PR introduces data_purposes support in datasets by taking a dependency on an unreleased branch of fideslang. The single change is a new root-level requirements.txt file that references fideslang from a Git branch.

• The override mechanism appears broken: pyproject.toml still declares fideslang==3.1.4a1 and uv.lock still resolves to that PyPI release. The new requirements.txt is not wired into any uv install step, so the branch dependency will never actually be installed.
• The branch reference (@feat/add-data-purposes-to-dataset-models) is non-deterministic — it is not pinned to a commit SHA and can silently drift as the upstream branch evolves.
• The PR description itself flags this as pre-merge work ("The fideslang pin will be updated to the release version before merge"), but as currently written, even the dev/review environment won't pick up the new fideslang code without explicitly running uv pip install -r requirements.txt by hand.
• pyproject.toml and uv.lock must be updated together for the override to take effect in a uv-managed project.

Confidence Score: 1/5

• Not safe to merge — the dependency override has no effect as implemented, and the PR is explicitly flagged as pre-merge work pending an upstream release.
• The sole change (new requirements.txt) does not actually install the intended fideslang branch in a uv-managed project because pyproject.toml and uv.lock were not updated. The feature being enabled (data_purposes support) will therefore not be present at runtime. Additionally, the PR author explicitly notes this should not be merged until fideslang#39 is released and the pin is updated to a released version.
• requirements.txt — the override approach needs to be replaced with updates to pyproject.toml and uv.lock

Important Files Changed

Filename	Overview
requirements.txt	New root-level requirements.txt pinning fideslang to a git branch — does not override pyproject.toml or uv.lock, so the actual installed version is unchanged; also uses a mutable branch ref instead of a commit SHA

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into feat/dataset-da..." | Re-trigger Greptile}

[greptile-apps]

Dependency override has no effect

This new requirements.txt file is not referenced anywhere in the project's install configuration, CI workflows, or Makefile. The actual project dependency is declared in pyproject.toml (line 58: "fideslang==3.1.4a1") and locked in uv.lock. Creating a standalone requirements.txt at the repo root does not override those — uv sync and uv install will continue installing fideslang==3.1.4a1 from PyPI.

To actually swap in the unreleased branch build, you would need to either:

1. Update pyproject.toml to use the git reference: "fideslang @ git+https://github.com/ethyca/fideslang.git@feat/add-data-purposes-to-dataset-models"
2. Regenerate uv.lock with uv lock

The CI check in .github/workflows/publish_docs.yaml that uses requirements.txt only reads docs/fides/requirements.txt, not the root-level file added here.

[greptile-apps]

Branch reference is non-deterministic

The dependency is pinned to a branch name (@feat/add-data-purposes-to-dataset-models) rather than a specific commit SHA. This means different installs at different points in time may pick up different code if new commits are pushed to that branch, making builds non-reproducible.

When the intent is to pin to a specific pre-release state, use a commit SHA instead:

fideslang @ git+https://github.com/ethyca/fideslang.git@<specific-commit-sha>

The PR description already acknowledges this needs to be replaced with the final release version before merge, but documenting the SHA in the meantime prevents accidental drift during development/review.

[claude]

Code Review

This PR introduces a single file change — a new root-level requirements.txt that pins fideslang to a feature branch in order to get data_purposes field support ahead of its official release.

Critical (Must Fix)

1. Mutable branch reference is non-reproducible.
The pin fideslang @ git+...@feat/add-data-purposes-to-dataset-models resolves to branch HEAD at install time. Any force-push or new commit to that branch silently changes what gets installed. Pin to an immutable commit SHA until the release is available, then update to the release version before merging.

2. Conflicting dependency declaration.
pyproject.toml already declares fideslang==3.1.4a1 as the authoritative dependency. This new requirements.txt at the repo root creates a second, conflicting source of truth. CI workflows in this repo only reference docs/fides/requirements.txt and qa/requirements.txt — there is no evidence this root-level file is consumed by any pipeline, Docker build, or install step. The net effect is that local environments that manually run pip install -r requirements.txt will get a different fideslang than environments driven by pip install -e . (i.e., CI and production). If the intent is to override the dependency for development purposes, the right place is pyproject.toml directly.

Suggestions

• The PR description explicitly notes this must not be merged until ethyca/fideslang#39 is released. Consider adding a draft status or a blocking label to prevent accidental early merge, since there is no automated guard on this.
• The CHANGELOG entry is unchecked in the pre-merge checklist — if data_purposes support is user-facing, a changelog entry will be needed before merge.
• No application code changes accompany the dependency bump. Even if the new field flows through automatically via fideslang's Pydantic models, it would be worth adding or calling out at least one integration test that round-trips data_purposes at each level (dataset, collection, field, sub-field) to guard against regressions.

[github-actions]

Dependency Review

The following issues were found:

• ✅ 0 vulnerable package(s)

See the Details below.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA 4056b0e.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Scanned Files

• uv.lock