#29463 closed New feature (needsinfo)

add pagination to stacked inline and tabular inline

Reported by: oliver Owned by: oliver
Component: contrib.admin Version: 2.1
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by oliver)

Currently, inlines on the django admin page do not have pagination.
So, if there are too many tuple in the inline, page can't be loaded.
How about adding pagination to them?
I could develop the feature

Change History (5)

comment:1 Changed 13 months ago by oliver

Owner: changed from nobody to oliver
Status: newassigned

comment:2 Changed 13 months ago by oliver

Description: modified (diff)

comment:3 Changed 13 months ago by Matthew Schinckel

Something that springs to mind is that without having all of the data in the request, it's not really possible to infer what the user wants to keep, and what the user wants to delete.

comment:4 in reply to:  3 Changed 13 months ago by oliver

Replying to Matthew Schinckel:

So, i made this ticket because i want to know other people's opinion.

Something that springs to mind is that without having all of the data in the request, it's not really possible to infer what the user wants to keep, and what the user wants to delete.

comment:5 Changed 13 months ago by Carlton Gibson

Resolution: needsinfo
Status: assignedclosed

Hi @olivier.

At first glance this seems like a "Yeah, why not?" kind of suggestion. But it's not addressable in it's current state, so I'm going to mark it needsinfo.

Reason: Adding pagination here is not going to be simple. As such, it needs some idea of how it would be implemented to see if it's reasonable.

There's also a question at to whether it's worth the effort. Are users coming up against memory limits on inlines enough to justify the changes? (I don't know the answer to that.)

My suggestion is to look at `get_inline_instances()` and come up with a rough and brief outline of the changes that would be required to support pagination. (Pulling offset parameters from the request etc — what would the query string look like for that?, where would we process the form to validate that?, how would/could we leverage the existing pagination?, and so on.)

With that rough sketch in hand, I'd then post to the mailing list explaining the proposal and see if there was some appetite. (Better there than here, simple because you'll get some response there from the larger audience.) Assuming some uptake, we can then flesh out the description here and re-open with an eye to implementing it.

Thanks for the effort!

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