gingeekrishna opened a new pull request, #69095:
URL: https://github.com/apache/airflow/pull/69095
## Summary
`Log.owner_display_name` is stored in the database and populated by
`action_logging` from the auth manager user display value since Airflow 2.8.0
(via AIP-56), but was never returned by the `/api/v2/eventLogs` endpoint or
shown in the Audit Log UI.
Auth managers use `owner` as a stable principal identifier (e.g. `jsmith`,
an email, or an opaque ID) while `owner_display_name` holds the human-readable
display name (e.g. `John Smith`). Omitting `owner_display_name` from the API
forces API consumers and the Audit Log UI to show the raw identifier even when
a more readable name has already been stored.
### Changes
**API** (additive — `owner` field unchanged):
- Adds `owner_display_name: str | None` to `EventLogResponse`
- Adds `owner_display_name` exact-match filter
- Adds `owner_display_name_pattern` (ILIKE substring) filter
- Adds `owner_display_name_prefix_pattern` (index-friendly prefix) filter
- Adds `owner_display_name` to the allowed sort attributes
**UI**:
- Audit Log "User" column now renders `owner_display_name ?? owner` — shows
the human-readable name when present, falls back to `owner` when `null`
**OpenAPI / TypeScript**:
- `EventLogResponse` schema updated with `owner_display_name` property
- `GetEventLogsData` updated with the new filter parameters and updated
`orderBy` description
### Review comment responses
- **ashb** ("does this PR do anything other than create a field that is
never set anywhere?"): `owner_display_name` is already being set —
`action_logging` in
`airflow-core/src/airflow/api_fastapi/logging/decorators.py` (line 159) writes
`owner_display_name=user_display` on every logged request. The `Log.__init__`
column has existed since the 2.8.0 migration
(`0005_2_8_0_add_owner_display_name_to_audit_log_table.py`). This PR only
exposes it through the read path.
- **pierrejeambrun** ("needs `owner_display_name_prefix_pattern` and
`owner_display_name_pattern`"): Both are added in this PR alongside the
existing `owner_pattern`/`owner_prefix_pattern` pair.
- **Vamsi-klu** ("sorting and filtering still target `owner` while the
display shows `owner_display_name`"): The new filter/sort parameters operate on
`Log.owner_display_name` directly, so search and sort are consistent with the
displayed value.
### Data flow
```
DB (Log row)
owner = "jsmith"
owner_display_name = "John Smith"
│
▼
API (EventLogResponse)
{ "owner": "jsmith", "owner_display_name": "John Smith", ... }
│
▼
UI (Audit Log "User" column)
shows: owner_display_name ?? owner
→ "John Smith" (falls back to "jsmith" if display name is null)
```
### Security
Same access control as `owner` (gated by `requires_access_event_log("GET")`
plus per-DAG audit log permission). Same trust boundary — both fields are
populated by the auth manager. Same rendering path — React escapes the cell
content. Follows the existing `dag_display_name` / `task_display_name`
precedent in the same response model.
closes: #68334
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (claude-sonnet-4-6)
Generated-by: Claude Code (claude-sonnet-4-6) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
