[Django] #36555: Allow null for LogEntry.user

8 views
Skip to first unread message

Django

unread,
Aug 15, 2025, 5:02:58 AM8/15/25
to django-...@googlegroups.com
#36555: Allow null for LogEntry.user
------------------------+-----------------------------------------
Reporter: Siburg | Type: New feature
Status: new | Component: contrib.admin
Version: dev | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------+-----------------------------------------
The `user` attribute of `LogEntry` is currently required. That causes two
problems for me:
1. I have admin actions that can be performed by users as well as by
periodically scheduled tasks (think Celery). For the latter case I now
have to `get_or_create` a proxy user record for the `LogEntry` for that
action. For example:
{{{
proxy_user, created = User.objects.get_or_create(
username='DataScrubTask',
defaults={'first_name': 'Proxy user for LogEntry records from
"archive_and_scrub_records" task'},
)
}}}
2. When a user who took an admin action is deleted then the admin history
is effectively corrupted. Because of the `CASCADE` for `LogEntry.user`,
their actions are deleted from the history.

To eliminate those problems I propose to add `blank=True, null=True` to
the `user` field definition, and change `CASCADE` to `SET_NULL`.

To provide more flexibility for tracking actions, I also propose to add a
`CharField` that can contain a text representation of who or what
performed the action.

I have created a preliminary, incomplete PR to show my proposed approach.
I will gladly continue work on that if this proposal is accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/36555>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Aug 15, 2025, 5:05:31 AM8/15/25
to django-...@googlegroups.com
#36555: Allow null for LogEntry.user
-------------------------------+--------------------------------------
Reporter: Siburg | Owner: (none)
Type: New feature | Status: closed
Component: contrib.admin | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Sarah Boyce):

* resolution: => wontfix
* status: new => closed

Comment:

Hi Siburg, thank you for the suggestion!

When suggesting a new feature for Django, the feature idea should first be
proposed and discussed with the community. To do that, please raise this
on the [https://github.com/django/new-features/issues ​new feature
tracker].

I'll close the ticket for now, but if the community agrees with the
proposal, please return to this ticket and reference the forum discussion
so we can re-open it. For more information, please refer to
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#requesting-features the documented guidelines for requesting
features].

Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/36555#comment:1>

Django

unread,
Aug 15, 2025, 5:12:31 AM8/15/25
to django-...@googlegroups.com
#36555: Allow null for LogEntry.user
-------------------------------+--------------------------------------
Reporter: Siburg | Owner: (none)
Type: New feature | Status: closed
Component: contrib.admin | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Description changed by Siburg:

Old description:

> The `user` attribute of `LogEntry` is currently required. That causes two
> problems for me:
> 1. I have admin actions that can be performed by users as well as by
> periodically scheduled tasks (think Celery). For the latter case I now
> have to `get_or_create` a proxy user record for the `LogEntry` for that
> action. For example:
> {{{
> proxy_user, created = User.objects.get_or_create(
> username='DataScrubTask',
> defaults={'first_name': 'Proxy user for LogEntry records from
> "archive_and_scrub_records" task'},
> )
> }}}
> 2. When a user who took an admin action is deleted then the admin history
> is effectively corrupted. Because of the `CASCADE` for `LogEntry.user`,
> their actions are deleted from the history.
>
> To eliminate those problems I propose to add `blank=True, null=True` to
> the `user` field definition, and change `CASCADE` to `SET_NULL`.
>
> To provide more flexibility for tracking actions, I also propose to add a
> `CharField` that can contain a text representation of who or what
> performed the action.
>
> I have created a preliminary, incomplete PR to show my proposed approach.
> I will gladly continue work on that if this proposal is accepted.

New description:

The `user` attribute of `LogEntry` is currently required. That causes two
problems for me:
1. I have admin actions that can be performed by users as well as by
periodically scheduled tasks (think Celery). For the latter case I now
have to `get_or_create` a proxy user record for the `LogEntry` for that
action. For example:
{{{
proxy_user, created = User.objects.get_or_create(
username='DataScrubTask',
defaults={'first_name': 'Proxy user for LogEntry records from
"archive_and_scrub_records" task'},
)
}}}
2. When a user who took an admin action is deleted then the admin history
is effectively corrupted. Because of the `CASCADE` for `LogEntry.user`,
their actions are deleted from the history.

To eliminate those problems I propose to add `blank=True, null=True` to
the `user` field definition, and change `CASCADE` to `SET_NULL`.

To provide more flexibility for tracking actions, I also propose to add a
`CharField` that can contain a text representation of who or what
performed the action.

I have created a preliminary, incomplete PR
[https://github.com/django/django/pull/19731] to show my proposed
approach. I will gladly continue work on that if this proposal is
accepted.

--
--
Ticket URL: <https://code.djangoproject.com/ticket/36555#comment:2>

Django

unread,
Sep 26, 2025, 12:27:46 PM9/26/25
to django-...@googlegroups.com
#36555: Allow null for LogEntry.user
-------------------------------+--------------------------------------
Reporter: Siburg | Owner: (none)
Type: New feature | Status: closed
Component: contrib.admin | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Carsten Fuchs):

* cc: Carsten Fuchs (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/36555#comment:3>
Reply all
Reply to author
Forward
0 new messages