feat: Data API (rescued from dev before reset)

[rdahis]

Purpose

Rescue the Data API backend work onto a main-based branch before dev is reset.

The feature was developed in Feb–May 2025 and never reached production: its commits exist only on origin/dev, which diverged from main under the old workflow and is scheduled to be reset. The data_api app is present on neither main nor staging.

Draft on purpose. Per Git Flow this must be validated via PRs into development and staging first. Those will be opened once the branches are reset; this PR stays in draft until then and merges into main last.

Description

11 commits cherry-picked with -x from origin/dev, oldest→newest, original authorship preserved:

commit	subject
435b250	feat: data API (read from previous PRs and commits before dev reset)
bdd3ba3	fix: search_views, list tables
0fc037f	fix: allow any table and column in endpoints
ec6adf8	chore: view return endpoint cloud table
49598f2	chore: parameter to search for columns
3cc6056	chore: enlarge column search
51f6df0	chore: return endpoint parameters
f865310	fix: rename migration to be consistent with newer one
2111338	fix: is_required, limit choices
4e3adb6	fix: admin show bool endpoint table
021d080	feat: change credits with hashed API key

Adds the data_api app (models, admin, GraphQL, views, URLs, decorators, translation) and wires it into INSTALLED_APPS, the GraphQL schema, and root URLs. Adds Dataset.contains_data_api_endpoint_tables and Table.is_data_api_endpoint, with the corresponding search index field and a search filter excluding endpoint-only datasets.

Includes a model rename

435b250 also carries Key → DictionaryKey in api/v1, plus migration 0056. This is kept deliberately: the new data_api app defines its own Key model, and without the rename Django admin shows two separate "Keys" sections. There is no database-level collision (data_api.Key defaults to table data_api_key; v1.Key used keys), so this is a clarity change rather than a required one — but 0056 renames a live table, which is the main thing to scrutinise here.

Conflict resolutions worth reviewing

main has moved substantially since these commits. Conflicts were resolved surgically rather than by taking the incoming side wholesale, which would have reverted main's work (e.g. admin.py drifted 227+/41−, search_views.py 199+/117−).

• api/v1/models.py — all 5 conflicts were main-side caching/formatting drift with no Data API content; main kept in full.
• api/v1/search_views.py — applied only the exclude(...) filter; deliberately did not restore the DEBUG: Form data print() block that main removed.
• api/v1/admin.py — kept main's trimmed field lists, adding only the Data API entries.
• apps/schema.py — registered data_api while keeping main's UserNotificationQuery.
• migrations/0054_alter_organization_area.py — kept main's copy; the two differed only in a header comment.

Migration chain lands cleanly: data_api/0001 depends on v1.0054 and 0056 depends on 0055, both already on main.

Checklist

• I have reviewed the code changes.
• I have tested the changes locally.
• I have updated the documentation if needed.
• I have added/modified tests to ensure the changes are valid.

Testing and evidence

Verified so far: all changed Python files compile; no conflict markers remain; migration dependency chain resolves against main. Not yet run: migrations against a database, or the test suite. Both should happen on the development PR.

Next steps

1. Hold in draft until dev is reset.
2. Open PRs into development and staging; validate there — in particular the 0056 table rename.
3. Merge into main last.

Paired with the website-side PR in basedosdados/website.

🤖 Generated with Claude Code