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

DCIM.Devices: Platform gets cleared when device type is changed #10997

New Issue
Closed
opened 2025-12-29 21:38:58 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:38:58 +01:00
Owner
Copy Link

Originally created by @uedvt359 on GitHub (Apr 8, 2025).

Deployment Type

Self-hosted

NetBox Version

v4.2.6

Python Version

3.11

Steps to Reproduce

  1. Prepare a manufacturer (Mikrotik) and two device types from it (e.g RB450G, RB450Gx4) and a platform linked to the manufacturer (e.g. RouterOS)
  2. create a device with these values (e.g. Mikrotik RB450G, RouterOS)
  3. edit the device and switch device type (e.g. RB450G -> RB450Gx4)

Expected Behavior

Since the manufacturer has not changed, the platform is still valid and should have been preserved

Observed Behavior

the platform value was cleared

Originally created by @uedvt359 on GitHub (Apr 8, 2025). ### Deployment Type Self-hosted ### NetBox Version v4.2.6 ### Python Version 3.11 ### Steps to Reproduce 1. Prepare a manufacturer (`Mikrotik`) and two device types from it (e.g `RB450G`, `RB450Gx4`) and a platform linked to the manufacturer (e.g. `RouterOS`) 2. create a device with these values (e.g. `Mikrotik RB450G`, `RouterOS`) 3. edit the device and switch device type (e.g. `RB450G` -> `RB450Gx4`) ### Expected Behavior Since the manufacturer has not changed, the platform is still valid and should have been preserved ### Observed Behavior the platform value was cleared
adam added the type: bug label 2025-12-29 21:38:58 +01:00
adam closed this issue 2025-12-29 21:38:58 +01:00
adam commented 2025-12-29 21:38:59 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Apr 8, 2025):

Thanks for taking the time to file this issue and for the detailed repro steps.
I looked into it, and this is actually the expected behavior. Because a default platform can be bound to a device type, when you change the device type the system resets the platform to reflect the new device type’s defaults.

@pheus commented on GitHub (Apr 8, 2025): Thanks for taking the time to file this issue and for the detailed repro steps. I looked into it, and this is actually the expected behavior. Because a default platform can be bound to a device type, when you change the device type the system resets the platform to reflect the new device type’s defaults.
adam commented 2025-12-29 21:38:59 +01:00
Author
Owner
Copy Link

@uedvt359 commented on GitHub (Apr 8, 2025):

I looked into it, and this is actually the expected behavior. Because a default platform can be bound to a device type

yes, i'm aware.

, when you change the device type the system resets the platform to reflect the new device type’s defaults.

but it only makes sense to reset the platform when the device's manufacturer changes. if it stays the same, it doesn't need to get cleared.

i've chosen my example carefully: both are real device types. it's easily mis-selected when creating the device initially. when fixing it, another part of the form (which is way further down and therefore mostly out of view) gets cleared, even though the fields are still consistent.

@uedvt359 commented on GitHub (Apr 8, 2025): > I looked into it, and this is actually the expected behavior. Because a default platform can be bound to a device type yes, i'm aware. >, when you change the device type the system resets the platform to reflect the new device type’s defaults. but it only makes sense to reset the platform when the device's manufacturer changes. if it stays the same, it doesn't need to get cleared. i've chosen my example carefully: both are real device types. it's easily mis-selected when creating the device initially. when fixing it, another part of the form (which is way further down and therefore mostly out of view) gets cleared, even though the fields are still consistent.
adam commented 2025-12-29 21:39:00 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Apr 8, 2025):

That’s a fair point, and I totally understand the scenario you’re describing.

That said, there are also cases where a single manufacturer provides multiple distinct platforms — for example, Microsoft has both Windows and Windows Server, or Cisco with IOS-XE and NX-OS. In these cases, automatically preserving the platform when changing the device type could lead to inconsistencies.

@pheus commented on GitHub (Apr 8, 2025): That’s a fair point, and I totally understand the scenario you’re describing. That said, there are also cases where a single manufacturer provides multiple distinct platforms — for example, Microsoft has both Windows and Windows Server, or Cisco with IOS-XE and NX-OS. In these cases, automatically preserving the platform when changing the device type could lead to inconsistencies.
adam commented 2025-12-29 21:39:00 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Apr 8, 2025):

I think I agree with @pheus -- preserving the platform would be overly "helpful" and would be just as annoying in as many cases as clearing the platform might be today. I'm also pretty sure it's without precedent in the existing UI behaviors.

@bctiemann commented on GitHub (Apr 8, 2025): I think I agree with @pheus -- preserving the platform would be overly "helpful" and would be just as annoying in as many cases as clearing the platform might be today. I'm also pretty sure it's without precedent in the existing UI behaviors.
adam commented 2025-12-29 21:39:00 +01:00
Author
Owner
Copy Link

@uedvt359 commented on GitHub (Apr 9, 2025):

Sorry for not letting this go, but I really don't agree with your statements:

preserving the platform would be overly "helpful" and would be just as annoying in as many cases as clearing the platform might be today. I'm also pretty sure it's without precedent in the existing UI behaviors.

I think it's "overly helpful" to clear the platform, and I don't think there is another example of mostly unrelated fields interacting like this.
Take a look at the edit form of a device: These two fields are so far apart, that I could hardly fit them on one fullscreen browser window. They are also in different sections: Device type is in 'hardware', while Platform is in 'management'. The only other fields that interact like that are clearly related and right next to each other in the GUI, like region/site/location/rack and tenant-group/tenant.

Image

@uedvt359 commented on GitHub (Apr 9, 2025): Sorry for not letting this go, but I really don't agree with your statements: > preserving the platform would be overly "helpful" and would be just as annoying in as many cases as clearing the platform might be today. I'm also pretty sure it's without precedent in the existing UI behaviors. I think it's "overly helpful" to clear the platform, and I don't think there is another example of mostly unrelated fields interacting like this. Take a look at the edit form of a device: These two fields are so far apart, that I could hardly fit them on one fullscreen browser window. They are also in different sections: Device type is in 'hardware', while Platform is in 'management'. The only other fields that interact like that are clearly related and right next to each other in the GUI, like region/site/location/rack and tenant-group/tenant. ![Image](https://github.com/user-attachments/assets/20250795-9860-409d-89c8-941ae0750111)
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 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#10997
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?