Add support for owner links in UI

[tirkarthi]

Description

The feature was implemented in Airflow 2.4 to support hyperlink per owner. https://airflow.apache.org/docs/apache-airflow/stable/howto/add-owner-links.html

Use case/motivation

No response

Related issues

No response

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[choo121600]

I want to get assigned this issue👀

[choo121600]

I was assigned this issue and have looked into it. Previously, when the UI was based on Flask AppBuilder (FAB), we could retrieve the owner link using the following method:

{% if owner_links and owner.strip() in owner_links.get(dag.dag_id, {}) %}

However, now that the UI has been changed to React, this method no longer works."

Currently, we need to get this information via an API. However, the current endpoint used in the header (/api/v2/dags/{dag_id}/details) and the DAGDetailsResponse data model do not include any owner_link information.

To resolve this, we may need to update the API and data model to include this field. I’m considering updating the API response to include the owner link, or possibly adding a new endpoint if necessary. I would like to confirm this approach before proceeding.

[eladkal]

To resolve this, we may need to update the API and data model to include this field. I’m considering updating the API response to include the owner link, or possibly adding a new endpoint if necessary. I would like to confirm this approach before proceeding.

Updating sound more resonable than a new api but lets confirm with @bbovenzi or @pierrejeambrun

[bbovenzi]

Usability-wise, I think changing dag.owners in the rest api from an array of string to an array of dicts sounds reasonable to me: [{ name: 'owner_name', link: 'owner_link.com'}]

Problem is that it technically is a change to our public API response. @pierrejeambrun what do you think? We can at least change the /ui/dags endpoint. Is owner_link even something that should be exposed publicly or is it only relevant to the UI?

[pierrejeambrun]

Yes technically that's a breaking change, if we can get away by just updating ui/dags I think that should be enough.

In the near future when we incorporate cadwyn versioning to the public API, it will finally be possible to do such breaking change in the API. (old versions will still be accessible)

[choo121600]

@eladkal @bbovenzi @pierrejeambrun Thank you for your response.

In the current implementation, owner_links is stored as a dictionary like:

{ "owner_example": "https://example_link.com" }

Changing this to an array of dicts like:

[{ "name": "owner_example", "link": "https://example_link.com" }]

would technically be a significant structural change and a breaking change to our public API.

However, if we want to get the owner_links on the React UI,
I believe we need to include it in the DAGDetailsResponse from api_fastapi/core_api (/api/v2/dags/{dag_id}/details).
Without adding it there, there is no way for the UI to receive and render that information.

To maintain backward compatibility, it may be best to include owner_links in its current dictionary format, e.g.:

{ "owner_example": "https://example_link.com" }

{
  "dag_id": "test_dag",
  "dag_display_name": "test_dag",
  "is_paused": true,
  "is_stale": false,
  "last_parsed_time": "2025-05-13T09:34:11.534352Z",
  "last_expired": null,
  "bundle_name": "dags-folder",
  "bundle_version": null,
  "relative_fileloc": "testDag.py",
  "fileloc": "/files/dags/testDag.py",
  "description": null,
  "timetable_summary": "0 0 * * *",
  "timetable_description": "At 00:00",
  "tags": [
    {
      "name": "tag1",
      "dag_id": "test_dag"
    },
    {
      "name": "tag2",
      "dag_id": "test_dag"
    },
    {
      "name": "tag3",
      "dag_id": "test_dag"
    }
  ],
  "max_active_tasks": 16,
  "max_active_runs": 1,
  "max_consecutive_failed_dag_runs": 5,
  "has_task_concurrency_limits": false,
  "has_import_errors": false,
  "next_dagrun_logical_date": "2025-05-13T00:00:00Z",
  "next_dagrun_data_interval_start": "2025-05-13T00:00:00Z",
  "next_dagrun_data_interval_end": "2025-05-13T00:00:00Z",
  "next_dagrun_run_after": "2025-05-13T00:00:00Z",
  "owners": [
    "Test-User"
  ],
  "catchup": false,
  "dag_run_timeout": null,
  "asset_expression": null,
  "doc_md": "DAG to test the DAG API.",
  "start_date": "2025-03-01T00:00:00Z",
  "end_date": null,
  "is_paused_upon_creation": null,
  "params": {},
  "render_template_as_native_obj": false,
  "template_search_path": null,
  "timezone": "UTC",
  "last_parsed": "2025-05-13T09:11:05.291707Z",
  "default_args": {
    "owner": "Test-User",
    "retries": 3,
    "retry_delay": "PT30S"
  },
  "owner_links": {
    "Test-User": "https://airflow.apache.org"
  },
  "file_token": "eyJidW5kbGVfbmFtZSI6ImRhZ3MtZm9sZGVyIiwicmVsYXRpdmVfZmlsZWxvYyI6InRlc3REYWcucHkifQ.bMX_q57JLsdISUtbe6ho4XP7ZPc",
  "concurrency": 16,
  "latest_dag_version": {
    "id": "01969a4c-a2ce-7306-b550-afa6db7c81e7",
    "version_number": 1,
    "dag_id": "test_dag",
    "bundle_name": "dags-folder",
    "bundle_version": null,
    "created_at": "2025-05-04T07:57:15.854519Z",
    "bundle_url": null
  }
}

[pierrejeambrun]

To maintain backward compatibility, it may be best to include owner_links in its current dictionary format, e.g.:

Yes we can do that, and we can always modify later when cadwyn supports it.

OR we can consider this a bugfix and still do the change...