Respect Dag-specific read access in graph structure endpoint

[Vamsi-klu]

The graph/structure payload endpoint now authorizes against the requested Dag with normal Dag read access. This fixes the #62532 task group detail failure because that UI path loads /ui/structure/structure_data?dag_id=...; users with read access to only Dag:<dag_id> can fetch the structure payload for that Dag without requiring global Dag read access.

Access to unreadable Dags remains denied. External dependency data is still gated separately and only requests dependency access when external_dependencies=true.

closes: #62532

Tests:

• SKIP_BREEZE_SELF_UPGRADE_CHECK=true breeze run --answer n --skip-image-upgrade-check pytest airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_should_allow_structure_data_with_dag_specific_read airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_should_deny_structure_data_for_unreadable_dag airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_external_dependencies_requires_dependency_access airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_external_dependencies_allows_dag_specific_read_with_dependency_access -xvs --with-db-init - 4 passed, 1 warning

---

Was generative AI tooling used to co-author this PR?

• Yes - Codex (GPT-5)

Generated-by: Codex (GPT-5) following the guidelines

[pierrejeambrun]

LGTM, just one question / adjustment to make regarding the TI permission check.

[Vamsi-klu]

Rebased onto current main — the earlier merge conflict is resolved (kept the new 400-on-malformed-asset-expression response from #67489 and scoped the access check so DAG-specific read users can load the task-group view per #62532). 29 structure tests pass; ruff, mypy-airflow-core, and the full pre-commit stage are green. Ready for review.

---

Drafted-by: Claude Code (Opus 4.8); reviewed by @Vamsi-klu before posting

[pierrejeambrun]

This PR doesn't seem to fix what it claims it is:

closes: #62532

Which is about task groups, while this PR targets structure endpoint.

Closing for now unless you can provide more context, fix the description and title. ("Fix task group view", this PR isn't about task group view, but graph view, this is too confusing and looks like unchecked AI generated stuff)

stale

[Vamsi-klu]

Thanks for the correction. I updated the title and description to target the graph/structure endpoint directly, not the task group view. The connection to #62532 is that the task group route loads /ui/structure/structure_data?dag_id=...; the previous wording made that indirect relationship too confusing.

I rechecked the current branch at 678502bf951b88f5151af95f43d82cb57c27adbf with Breeze and did not force-push:

SKIP_BREEZE_SELF_UPGRADE_CHECK=true breeze run --answer n --skip-image-upgrade-check pytest airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_should_allow_structure_data_with_dag_specific_read airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_should_deny_structure_data_for_unreadable_dag airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_external_dependencies_requires_dependency_access airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_structure.py::TestStructureDataEndpoint::test_external_dependencies_allows_dag_specific_read_with_dependency_access -xvs --with-db-init

Result: 4 passed, 1 warning.

Those tests cover the intended boundary: a user with read access to only Dag:<dag_id> gets a 200 for that Dag's structure payload, an unreadable Dag returns 403, and external dependency data still requires dependency access when external_dependencies=true.

Could you reopen this PR for review? If you prefer, I can also open a fresh PR with the corrected title and description.

[pierrejeambrun]

@Vamsi-klu between this and some other of yours PR, this starts to sound like AI low quality spamming.

Please follow the project contribution guidelines, abusing AI is not helping the project and lowering the trust maintainers have in your work, that can also get you blocked from the repository if you do not adjust.

Feel free to re-open a clean PR addressing the issue. You are responsible for your AI generated code, make sure you double check it and manually verify your PR fixes the issue.

Do not re-open a PR if you are not willing to spend (as a human) the time and effort necessary to guarantee your PR meets the project standards.