Opened 7 years ago
Closed 7 years ago
#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 )
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 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 7 years ago
Description: | modified (diff) |
---|
follow-up: 4 comment:3 by , 7 years ago
comment:4 by , 7 years ago
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 by , 7 years ago
Resolution: | → needsinfo |
---|---|
Status: | assigned → closed |
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!
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.