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

Invalid value assigned to "Global" option for VRF field in IP address form #5289

New Issue
Closed
opened 2025-12-29 19:26:15 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:26:15 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Sep 1, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0.0

Python version

3.7

Steps to Reproduce

  1. Navigate to IPAM > IP addresses > Add
  2. Attempt to create an IP address with no VRF assigned (i.e. Global)

Expected Behavior

The IP address should be created successfully.

Observed Behavior

A ValueError exception is raised due to an invalid value for the vrf field:

Exception Type: ValueError at /ipam/ip-addresses/add/
Exception Value: Field 'id' expected a number but got 'Global'.

If we inspect the DOM, we can see that a literal value of Global has been erroneously set for the "Global" option (it should have a null value):

<option value="Global">Global</option>

This is being set by the frontend, but I haven't been able to narrow down exactly where. I suspect it might be related to the change in 093a86bc38 for #7081.

Originally created by @jeremystretch on GitHub (Sep 1, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0.0 ### Python version 3.7 ### Steps to Reproduce 1. Navigate to IPAM > IP addresses > Add 2. Attempt to create an IP address with no VRF assigned (i.e. Global) ### Expected Behavior The IP address should be created successfully. ### Observed Behavior A ValueError exception is raised due to an invalid value for the `vrf` field: ``` Exception Type: ValueError at /ipam/ip-addresses/add/ Exception Value: Field 'id' expected a number but got 'Global'. ``` If we inspect the DOM, we can see that a literal value of `Global` has been erroneously set for the "Global" option (it should have a null value): ``` <option value="Global">Global</option> ``` This is being set by the frontend, but I haven't been able to narrow down exactly where. I suspect it might be related to the change in 093a86bc3819d453f96f886aeea711c76f53fd89 for #7081.
adam added the type: bugstatus: accepted labels 2025-12-29 19:26:15 +01:00
adam closed this issue 2025-12-29 19:26:15 +01:00
adam commented 2025-12-29 19:26:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 1, 2021):

I've worked around this temporarily for v3.0.1 in 6f9419893 by removing the "Global" placeholder from all VRF fields. However, I still want to resolve the underlying issue to ensure that we properly support the empty_label attribute on form fields.

@jeremystretch commented on GitHub (Sep 1, 2021): I've worked around this temporarily for v3.0.1 in 6f9419893 by removing the "Global" placeholder from all VRF fields. However, I still want to resolve the underlying issue to ensure that we properly support the `empty_label` attribute on form fields.
adam commented 2025-12-29 19:26:16 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Sep 2, 2021):

Handling of empty_label is now implemented in API Select, however, due to an issue with SlimSelect, it doesn't actually work. Issue brianvoe/slim-select#293 and PR brianvoe/slim-select#294 have been submitted to fix this, but they've sat untouched for quite a while. As a result, I've opened brianvoe/slim-select#308 to inquire as to the status of the project.

When I first started working on the jQuery removal, it was pretty close to the recent commits on SlimSelect's develop branch, so I assumed the project was active. However, depending on their answer, we may need to look into alternative options. Sadly, there just aren't many libraries that meet the criteria:

  • Vanilla JS, no framework requirement
  • Sass styling
  • Actively maintained

ChoicesJS was the next closest, and I actually started with that one. However, the ChoicesJS maintainer isn't maintaining that project, either (and there were issues with the styling API, IIRC).

After taking another look, TomSelect (a fork of Selectize.js that drops jQuery and adds some other interesting features) looks like a potential option.

If there are no other viable alternatives, we may need to consider forking Slim Select and modifying as needed. There could be some benefits to that approach - there are a lot of duplicated actions in our implementation due to shortcomings in SlimSelect's API. But on the flip side, there are all the drawbacks of maintaining a separate project.

@thatmattlove commented on GitHub (Sep 2, 2021): Handling of `empty_label` is now implemented in API Select, however, due to an issue with SlimSelect, it doesn't actually work. Issue brianvoe/slim-select#293 and PR brianvoe/slim-select#294 have been submitted to fix this, but they've sat untouched for quite a while. As a result, I've opened brianvoe/slim-select#308 to inquire as to the status of the project. When I first started working on the jQuery removal, it was pretty close to the recent commits on SlimSelect's `develop` branch, so I assumed the project was active. However, depending on their answer, we may need to look into alternative options. Sadly, there just aren't many libraries that meet the criteria: - Vanilla JS, no framework requirement - Sass styling - Actively maintained [ChoicesJS](https://github.com/Choices-js/Choices) was the next closest, and I actually started with that one. However, the ChoicesJS maintainer isn't maintaining that project, either (and there were issues with the styling API, IIRC). After taking another look, [TomSelect](https://github.com/orchidjs/tom-select) (a fork of [Selectize.js](https://selectize.dev/) that drops jQuery and adds some other interesting features) looks like a potential option. If there are no other viable alternatives, we may need to consider forking Slim Select and modifying as needed. There could be some benefits to that approach - there are a lot of duplicated actions in our implementation due to shortcomings in SlimSelect's API. But on the flip side, there are all the drawbacks of maintaining a separate project.
adam commented 2025-12-29 19:26:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 2, 2021):

Thanks, Matt. At this point I think we're okay to just acknowledge it as a limitation of the current solution. With the "Global" label omitted from VRF assignment widgets, we're no longer using empty_label anywhere, so there's no impact. It'll just be something to bear in mind for future work.

@jeremystretch commented on GitHub (Sep 2, 2021): Thanks, Matt. At this point I think we're okay to just acknowledge it as a limitation of the current solution. With the "Global" label omitted from VRF assignment widgets, we're no longer using `empty_label` anywhere, so there's no impact. It'll just be something to bear in mind for future work.
adam commented 2025-12-29 19:26:16 +01:00
Author
Owner
Copy Link

@thatmattlove commented on GitHub (Sep 2, 2021):

It sounds like the project still has life in it, the maintainer says they've been working on a new version. We shall see.

@thatmattlove commented on GitHub (Sep 2, 2021): It sounds like the project still has life in it, the maintainer says they've been working on a new version. We shall see.
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#5289
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?