starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

filterable drop-downs only populate with MAX_PAGE_SIZE items #5127

New Issue
Closed
opened 2025-12-29 19:24:32 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:24:32 +01:00
Owner
Copy Link

Originally created by @maznu on GitHub (Jul 31, 2021).

Originally assigned to: @thatmattlove on GitHub.

NetBox version

v3.0-beta1

Python version

3.7

Steps to Reproduce

  1. Create more than MAX_PAGE_SIZE VLANs (e.g. MAX_PAGE_SIZE=50, create vids 1-100)
  2. Edit an interface
  3. Try to assign access VLAN e.g. 66 to that interface
  4. Realise that you cannot, because only MAX_PAGE_SIZE VLANs were loaded in, and vid 66 is in page 2

Expected Behavior

Either (a) document MAX_PAGE_SIZE to say that this should be at least as big as the largest number of items you'd expect to see in one of these drop-down widgets (ugly kludge?)

or (b) while a "next" is returned by the API to the UI JS code, XHR to fetch that page and append it to list of options gathered so far

Observed Behavior

  1. Can only assign e.g. VLANs in the first MAX_PAGE_SIZE results.
  2. Worse: if you have already assigned e.g. tagged VLANs to a port, and then added more VLANs to your IPAM, potentially the first page of /api/ipam/vlans isn't going to return all the VLANs you've already got assigned — so if you go to edit e.g. MTU of the interface, the UI fetches VLANs, removes ones not in the first page of API results from the currently tagged VLANs on the interface, with detrimental results when you click "save".
Originally created by @maznu on GitHub (Jul 31, 2021). Originally assigned to: @thatmattlove on GitHub. ### NetBox version v3.0-beta1 ### Python version 3.7 ### Steps to Reproduce 1. Create more than MAX_PAGE_SIZE VLANs (e.g. MAX_PAGE_SIZE=50, create vids 1-100) 2. Edit an interface 3. Try to assign access VLAN e.g. 66 to that interface 4. Realise that you cannot, because only MAX_PAGE_SIZE VLANs were loaded in, and vid 66 is in page 2 ### Expected Behavior Either (a) document MAX_PAGE_SIZE to say that this should be at least as big as the largest number of items you'd expect to see in one of these drop-down widgets (ugly kludge?) or (b) while a "next" is returned by the API to the UI JS code, XHR to fetch that page and append it to list of options gathered so far ### Observed Behavior 1. Can only assign e.g. VLANs in the first MAX_PAGE_SIZE results. 2. Worse: if you have already assigned e.g. tagged VLANs to a port, and then added more VLANs to your IPAM, potentially the first page of /api/ipam/vlans isn't going to return all the VLANs you've already got assigned — so if you go to edit e.g. MTU of the interface, the UI fetches VLANs, removes ones not in the first page of API results from the currently tagged VLANs on the interface, with detrimental results when you click "save".
adam added the type: bugstatus: acceptedbeta labels 2025-12-29 19:24:32 +01:00
adam closed this issue 2025-12-29 19:24:32 +01:00
adam commented 2025-12-29 19:24:33 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Aug 1, 2021):

When was the last time you pulled down the beta to test this? I just tested on the latest commit (2613722) and I cannot reproduce this issue. I created 60 new VLANs for a site, edited an interface on a device assigned to that site, and I see all 60 of the VLANs I created as well as others that already existed. I do remember this being a bug in the API select element (limit=0 was not set), but that was a while ago.

@thatmattlove commented on GitHub (Aug 1, 2021): When was the last time you pulled down the beta to test this? I just tested on the latest commit (2613722) and I cannot reproduce this issue. I created 60 new VLANs for a site, edited an interface on a device assigned to that site, and I see all 60 of the VLANs I created as well as others that already existed. I do remember this being a bug in the API select element (`limit=0` was not set), but that was a while ago.
adam commented 2025-12-29 19:24:33 +01:00
Author
Owner
Copy Link

@maznu commented on GitHub (Aug 1, 2021):

Bug was from running the released beta cb804eb3e1 rather than a more recent commit. Will check out whether this has been fixed in a more recent commit.

