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

[palkeo]

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 ?

[thikonom]

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.

[palkeo]

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 ?

[thikonom]

Yes.

[palkeo]

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

[Preston Holmes]

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/

[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 ?

[Preston Holmes]

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.

[Łukasz Rekucki]

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.

[palkeo]

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

[Carlton Gibson]

This was resolved by #27728, which allowed overriding admin templatetag's templates.