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

Edit ip address - change device assignment, doesnt clear interface assignment. causes confusion #7163

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

Originally created by @ITJamie on GitHub (Oct 26, 2022).

Originally assigned to: @DanSheps on GitHub.

NetBox version

v3.3.5

Python version

3.10

Steps to Reproduce

  1. goto an ip address with an existing assignment, eg https://demo.netbox.dev/ipam/ip-addresses/186/
  2. edit the ip address, change the vm or device assignment, eg from vm1 to vm2.
  3. Notice that interface field below still says eth0
    (its not obvious but that eth0 field is still set to eth0 on vm1, not eth0 on vm2 which is selected above)
  4. user saves form, result is accepted. however interface assignment is still set to vm1 - eth0.

Expected Behavior

I would expect that at step 2 once the device or vm relationship was changed that the interfaces field would empty out

OR

that during the save process data validation would fail and tell the user that the device / virtual machine assignment + interface are not part of the same device.

OR

maybe the interface assignment (eth0) should also have the vm or device name listed after it? making it obvious that the field above didnt change anything and is just a filter?

Observed Behavior

assignment does not change in netbox. user gets no warning that there was a conflict or no change made

Originally created by @ITJamie on GitHub (Oct 26, 2022). Originally assigned to: @DanSheps on GitHub. ### NetBox version v3.3.5 ### Python version 3.10 ### Steps to Reproduce 1. goto an ip address with an existing assignment, eg https://demo.netbox.dev/ipam/ip-addresses/186/ 2. edit the ip address, change the vm or device assignment, eg from vm1 to vm2. 3. Notice that interface field below still says eth0 (its not obvious but that eth0 field is still set to eth0 on vm1, not eth0 on vm2 which is selected above) 4. user saves form, result is accepted. however interface assignment is still set to vm1 - eth0. ### Expected Behavior I would expect that at step 2 once the device or vm relationship was changed that the interfaces field would empty out OR that during the save process data validation would fail and tell the user that the device / virtual machine assignment + interface are not part of the same device. OR maybe the interface assignment (eth0) should also have the vm or device name listed after it? making it obvious that the field above didnt change anything and is just a filter? ### Observed Behavior assignment does not change in netbox. user gets no warning that there was a conflict or no change made
adam added the type: bugstatus: accepted labels 2025-12-29 20:19:57 +01:00
adam closed this issue 2025-12-29 20:19:58 +01:00
adam commented 2025-12-29 20:19:58 +01:00
Author
Owner
Copy Link

@a084ed22 commented on GitHub (Oct 27, 2022):

From experience, the device/virtual machine dropdowns are meant to be only filters for the respective interface field. Only the interface field matters in terms of association with the IP, therefore just changing the virtual machine won't result in any change to the association.

@a084ed22 commented on GitHub (Oct 27, 2022): From experience, the device/virtual machine dropdowns are meant to be only filters for the respective interface field. Only the interface field matters in terms of association with the IP, therefore just changing the virtual machine won't result in any change to the association.
adam commented 2025-12-29 20:19:59 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Oct 27, 2022):

This is a common issue with fields that filter other fields. The obvious solution would be to clear dependent fields after updating the parent. Not sure if there are any usability issues to consider though.

Code for the API select fields can be found here if anyone wants to give it a shot:

https://github.com/netbox-community/netbox/blob/develop/netbox/project-static/src/select/api/apiSelect.ts

@kkthxbye-code commented on GitHub (Oct 27, 2022): This is a common issue with fields that filter other fields. The obvious solution would be to clear dependent fields after updating the parent. Not sure if there are any usability issues to consider though. Code for the API select fields can be found here if anyone wants to give it a shot: https://github.com/netbox-community/netbox/blob/develop/netbox/project-static/src/select/api/apiSelect.ts
adam commented 2025-12-29 20:19:59 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Nov 8, 2022):

Another (quicker) option would be to also show the name of the attached device/vm in brackets after the interface name.

Eg right now it just shows "eth0" but it could show "eth0 (device1)" in the interface name field. It would at least make it slightly more obvious that the data didnt update when you change the field above

@ITJamie commented on GitHub (Nov 8, 2022): Another (quicker) option would be to also show the name of the attached device/vm in brackets after the interface name. Eg right now it just shows "eth0" but it could show "eth0 (device1)" in the interface name field. It would at least make it slightly more obvious that the data didnt update when you change the field above
adam commented 2025-12-29 20:19:59 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Nov 15, 2022):

something like this

apiSelect.ts
add on line 604:

    // Remove the existing select option, as the parent changed, and the current selected options is not relevant to the new parent
    this.resetOptions()

This will remove the data of a child selection if the parent has changed value.

I have a branch ready with this change
https://github.com/PieterL75/netbox/tree/issue10757_clearchilselectlist
If the idea is ok, then I'll create a PR form it

