[Django] #18957: Add next/previous buttons when editing a model in the admin site
Django
-------------------------------+--------------------
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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 ?
--
Ticket URL: <https://code.djangoproject.com/ticket/18957>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
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 thikonom):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:1>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by palkeo):
* cc: palkeo (added)
Comment:
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 ?
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:2>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by thikonom):
Yes.
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:3>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by palkeo):
If I try to make a patch by myself, will it possibly be included in Django
?
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:4>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by ptone):
Replying to [comment:4 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/
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:5>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (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 ?
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:6>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:7>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by lrekucki):
* stage: Unreviewed => Accepted
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:8>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by lrekucki):
* cc: lrekucki (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:9>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 1.4
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by palkeo):
Now that the bug #6903 is fixed, I think these buttons should be fairly
easy to add :)
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:10>
Django
Reporter: palkeo | Owner: nobody
Type: New feature | Status: closed
Component: contrib.admin | Version: 1.4
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => fixed
Comment:
This was resolved by #27728, which allowed overriding admin templatetag's
templates.
--
Ticket URL: <https://code.djangoproject.com/ticket/18957#comment:11>