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

Show front and rear device images on device view #3451

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

Originally created by @JNR8 on GitHub (Mar 9, 2020).

Environment

  • Python version:
  • NetBox version: 2.7.8

Proposed Functionality

Within the device view, the front and rear images could be shown, if present, at the top of the device tab (or as appropriate). The feature could be toggled per device if it does not suit everyone.
Device View - Image Porposal

Use Case

The example image above should provide enough idea of what it could look like.

For the device view I currently make use of the comment field with markdown to render the front and rear images, which just feels a bit clunky. and as markdown cannot resize an image it makes it time consuming to resize each and every image manually before uploading.

Database Changes

none that I am aware of.

External Dependencies

No additional dependencies as far as I am aware.

Originally created by @JNR8 on GitHub (Mar 9, 2020). ### Environment * Python version: <!-- Example: 3.6.9 --> * NetBox version: 2.7.8 <!-- A request for enhancements, which feel minor in some ways, but could improve the overall look of the device view. --> ### Proposed Functionality Within the device view, the front and rear images could be shown, if present, at the top of the device tab (or as appropriate). The feature could be toggled per device if it does not suit everyone. ![Device View - Image Porposal](https://user-images.githubusercontent.com/4245161/75996800-4f158e80-5ef6-11ea-8774-58a80a947877.png) ### Use Case The example image above should provide enough idea of what it could look like. For the device view I currently make use of the comment field with markdown to render the front and rear images, which just feels a bit clunky. and as markdown cannot resize an image it makes it time consuming to resize each and every image manually before uploading. ### Database Changes none that I am aware of. <!-- No additional dependencies as far as I am aware. --> ### External Dependencies No additional dependencies as far as I am aware.
adam closed this issue 2025-12-29 18:29:15 +01:00
adam commented 2025-12-29 18:29:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 12, 2020):

This looks nice when you have high resolution, 1U images. It doesn't look so nice when you have small/low-resolution images, or large images for a 12U chassis.

Also, given that the device images are already included on the device type view, I don't think it makes sense to commit valuable screen space at the top of the device view.

@jeremystretch commented on GitHub (Mar 12, 2020): This looks nice when you have high resolution, 1U images. It doesn't look so nice when you have small/low-resolution images, or large images for a 12U chassis. Also, given that the device images are already included on the device type view, I don't think it makes sense to commit valuable screen space at the top of the device view.
adam commented 2025-12-29 18:29:16 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Mar 12, 2020):

A fair point.

Perhaps the images can be a toggle feature per device or device type. That way you can control weather the page gets taken over by the multi-U device images or not depending on your personal preference.
Perhaps it could also be done byt having the devices only diplay an images if that device is under a certain U hieght. This could be a variable set by the end user as per personal preference.

But to be honest, and this might just be me being a perfectionist, I would not be put a low res image of a device on a device type. I would either not have an image associated or put some kind of place holder image in place.

Additionally, the top of the page location is just a suggestion. Other locations could be suitable as well, such as above the comments field or above/below the inteface section.

@JNR8 commented on GitHub (Mar 12, 2020): A fair point. Perhaps the images can be a toggle feature per device or device type. That way you can control weather the page gets taken over by the multi-U device images or not depending on your personal preference. Perhaps it could also be done byt having the devices only diplay an images if that device is under a certain U hieght. This could be a variable set by the end user as per personal preference. But to be honest, and this might just be me being a perfectionist, I would not be put a low res image of a device on a device type. I would either not have an image associated or put some kind of place holder image in place. Additionally, the top of the page location is just a suggestion. Other locations could be suitable as well, such as above the comments field or above/below the inteface section.
adam commented 2025-12-29 18:29:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 13, 2020):

I'm working with two assumptions here:

  1. Most users probably know what the device looks like, or don't care.
  2. If they do need to see what the device looks like, a single click on the device type is a reasonable level of effort to get that information.