@maznu commented on GitHub (Aug 1, 2021): Bug was from running the released beta https://github.com/netbox-community/netbox/commit/cb804eb3e16d1a03e0fe98276fdf1613e000dcaf rather than a more recent commit. Will check out whether this has been fixed in a more recent commit.
adam commented 2025-12-29 19:24:33 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Aug 4, 2021):

@maznu update?

@thatmattlove commented on GitHub (Aug 4, 2021): @maznu update?
adam commented 2025-12-29 19:24:33 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 4, 2021):

I think the key here is that the MAX_PAGE_SIZE configuration parameter defaults to 1000. Since the REST API call to populate the dropdown widget appends ?limit=0, this will return up to 1000 items by default, but no more. So the issue arises when MAX_PAGE_SIZE is less than the total number of items matching the API query.

or (b) while a "next" is returned by the API to the UI JS code, XHR to fetch that page and append it to list of options gathered so far

This is essentially how the current implementation works. Rather than appending ?limit=0, it uses the default page size and automatically fetches additional items once the user scrolls to the end of the list (if a next URL has been included with the response). I think ideally we would replicate this behavior.

Alternatively, where the total number of items is greater than the number returned, we could require the user to type something into the filter box, and generate a new API call to filter the returned objects. This would probably work just as well, since once you're dealing with that many items it's likely you'll want to filter by string anyway.

@jeremystretch commented on GitHub (Aug 4, 2021): I think the key here is that the `MAX_PAGE_SIZE` configuration parameter defaults to 1000. Since the REST API call to populate the dropdown widget appends `?limit=0`, this will return up to 1000 items by default, but no more. So the issue arises when `MAX_PAGE_SIZE` is less than the total number of items matching the API query. > or (b) while a "next" is returned by the API to the UI JS code, XHR to fetch that page and append it to list of options gathered so far This is essentially how the current implementation works. Rather than appending `?limit=0`, it uses the default page size and automatically fetches additional items once the user scrolls to the end of the list (if a `next` URL has been included with the response). I think ideally we would replicate this behavior. Alternatively, where the total number of items is greater than the number returned, we could require the user to type something into the filter box, and generate a new API call to filter the returned objects. This would probably work just as well, since once you're dealing with that many items it's likely you'll want to filter by string anyway.
adam commented 2025-12-29 19:24:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 18, 2021):

@thatmattlove this looks great, thanks! The list of options is automatically populated when the user reaches the end of the list (and a next URL was provided in the previous API response), and new items are populated when searching within the widget. Perfect.

My only suggestion at this point would be to omit the ?limit=0 from the API request, and instead rely on inference of the configured PAGINATE_COUNT. This will avoid pulling down e.g. a thousand objects when a user intends to search for a specific object anyway.

If you're in agreement, I'm happy to make the change myself.

@jeremystretch commented on GitHub (Aug 18, 2021): @thatmattlove this looks great, thanks! The list of options is automatically populated when the user reaches the end of the list (and a `next` URL was provided in the previous API response), and new items are populated when searching within the widget. Perfect. My only suggestion at this point would be to omit the `?limit=0` from the API request, and instead rely on inference of the configured `PAGINATE_COUNT`. This will avoid pulling down e.g. a thousand objects when a user intends to search for a specific object anyway. If you're in agreement, I'm happy to make the change myself.
adam commented 2025-12-29 19:24:34 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Aug 18, 2021):

@jeremystretch I actually tried to do that before pushing 664b02d, but it resulting in some goofy behavior. However, after re-testing again locally, I can't reproduce it. It's possible I fixed it inadvertently. Go for it!

@thatmattlove commented on GitHub (Aug 18, 2021): @jeremystretch I actually tried to do that before pushing 664b02d, but it resulting in some goofy behavior. However, after re-testing again locally, I can't reproduce it. It's possible I fixed it inadvertently. Go for it!
adam commented 2025-12-29 19:24:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 18, 2021):

Cool. Looks like we're good to go on this one. Thanks again, @thatmattlove!

@jeremystretch commented on GitHub (Aug 18, 2021): Cool. Looks like we're good to go on this one. Thanks again, @thatmattlove!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label beta status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5127
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?