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

Airflow not shown on device view if only set on the devicetype #8845

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

Originally created by @PieterL75 on GitHub (Nov 16, 2023).

NetBox version

v3.6.5

Python version

3.10

Steps to Reproduce

  1. Create a devicetype without an airflow
  2. Create a device, based on that devicetype, but leave the airflow undefined
  3. update the devicetype and set an airflow
  4. Open the device page

Expected Behavior

If no airflow is set on the device, but one is set on the devicetype, then the airflow of the devicetype should be shown in the deviceview

Observed Behavior

The airflow is a 'placeholder' (dashes).
it only shows when the airflow is set on the device.

Originally created by @PieterL75 on GitHub (Nov 16, 2023). ### NetBox version v3.6.5 ### Python version 3.10 ### Steps to Reproduce 1. Create a devicetype without an airflow 2. Create a device, based on that devicetype, but leave the airflow undefined 3. update the devicetype and set an airflow 4. Open the device page ### Expected Behavior If no airflow is set on the device, but one is set on the devicetype, then the airflow of the devicetype should be shown in the deviceview ### Observed Behavior The airflow is a 'placeholder' (dashes). it only shows when the airflow is set on the device.
adam added the type: featurepending closurestatus: under reviewcomplexity: medium labels 2025-12-29 20:42:00 +01:00
adam closed this issue 2025-12-29 20:42:00 +01:00
adam commented 2025-12-29 20:42:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 28, 2023):

If no airflow is set on the device, but one is set on the devicetype, then the airflow of the devicetype should be shown in the deviceview

This gets a little murky. The device view is showing the value of the device's own airflow field, which happens to be null. While I understand the assumption that this value should "default" to the setting on the assigned device type, this would be dangerous and inaccurate without some canonical logic in place to make that connection. For instance, looking at the device view alone, how would you know if you're seeing the airflow value of the device itself or of the device type? And what if they're both set to different values?

I see a couple options:

  1. Leave the display as-is, and modify the device creation form to default the airflow field to an "inherit" option, which would automatically replicate the new device's airflow field to the value set on the device type. (We'd still want to retain an option for "none" as well.)
  2. Establish some property which represents the inferred value, preferring the local airflow value but defaulting to the device type's airflow value. This would need to be conveyed via the API as well.
@jeremystretch commented on GitHub (Nov 28, 2023): > If no airflow is set on the device, but one is set on the devicetype, then the airflow of the devicetype should be shown in the deviceview This gets a little murky. The device view is showing the value of the device's own `airflow` field, which happens to be null. While I understand the assumption that this value should "default" to the setting on the assigned device type, this would be dangerous and inaccurate without some canonical logic in place to make that connection. For instance, looking at the device view alone, how would you know if you're seeing the airflow value of the device itself or of the device type? And what if they're both set to different values? I see a couple options: 1. Leave the display as-is, and modify the device creation form to default the airflow field to an "inherit" option, which would automatically replicate the new device's `airflow` field to the value set on the device type. (We'd still want to retain an option for "none" as well.) 2. Establish some property which represents the inferred value, preferring the local `airflow` value but defaulting to the device type's `airflow` value. This would need to be conveyed via the API as well.
adam commented 2025-12-29 20:42:01 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Nov 29, 2023):

The second option comes closest to what I have in mind.
It kind of makes sense, that the device's airflow overrides the device type's airflow.
Maybe if this is clearly documented?

What does the current api call is a device gives you, when getting the airflow? When none is set on the device, or when the device has a different airflow than the device type

Pierer

@PieterL75 commented on GitHub (Nov 29, 2023): The second option comes closest to what I have in mind. It kind of makes sense, that the device's airflow overrides the device type's airflow. Maybe if this is clearly documented? What does the current api call is a device gives you, when getting the airflow? When none is set on the device, or when the device has a different airflow than the device type Pierer
adam commented 2025-12-29 20:42:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 7, 2023):

What does the current api call is a device gives you, when getting the airflow?

The API representation of a device will always show the value of its own airflow field.

I'm going to reclassify this as a feature request, as the current behavior is technically working as designed.

@jeremystretch commented on GitHub (Dec 7, 2023): > What does the current api call is a device gives you, when getting the airflow? The API representation of a device will always show the value of its own `airflow` field. I'm going to reclassify this as a feature request, as the current behavior is technically working as designed.
adam commented 2025-12-29 20:42:02 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Aug 22, 2024):

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 (Aug 22, 2024): 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:42:02 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 21, 2024):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Sep 21, 2024): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
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: medium pending closure status: under review 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#8845
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?