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

Regression from APISelect option optimization #3113

New Issue
Closed
opened 2025-12-29 18:25:46 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:25:46 +01:00
Owner
Copy Link

Originally created by @hSaria on GitHub (Jan 3, 2020).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.6.8
  • NetBox version: 2.6.10

Steps to Reproduce

  1. Go to IP addresses page (/ipam/ip-addresses/)
  2. Only the filter form, select a VRF

There are multiple places that this is happening at. This is one example.

Following #3812, it seems I messed up some APISelect-based fields and I'm still unsure what's affected and what's not (I'll put a comment with more info).

Expected Behavior

The list of VRFs is shown

Observed Behavior

Select is stuck at Searching...

Originally created by @hSaria on GitHub (Jan 3, 2020). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.6.8 * NetBox version: 2.6.10 ### Steps to Reproduce 1. Go to IP addresses page (`/ipam/ip-addresses/`) 2. Only the filter form, select a VRF There are multiple places that this is happening at. This is one example. Following #3812, it seems I messed up some APISelect-based fields and I'm still unsure what's affected and what's not (I'll put a comment with more info). ### Expected Behavior The list of VRFs is shown ### Observed Behavior Select is stuck at `Searching...`
adam added the type: bugstatus: accepted labels 2025-12-29 18:25:46 +01:00
adam closed this issue 2025-12-29 18:25:46 +01:00
adam commented 2025-12-29 18:25:46 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 3, 2020):

This seems to be related to the null option not being present, or rather no options being present at all.

Firstly, if you make the following change, the VRF field and most others start working:

--- a/netbox/utilities/templates/widgets/select_api.html
+++ b/netbox/utilities/templates/widgets/select_api.html
@@ -1,5 +1,5 @@
 <select name="{{ widget.name }}"{% include "django/forms/widgets/attrs.html" %}>{% for group_name, group_choices, group_index in widget.opt
-  <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected %}
+  <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected or widget.value == "null" %}
   {% include widget.template_name %}{% endif %}{% endfor %}{% if group_name %}
   </optgroup>{% endif %}{% endfor %}
 </select>

However, there is still at least one field that I found not working: the Rack group field in Racks (/dcim/racks/) and I have no idea why that one specifically is there.

I'm not 100% sure, but I think any static options (API will not return) will need to be put into the page (not filtered by the template). If it is just the null option that is always the exception, then the above diff will fix it, but if there instances where we mix multiple static options with an APISelect-based field, the patch won't work.

But again, the patch above still doesn't fix the Rack group field in Racks, and I can't figure out why.

@hSaria commented on GitHub (Jan 3, 2020): This _seems_ to be related to the null option not being present, or rather no options being present at all. Firstly, if you make the following change, the VRF field and most others start working: ```diff --- a/netbox/utilities/templates/widgets/select_api.html +++ b/netbox/utilities/templates/widgets/select_api.html @@ -1,5 +1,5 @@ <select name="{{ widget.name }}"{% include "django/forms/widgets/attrs.html" %}>{% for group_name, group_choices, group_index in widget.opt - <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected %} + <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected or widget.value == "null" %} {% include widget.template_name %}{% endif %}{% endfor %}{% if group_name %} </optgroup>{% endif %}{% endfor %} </select> ``` However, there is still _at least_ one field that I found not working: the `Rack group` field in Racks (`/dcim/racks/`) and I have no idea why that one specifically is there. I'm not 100% sure, but I think any static options (API will not return) will need to be put into the page (not filtered by the template). If it is just the null option that is always the exception, then the above diff will fix it, but if there instances where we mix multiple static options with an APISelect-based field, the patch won't work. But again, the patch above still doesn't fix the `Rack group` field in Racks, and I can't figure out why.
adam commented 2025-12-29 18:25:46 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 3, 2020):

I think I found out why rack groups wasn't working: the default option has no value, so this fixes it

--- a/netbox/utilities/templates/widgets/select_api.html
+++ b/netbox/utilities/templates/widgets/select_api.html
@@ -1,5 +1,5 @@
 <select name="{{ widget.name }}"{% include "django/forms/widgets/attrs.html" %}>{% for group_name, group_choices, group_index in widget.optgroups %}{% if group_name %}
-  <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected %}
+  <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected or widget.value == "null" or not widget.value %}
   {% include widget.template_name %}{% endif %}{% endfor %}{% if group_name %}
   </optgroup>{% endif %}{% endfor %}
 </select>

I don't know if this is the best or most efficient solution considering I'm accounting for two exception manually

@hSaria commented on GitHub (Jan 3, 2020): I think I found out why rack groups wasn't working: the default option has no value, so this fixes it ```diff --- a/netbox/utilities/templates/widgets/select_api.html +++ b/netbox/utilities/templates/widgets/select_api.html @@ -1,5 +1,5 @@ <select name="{{ widget.name }}"{% include "django/forms/widgets/attrs.html" %}>{% for group_name, group_choices, group_index in widget.optgroups %}{% if group_name %} - <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected %} + <optgroup label="{{ group_name }}">{% endif %}{% for widget in group_choices %}{% if widget.attrs.selected or widget.value == "null" or not widget.value %} {% include widget.template_name %}{% endif %}{% endfor %}{% if group_name %} </optgroup>{% endif %}{% endfor %} </select> ``` **I don't know if this is the best or most efficient solution considering I'm accounting for two exception manually**
adam commented 2025-12-29 18:25:47 +01:00
Author
Owner
Copy Link

@hoalex commented on GitHub (Jan 3, 2020):

This is also happening on the Devices page when trying to filter for a specific rack.

@hoalex commented on GitHub (Jan 3, 2020): This is also happening on the `Devices` page when trying to filter for a specific rack.
adam commented 2025-12-29 18:25:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 3, 2020):

Going to stick with option.value == "null" for now, until we have time to do some thorough cleanup around the select widgets. RackFilter.group_id (and possibly other fields) need to be changed to FilterChoiceField to populate null values correctly.

@jeremystretch commented on GitHub (Jan 3, 2020): Going to stick with `option.value == "null"` for now, until we have time to do some thorough cleanup around the select widgets. `RackFilter.group_id` (and possibly other fields) need to be changed to FilterChoiceField to populate `null` values correctly.
adam commented 2025-12-29 18:25:47 +01:00
Author
Owner
Copy Link

@hSaria commented on GitHub (Jan 3, 2020):

@jeremystretch thanks for fixing and sorry for the mess.

@hSaria commented on GitHub (Jan 3, 2020): @jeremystretch thanks for fixing and sorry for the mess.
adam commented 2025-12-29 18:25:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 3, 2020):

@hSaria No worries, I didn't catch it either.

@jeremystretch commented on GitHub (Jan 3, 2020): @hSaria No worries, I didn't catch it either.
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 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#3113
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?