Opened 3 years ago

Closed 10 months ago

#15176 closed New feature (fixed)

History view of AdminSite doesn't take in account user defined queryset

Reported by: t2y Owned by: nobody
Component: contrib.admin Version: 1.2
Severity: Normal Keywords: multi-db
Cc: info@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no


I found a bug which does not show history view in AdminSite when I defined a queryset for multi-db.

# see also:

The history_view method of django.contrib.admin.ModelAdmin give a model object to get_object_or_404 as an argument. In that case, normal queryset of the model is used even if user defined custom queryset for the model. It means that the history view isn't showed for multi-db since it define custom queryset.

I made a patch, but I have no idea for making tests code. I only tested after I did some table operation, and I confirmed the history view.

Additionally, you might wonder about the LogEntry(django_admin_log). I think it's no problem since I can handle LogEntry to read/write with db-router.

Attachments (1)

get_history_view_with_user_defined_queryset.patch (661 bytes) - added by t2y 3 years ago.
Patch to use self.queryset instead of model

Download all attachments as: .zip

Change History (11)

Changed 3 years ago by t2y

Patch to use self.queryset instead of model

comment:1 Changed 3 years ago by russellm

  • Component changed from ORM aggregation to django.contrib.admin
  • Needs documentation unset
  • Needs tests set
  • Owner set to nobody
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 3 years ago by anonymous

I actually feel divided about this. The history is supposed to show all the things that have been changed/added/deleted in the past. Using a custom queryset means that the history may change over time, which seem kind of weird. I do recognise that there might be cases where we do want a custom queryset to be used, but I also think that in some other cases we might actually want the default one to be used. So I'd be in favour of a more granular system for the history view.

comment:3 Changed 3 years ago by julien

Sorry, that was me just above.

comment:4 Changed 3 years ago by lrekucki

  • Severity set to Normal
  • Type set to New feature

comment:5 Changed 3 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

comment:11 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:12 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:13 Changed 19 months ago by brocaar

I think there might be an other case where it is expected that history_view is using the custom queryset set by the user. I'm currently working on an app where users can only see a subset of data in the admin depending on the groups they are in. By creating a custom queryset method on the ModelAdmin, this works great for listing and editing and I was expected that this would work for history as well (since the history button is visible on item level). However, the user has access to the history of all the items by changing the id in the url.

comment:14 Changed 19 months ago by brocaar

  • Cc info@… added

comment:15 Changed 10 months ago by julien

  • Resolution set to fixed
  • Status changed from new to closed

This was fixed as part of #21013.

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.