Absent a solid argument to either point, I don't see any value in piling any more content onto the device view, which is already fairly busy.

@jeremystretch commented on GitHub (Mar 13, 2020): I'm working with two assumptions here: 1. Most users probably know what the device looks like, or don't care. 2. If they *do* need to see what the device looks like, a single click on the device type is a reasonable level of effort to get that information. Absent a solid argument to either point, I don't see any value in piling any more content onto the device view, which is already fairly busy.
adam commented 2025-12-29 18:29:16 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Mar 13, 2020):

I can understand the point of view you have, and that you have a certain level of restraint for new features if they do not fit with what you feel is correct with your vision for the product.

Having said that, right now at the time of posting this comment, there seems to be an unofficial polling going on and more people seem to like the idea than not.

At what point would you consider implementing a user controllable cosmetic change (such as this), which does not detract from the overall vision of the product?

I know I have been wanting this feature for a years now, and have mentioned it a few times in other posts. With the addition of device type front and rear images recently, my sugestion seems like a natural continuence of this feature. Yes, some may not want this and some will. To cater for both it could be turned on or off per a user controllable setting. Win/Win.

Regards, point 2 in your reply. I, personally, do not consider having to click out of the device I am viewing to view an image of that device a logic work flow.

Personally, having all information for a device available on one single page is preferable than having to click through other pages. But, I do understand the need to keep the device page as tidy as possible. Which is why I think collapsable sections on the device view would be another cosmetic change that could poentially help and alow for more info at the users finger tips, with an understandable work flow.

@JNR8 commented on GitHub (Mar 13, 2020): I can understand the point of view you have, and that you have a certain level of restraint for new features if they do not fit with what you feel is correct with your vision for the product. Having said that, right now at the time of posting this comment, there seems to be an unofficial polling going on and more people seem to like the idea than not. At what point would you consider implementing a user controllable cosmetic change (such as this), which does not detract from the overall vision of the product? I know I have been wanting this feature for a years now, and have mentioned it a few times in other posts. With the addition of device type front and rear images recently, my sugestion seems like a natural continuence of this feature. Yes, some may not want this and some will. To cater for both it could be turned on or off per a user controllable setting. Win/Win. Regards, point 2 in your reply. I, personally, do not consider having to click out of the device I am viewing to view an image of that device a logic work flow. Personally, having all information for a device available on one single page is preferable than having to click through other pages. But, I do understand the need to keep the device page as tidy as possible. Which is why I think collapsable sections on the device view would be another cosmetic change that could poentially help and alow for more info at the users finger tips, with an understandable work flow.
adam commented 2025-12-29 18:29:16 +01:00
Author
Owner
Copy Link

@lukasodhner commented on GitHub (Mar 17, 2020):

I would be in favor of image support on the device page as shown above.
We will make the high photos ourselves but as above we probably won't actually take photos of each device. Therefore I would love to have support for Device Type photos that are easily accessible from each instance of that device so that I don't have to upload a copy of the same stock photo for each device.

@lukasodhner commented on GitHub (Mar 17, 2020): I would be in favor of image support on the device page as shown above. We will make the high photos ourselves but as above we probably won't actually take photos of each device. Therefore I would love to have support for Device Type photos that are easily accessible from each instance of that device so that I don't have to upload a copy of the same stock photo for each device.
adam commented 2025-12-29 18:29:16 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Mar 27, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Mar 27, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:29:16 +01:00
Author
Owner
Copy Link

@DouglasHeriot commented on GitHub (Apr 2, 2020):

I agree with @lukasodhner - maybe this should just be a feature request for uploading images associated with Device Types, rather than just Devices. I don't want to upload the same image for every instance of a device I have.

The current system of uploading images and having to click on them to see them is fine - but would be nice if they could belong on Device Types too.

