Opened 3 years ago

Last modified 22 months ago

#18957 new New feature

Add next/previous buttons when editing a model in the admin site

Reported by: palkeo Owned by: nobody
Component: contrib.admin Version: 1.4
Severity: Normal Keywords:
Cc: palkeo, lrekucki Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hi,

I am working on a project that rely on the admin site to manage the website.

I've had an interesting feedback from my users : Sometime they need to review all the objects that are in the DB for a certain model, and arbitrarily modify some of them.
So, it will make their life easier if they can directly look through all the models by using « next/previous » buttons, to go from the page to modify an object, to the page to modify the next/previous object in the DB.

So I suggest adding two buttons (next/previous) on the admin page to modify an object, that will link to the page to modify the object with the next/previous primary key in the DB.
These buttons may only be explicitly enabled via a parameter in the ModelAdmin (?)

What do you think about this idea ?

Change History (10)

comment:1 Changed 3 years ago by thikonom

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I think it could potentially be useful to have these buttons, but i don't really think its we should modify the ModelAdmin class for this specific feature.

comment:2 Changed 3 years ago by palkeo

  • Cc palkeo added

Thanks for your comment.
If an option is not added to the ModelAdmin class, how will this feature be enabled ? Do you think it just have to be enabled by default ?

comment:3 Changed 3 years ago by thikonom

Yes.

comment:4 follow-up: Changed 3 years ago by palkeo

If I try to make a patch by myself, will it possibly be included in Django ?

comment:5 in reply to: ↑ 4 Changed 3 years ago by ptone

Replying to palkeo:

If I try to make a patch by myself, will it possibly be included in Django ?

Patches are merged based on their quality and relevance.

In this case I think the feature is harder to implement than you may be thinking. From a UX point of view, a prev/next interface would need access in some way to the most recent list view. If you have a found set, or a filtered list, the expectation is that the next/prev would be the next/prev from that list of objects, not simply the next/prev based on a numeric ID.

By all means if you want to tackle this, give it a shot - you may wish to review the contributing docs to become more familiar with what is expected of a patch.

https://docs.djangoproject.com/en/dev/internals/contributing/

comment:6 Changed 3 years ago by palkeo

Interesting, I didn't though of that.
So, this raises two more questions :

Even if it is far from perfect, do you think it may be possible to have a (perhaps optional ?) prev/next functionality that will just be based on the object ID ? Or do I have to abandon that idea ?

If I try to implement it based on the previous list of objects that was used, I suppose I will have to do something like storing the IDs of the last list of objects in a session (or storing the parameters used to create its queryset). Isn't that too complicated or time/memory consuming for such a simple feature ?

comment:7 Changed 3 years ago by ptone

I'd be -1 on including an incomplete implementation that just uses the pk - if you need just this for your project, you can implement it in your own code without needing changes in Django.contrib.admin, its been done.

I'm not informed enough about the admin to get into a discussion on how to implement this, but I'd argue that it is probably not a "simple" feature. But one wouldn't know until you start diving in.

comment:8 Changed 3 years ago by lrekucki

  • Triage Stage changed from Unreviewed to Accepted

The idea sounds great, but I suspect it will be very hard to make a generic solution. Storing a list of IDs in a session is non-starter, because it can be huge. You don't need to store the queryset parameters in session, because you have them all in the URL used to generate the list page. I guess this could work a bit like paging, but with page size always equal to 1. And to avoid constantly making the same query, the client could fetch a batch of ids and then switch with AJAX.

comment:9 Changed 3 years ago by lrekucki

  • Cc lrekucki added

comment:10 Changed 22 months ago by palkeo

Now that the bug #6903 is fixed, I think these buttons should be fairly easy to add :)

Note: See TracTickets for help on using tickets.
Back to Top