Display owner_display_name in Audit Log

[VladaZakharova]

In Breeze / community Airflow, there are several types of auth managers that have different sets of fields, which actually leads to different data stored to DB about the user.
The default auth manager is usually SimpleAuthManager. It only knows simple login data like:

• username
• role
• password

For example:
username: admin
role: admin
password: admin

So in default Breeze, the new column will look the same as old one:
User: admin.
User Display Name: admin.

The other one that can be also used is FAB manager. Available fields are:

• username
• first_name
• last_name
• email
• password
• role

The common solution will be for different auth managers like this:

   If first_name and last_name exist:
       show "first_name last_name"

   Else if email exists:
       show "email"

   Else:
       show "username"

Example:
first_name = Jane.
last_name = Smith.
email = jane@example.com.
username = jane.

User = jane.
User Display Name = Jane Smith.

Or:
first_name = empty.
last_name = empty.
email = jane@example.com.
username = jane.

User = jane.
User Display Name = jane@example.com.

This change will make the Audit log more informative for users.
Example how it will look like:

The change is implemented as a new Column in Audit Logs tab, which can be also hidden in side menu by user, if preferred to not be shown.

---

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

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

---

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

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

---

Important

🛠️ Maintainer triage note for @VladaZakharova · by @potiuk · 2026-07-11 14:59 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed (see our Pull Request quality criteria):

• ❌ Pre-commit / static checks. See docs.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[pierrejeambrun]

Thanks for the pull request.

CI need fixing (e2e tests).

Also I'm not sure about this, because there are plenty of other Log creation path and most of them do not populate the owner_display_name field. _add_log, task execution events, task fail/skip/running, scheduler events (scheduler_job_runner.py), buffered task events, asset events.

I'm afraid that showing this will highlight an inconsistent attribute. (None most of the time, unless it's created by the API layer). I wouldn't show this to the UI users unless we fix all the event creation path to properly populate the owner_display_name attribute.

[VladaZakharova]

Thanks, I agree that showing the raw stored Log.owner_display_name would be inconsistent today.

I’ll adjust the PR so owner_display_name is resolved at read time in the event-log API response instead of relying on every Log(...) creation path to populate it. The API can use Log.owner to look up the matching Airflow user by username/email and return a best-effort display name, falling back to the stored owner_display_name or owner when needed. Like this:

UI column = log.owner_display_name OR user lookup from log.owner OR log.owner

[pierrejeambrun]

A few things to address below

[Lee-W]

rebased from the main branch for the latest CI fix

[amoghrajesh]

Needs some more work.

[amoghrajesh]

Hello @VladaZakharova, will you be able to take a look at the comments? I have rebased it.

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 48dc012 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[amoghrajesh]

owner and owner_display_name are both set from the same user.get_name() call in https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/api_fastapi/logging/decorators.py#L87-L164. So they will always be identical, no path where they diverge. Been true since owner_display_name was added, so this will not work.

[pierrejeambrun]

I think we need a follow up PR, working on that.

[VladaZakharova]

@pierrejeambrun
Wow, thank you for your help here, really :)
I was on sick leave and didn't have time to finish the work, but with your impact it is done, thank you again!