@DouglasHeriot commented on GitHub (Apr 2, 2020): I agree with @lukasodhner - maybe this should just be a feature request for uploading images associated with Device Types, rather than just Devices. I don't want to upload the same image for every instance of a device I have. The current system of uploading images and having to click on them to see them is fine - but would be nice if they could belong on Device Types too.
adam commented 2025-12-29 18:29:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 2, 2020):

maybe this should just be a feature request for uploading images associated with Device Types

This has already been implemented in NetBox.

I'm closing this issue as I have not seen a strong argument in support of this proposal.

@jeremystretch commented on GitHub (Apr 2, 2020): > maybe this should just be a feature request for uploading images associated with Device Types This has already been implemented in NetBox. I'm closing this issue as I have not seen a strong argument in support of this proposal.
adam commented 2025-12-29 18:29:17 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Apr 2, 2020):

@DouglasHeriot You can do what you have asked or already, which is why this feature request came to be. Each device type can have its own front and rear images. My request was to have the ability to toggle on/off the display of those images when viewing a device. Curently you cannot see these images when viewing a device, which seems like a missed opportunity to me.

Yes you can upload individual images for Front and Rear for each device and mouse over them to view them, or click them to open another window to see the larger images. But the mouse over view it too small (any larger and it would look weird though) and opening another tab/window to view the image of the device seems unecessary.

Right now you cannot view the Front or Rear images assigned to a device type when you view a device. You can see them on the Rack elevations view, but thats it. Being able to view them in a device created from the Device Type seems like a logical continuence of this feature. To not do this seems like a lack of consistency within the product.

@jeremystretch

Most users probably know what the device looks like, or don't care.

You could attribute that statement to so many other bits of info on this page too. For me, the point of your software if to provide all information to the viewer, and not rely on then having to figure our where than information is hidden. Having said that, giving the adminstrator of the product more control over how information is provided to the viewer is also essential. Allowing for the relevant information to be provided within the environment for which is it being used.

If they do need to see what the device looks like, a single click on the device type is a reasonable level of effort to get that information.

there are situations where a viewer may not be able to view device types due to the level of permissions granted them within the deplyment of the app. Each deplyment can have different use cases after all. So in those instances, device types images cannot be viewed or accessed when viewing a device.

@JNR8 commented on GitHub (Apr 2, 2020): @DouglasHeriot You can do what you have asked or already, which is why this feature request came to be. Each device type can have its own front and rear images. My request was to have the ability to toggle on/off the display of those images when viewing a device. Curently you cannot see these images when viewing a device, which seems like a missed opportunity to me. Yes you can upload individual images for Front and Rear for each device and mouse over them to view them, or click them to open another window to see the larger images. But the mouse over view it too small (any larger and it would look weird though) and opening another tab/window to view the image of the device seems unecessary. Right now you cannot view the Front or Rear images assigned to a device type when you view a device. You can see them on the Rack elevations view, but thats it. Being able to view them in a device created from the Device Type seems like a logical continuence of this feature. To not do this seems like a lack of consistency within the product. @jeremystretch > Most users probably know what the device looks like, or don't care. You could attribute that statement to so many other bits of info on this page too. For me, the point of your software if to provide all information to the viewer, and not rely on then having to figure our where than information is hidden. Having said that, giving the adminstrator of the product more control over how information is provided to the viewer is also essential. Allowing for the relevant information to be provided within the environment for which is it being used. > If they do need to see what the device looks like, a single click on the device type is a reasonable level of effort to get that information. there are situations where a viewer may not be able to view device types due to the level of permissions granted them within the deplyment of the app. Each deplyment can have different use cases after all. So in those instances, device types images cannot be viewed or accessed when viewing a device.
adam commented 2025-12-29 18:29:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 2, 2020):

Guys, the answer is no. The discussion is done now. You just have to accept that, or make your own fork.

@jeremystretch commented on GitHub (Apr 2, 2020): Guys, the answer is no. The discussion is done now. You just have to accept that, or make your own fork.
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
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#3451
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?