@PieterL75 commented on GitHub (Nov 15, 2022): something like this apiSelect.ts add on line 604: ``` // Remove the existing select option, as the parent changed, and the current selected options is not relevant to the new parent this.resetOptions() ``` This will remove the data of a child selection if the parent has changed value. I have a branch ready with this change https://github.com/PieterL75/netbox/tree/issue10757_clearchilselectlist If the idea is ok, then I'll create a PR form it
adam commented 2025-12-29 20:19:59 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (Nov 17, 2022):

My worry about doing it for every parent child field is that in some cases the current logic is actually useful.

Eg if your editing an interfaces vlan tags. I have several interfaces where there are vlans in multiple different vlan groups that need to be tagged on one interface.

So with the change above if i changed the vlan group to find another vlan i need to tag on that interface, it would clear out the existing tagged vlans.

@ITJamie commented on GitHub (Nov 17, 2022): My worry about doing it for every parent child field is that in some cases the current logic is actually useful. Eg if your editing an interfaces vlan tags. I have several interfaces where there are vlans in multiple different vlan groups that need to be tagged on one interface. So with the change above if i changed the vlan group to find another vlan i need to tag on that interface, it would clear out the existing tagged vlans.
adam commented 2025-12-29 20:19:59 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Nov 17, 2022):

interesting one.. so it should only clear on singlevalue dropdowns and not al the time..

and still then.. if you selected an untagged vlan from groupA and added some tagged, then got to groupB, the untagged vlan is cleared too..

Looks like this will need to be an option to either always-clear-except; or never-clear-except

@PieterL75 commented on GitHub (Nov 17, 2022): interesting one.. so it should only clear on singlevalue dropdowns and not al the time.. and still then.. if you selected an untagged vlan from groupA and added some tagged, then got to groupB, the untagged vlan is cleared too.. Looks like this will need to be an option to either always-clear-except; or never-clear-except
adam commented 2025-12-29 20:19:59 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 17, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Jan 17, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:20:00 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Mar 21, 2023):

maybe, the element that is displayed in the list needs to show more information.
Currently you only see the value of the listiems (ex eth1, eth1, eth2, eth2, ...)

What if the list is dependent on another list, then show that too.
VM1/Eth1
VM2/Eth2
VM1/Eth1
VM2/Eth2.

Then the current logic can remain, but the confusion on what the relation of the Eth1 is to the parent is more clear

@PieterL75 commented on GitHub (Mar 21, 2023): maybe, the element that is displayed in the list needs to show more information. Currently you only see the value of the listiems (ex eth1, eth1, eth2, eth2, ...) What if the list is dependent on another list, then show that too. VM1/Eth1 VM2/Eth2 VM1/Eth1 VM2/Eth2. Then the current logic can remain, but the confusion on what the relation of the Eth1 is to the parent is more clear
adam commented 2025-12-29 20:20:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2023):

@DanSheps why did you mark this as blocked?

@jeremystretch commented on GitHub (May 2, 2023): @DanSheps why did you mark this as blocked?
adam commented 2025-12-29 20:20:00 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 2, 2023):

No idea, might have been by accident

@DanSheps commented on GitHub (May 2, 2023): No idea, might have been by accident
adam commented 2025-12-29 20:20:00 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 2, 2023):

There is an identical one however that would be fixed by moving to the new filtering logic. I am willing to take both of those

@DanSheps commented on GitHub (May 2, 2023): There is an identical one however that would be fixed by moving to the new filtering logic. I am willing to take both of those
adam commented 2025-12-29 20:20:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 2, 2023):

What is the other issue? Can we consolidate them?

@jeremystretch commented on GitHub (May 2, 2023): What is the other issue? Can we consolidate them?
adam commented 2025-12-29 20:20:01 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 2, 2023):

Pretty sure you "just" closed it out: #11477

If we move to the new filtering mechanism, it would remove the "device assignment" all together, and make it clear that you can only assign an ip address to a interface.

@DanSheps commented on GitHub (May 2, 2023): Pretty sure you "just" closed it out: #11477 If we move to the new filtering mechanism, it would remove the "device assignment" all together, and make it clear that you can only assign an ip address to a interface.
adam commented 2025-12-29 20:20:01 +01:00
Author
Owner
Copy Link

@ITJamie commented on GitHub (May 2, 2023):

the new filtering mechanism should solve this right? https://twitter.com/jstretch85/status/1631677080252424192?s=20

@ITJamie commented on GitHub (May 2, 2023): the new filtering mechanism should solve this right? https://twitter.com/jstretch85/status/1631677080252424192?s=20
adam commented 2025-12-29 20:20:02 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 2, 2023):

Yeah, it should solve it.

@DanSheps commented on GitHub (May 2, 2023): Yeah, it should solve it.
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#7163
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?