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

Enable image attachments for device types #7005

New Issue
Closed
opened 2025-12-29 19:47:41 +01:00 by adam · 8 comments
adam commented 2025-12-29 19:47:41 +01:00
Owner
Copy Link

Originally created by @jcralbino on GitHub (Sep 20, 2022).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.3.4

Feature type

Change to existing functionality

Proposed functionality

Currently in the device type, we are allowing the introduction of two types of images:

  • rear image. Used for the rack rendering
  • front image. Used for the rack rendering

[ ]The Device Type "Front" and "Rear" images have a very limited scope as we want those images to be super high-quality or detailed (as they are used in the Rack Elevation and get shrunk down fairly small anyway, plus you want them to be perfectly straight-on for the Rack Elevation view).

  • I propose that within the device type we also introduce a generic image field, that is then copied to every new device created using this template.

Use case

Image inside the device are used to provide additional relevant information for each device, improving the documentation on site and the utilisation of this information with non technical people

  • a generic image of a device can be helpful to describe various aspects about the equipment to them, and is much better than "no images at all."

Database changes

  • adding a new field in the device-type data model referring to the image. As used in the device itself.

External dependencies

No response

Originally created by @jcralbino on GitHub (Sep 20, 2022). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.3.4 ### Feature type Change to existing functionality ### Proposed functionality Currently in the device type, we are allowing the introduction of two types of images: - rear image. Used for the rack rendering - front image. Used for the rack rendering [ ]The Device Type "Front" and "Rear" images have a very limited scope as we want those images to be super high-quality or detailed (as they are used in the Rack Elevation and get shrunk down fairly small anyway, plus you want them to be perfectly straight-on for the Rack Elevation view). - I propose that within the device type we also introduce a generic image field, that is then copied to every new device created using this template. ### Use case Image inside the device are used to provide additional relevant information for each device, improving the documentation on site and the utilisation of this information with non technical people - a generic image of a device can be helpful to describe various aspects about the equipment to them, and is much better than "no images at all." ### Database changes - adding a new field in the device-type data model referring to the image. As used in the device itself. ### External dependencies _No response_
adam added the status: acceptedtype: feature labels 2025-12-29 19:47:41 +01:00
adam closed this issue 2025-12-29 19:47:41 +01:00
adam commented 2025-12-29 19:47:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 26, 2022):

I'm sorry but I don't follow exactly what it is you're proposing, or why. Please rewrite your proposal above to clearly convey the proposed change and cited use case.

@jeremystretch commented on GitHub (Sep 26, 2022): I'm sorry but I don't follow exactly what it is you're proposing, or why. Please rewrite your proposal above to clearly convey the proposed change and cited use case.
adam commented 2025-12-29 19:47:42 +01:00
Author
Owner
Copy Link

@ZPrimed commented on GitHub (Sep 30, 2022):

I think I understand what the OP is asking for here - they're asking for a generic "image" field on a Device Type that would automatically be inherited by (copied into) all Device instances that are spawned from that Device Type. Device already allows Image uploads which is great for documenting devices in situ, but in the real world, we don't always have a photo of the specific device we're talking about.

This sort of thing is incredibly useful when you're dealing with "non-technical remote hands" (i.e. end-users) - a generic image of a device can be helpful to describe various aspects about the equipment to them, and is much better than "no images at all."

The Device Type "Front" and "Rear" images aren't even necessarily the best for this kind of "generic picture," since you don't really want those images to be super high-quality or detailed (as they are used in the Rack Elevation and get shrunk down fairly small anyway, plus you want them to be perfectly straight-on for the Rack Elevation view).

Sure, you can always search the web for a generic image, but a lot of person-hours can be saved in aggregate if someone takes a few minutes to put a quality generic image into the DCIM when creating the Device Type. Needing to duplicate / re-attach that image to every Device instance is a pain, and it would be nice to have some way to provide a generic and have it apply to everything spawned from the Type.

I have no clue how feasible this is, but I definitely think it would be helpful.

@ZPrimed commented on GitHub (Sep 30, 2022): I think I understand what the OP is asking for here - they're asking for a generic "image" field on a `Device Type` that would automatically be inherited by (copied into) all `Device` instances that are spawned from that `Device Type`. `Device` already allows Image uploads which is great for documenting devices *in situ*, but in the real world, we don't always have a photo of the specific device we're talking about. This sort of thing is incredibly useful when you're dealing with "non-technical remote hands" (i.e. end-users) - a generic image of a device can be helpful to describe various aspects about the equipment to them, and is much better than "no images at all." The `Device Type` "Front" and "Rear" images aren't even necessarily the best for this kind of "generic picture," since you don't really *want* those images to be super high-quality or detailed (as they are used in the Rack Elevation and get shrunk down fairly small anyway, plus you want them to be perfectly straight-on for the Rack Elevation view). Sure, you can always search the web for a generic image, but a lot of person-hours can be saved in aggregate if someone takes a few minutes to put a *quality* generic image into the DCIM when creating the `Device Type`. Needing to duplicate / re-attach that image to every `Device` instance is a pain, and it would be nice to have some way to provide a generic and have it apply to everything spawned from the `Type`. I have no clue how feasible this is, but I definitely think it would be helpful.
adam commented 2025-12-29 19:47:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 30, 2022):

We could add support for generic image attachments to the DeviceType model, but I don't see any reason for anything more complex than that. At any rate, let's wait for @jcralbino to clarify his intent.

@jeremystretch commented on GitHub (Sep 30, 2022): We could add support for generic image attachments to the DeviceType model, but I don't see any reason for anything more complex than that. At any rate, let's wait for @jcralbino to clarify his intent.
adam commented 2025-12-29 19:47:47 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Oct 1, 2022):

I have changed slightly the text in the initial request but the goal is aligned with what was explained by @ZPrimed

@jcralbino commented on GitHub (Oct 1, 2022): I have changed slightly the text in the initial request but the goal is aligned with what was explained by @ZPrimed
adam commented 2025-12-29 19:47:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 4, 2022):

I propose that within the device type we also introduce a generic image field, that is then copied to every new device created using this template.

There is no need to copy this field's value to instantiated devices, because each device already has a relationship to the device type: What is true for one instance is true for all.

As I mentioned, we could introduce support for attaching images to device types, which seems like it would satisfy your use case. If it does not, please elaborate on why.

@jeremystretch commented on GitHub (Oct 4, 2022): > I propose that within the device type we also introduce a generic image field, that is then copied to every new device created using this template. There is no need to copy this field's value to instantiated devices, because each device already has a relationship to the device type: What is true for one instance is true for all. As I mentioned, we could introduce support for attaching images to device types, which seems like it would satisfy your use case. If it does not, please elaborate on why.
adam commented 2025-12-29 19:47:48 +01:00
Author
Owner
Copy Link

@jcralbino commented on GitHub (Oct 7, 2022):

As long as the images associated with the device type are also seen under the device view also that would work

@jcralbino commented on GitHub (Oct 7, 2022): As long as the images associated with the device type are also seen under the device view also that would work
adam commented 2025-12-29 19:47:48 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jan 2, 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 2, 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 19:47:48 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 6, 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 (Apr 6, 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).
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: 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#7005
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?