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

Airflow inheritance when creating a device (not on save) #11200

New Issue
Open
opened 2025-12-29 21:41:52 +01:00 by adam · 4 comments
adam commented 2025-12-29 21:41:52 +01:00
Owner
Copy Link

Originally created by @larsen0815 on GitHub (May 19, 2025).

NetBox version

v4.3.1

Feature type

Change to existing functionality

Proposed functionality

The value for "airflow" should be fetched from a device type and used as the default value for the airflow of a new device to be created (as it already is), and also be shown before the new device is saved.

Use case

When a device type has set a value for "airflow", and a device of that type is instantiated, the value for "airflow" is still shown as "-------" and only gets the value (e.g. "passive") when the device is saved.

When you don't know that it works this way, you wonder why the form for creating a device doesn't show the value from the device type you created before. This led me to believe this to be buggy. Also, you cannot see what the value will be after saving, and only then might notice that in this case the airflow is different and needs to be changed.

Database changes

No response

External dependencies

No response

Originally created by @larsen0815 on GitHub (May 19, 2025). ### NetBox version v4.3.1 ### Feature type Change to existing functionality ### Proposed functionality The value for "airflow" should be fetched from a device type and used as the default value for the airflow of a new device to be created (as it already is), and also be shown before the new device is saved. ### Use case When a device type has set a value for "airflow", and a device of that type is instantiated, the value for "airflow" is still shown as "-------" and only gets the value (e.g. "passive") when the device is saved. When you don't know that it works this way, you wonder why the form for creating a device doesn't show the value from the device type you created before. This led me to believe this to be buggy. Also, you cannot see what the value will be after saving, and only then might notice that in this case the airflow is different and needs to be changed. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurestatus: needs ownernetboxcomplexity: low labels 2025-12-29 21:41:52 +01:00
adam commented 2025-12-29 21:41:52 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 22, 2025):

I don't think it's feasible to automatically populate the airflow form field, but we could add a note to the field's help text indicating that the value will be inherited from the device type if not explicitly set.

@jeremystretch commented on GitHub (May 22, 2025): I don't think it's feasible to automatically populate the airflow form field, but we could add a note to the field's help text indicating that the value will be inherited from the device type if not explicitly set.
adam commented 2025-12-29 21:41:52 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (May 22, 2025):

Indeed the help text could just reflect the value of the device type and say "This is the value that will be set if left blank".

@bctiemann commented on GitHub (May 22, 2025): Indeed the help text could just reflect the value of the device type and say "This is the value that will be set if left blank".
adam commented 2025-12-29 21:41:53 +01:00
Author
Owner
Copy Link

@larsen0815 commented on GitHub (May 23, 2025):

Out of curiosity: Why wouldn't it be feasible?

@larsen0815 commented on GitHub (May 23, 2025): Out of curiosity: Why wouldn't it be feasible?
adam commented 2025-12-29 21:41:53 +01:00
Author
Owner
Copy Link

@De-Backer commented on GitHub (Aug 15, 2025):

Try looking at it from another perspective.

Why are we setting “airflow” as a value in the device type?
If you still have to enter it manually when creating a device?

Another point, can the “airflow” of a device even change?

@De-Backer commented on GitHub (Aug 15, 2025): Try looking at it from another perspective. Why are we setting “airflow” as a value in the device type? If you still have to enter it manually when creating a device? Another point, can the “airflow” of a device even change?
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 complexity: low netbox status: needs owner type: feature
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#11200
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?