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

Add Icon to Device View For Connecting to Device #2160

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

Originally created by @bdlamprecht on GitHub (Nov 29, 2018).

Environment

  • Python version: 3.6.7
  • NetBox version: v2.4.8

Proposed Functionality

As I become more active in using the awesomeness of NetBox to document everything about my network, I find myself having to do a lot of copy / paste operations from the WebUI of NetBox into either (1) my command line (for SSH) or (2) my browser (for HTTPS) to manage devices.

I'm wondering if it would be useful or appropriate to add a link to open a connection to the device's primary_ip via a specific protocol (by appending said protocol to the URI of the IP address) which would then be interpreted by the user's browser or OS.

Here is a very crude mock-up of how this would look should it be implemented:

image

Clicking the green lightning bolt (or any other icon of preference) to the right of the IP address on this view would open a connection to the primary_ip (when all of the requirements specified below were met) via a generated URI.

The prerequisites for this to become available would be the following:

  1. Have a primary_ip defined (obviously)
  2. Have a management protocol defined (new property)

The mock-up for how this would appear in the view of each device would be something like this:

image

The usefulness of this would be, in my opinion, huge as it would eliminate a lot of copy / paste operations or errors due to "fat-fingering" or other errors in entering the IP address into a CLI or browser.

It would be be up to the end-user to allow said operation or not by allowing the protocol in the URI to be executed or not.

Use Case

Already explained above.

Database Changes

The device would need to have an optional mgmt_protocol property based off of predefined _choices similar to interface form_factor or rack width so as to keep the database fairly "clean".

External Dependencies

None

Originally created by @bdlamprecht on GitHub (Nov 29, 2018). ### Environment * Python version: 3.6.7 * NetBox version: v2.4.8 ### Proposed Functionality As I become more active in using the **awesomeness** of NetBox to document everything about my network, I find myself having to do a lot of copy / paste operations from the WebUI of NetBox into either (1) my command line (for SSH) or (2) my browser (for HTTPS) to manage devices. I'm wondering if it would be useful or appropriate to add a link to open a connection to the `device`'s `primary_ip` via a specific protocol (by appending said protocol to the URI of the IP address) which would then be interpreted by the user's browser or OS. Here is a _**very**_ crude mock-up of how this would look should it be implemented: ![image](https://user-images.githubusercontent.com/7783306/49243182-ed4ca780-f3c9-11e8-93c6-ad765629abe6.png) Clicking the green lightning bolt (or any other icon of preference) to the right of the IP address on this view would open a connection to the `primary_ip` (when all of the requirements specified below were met) via a generated URI. The prerequisites for this to become available would be the following: 1. Have a `primary_ip` defined (obviously) 2. Have a management `protocol` defined (new property) The mock-up for how this would appear in the view of each device would be something like this: ![image](https://user-images.githubusercontent.com/7783306/49244037-153d0a80-f3cc-11e8-870a-0e6473b2f8d7.png) The usefulness of this would be, in my opinion, huge as it would eliminate a lot of copy / paste operations or errors due to "fat-fingering" or other errors in entering the IP address into a CLI or browser. It would be be up to the end-user to allow said operation or not by allowing the protocol in the URI to be executed or not. ### Use Case Already explained above. ### Database Changes The device would need to have an optional `mgmt_protocol` property based off of predefined `_choices` similar to interface `form_factor` or rack `width` so as to keep the database fairly "clean". <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None
adam closed this issue 2025-12-29 17:22:48 +01:00
adam commented 2025-12-29 17:22:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 30, 2018):

If anything, I imagine we'd use the Service model for this, rather than adding a new field. But the reason NetBox doesn't currently do this is that most web browsers don't have a built-in mechanism for handling ssh:// or telnet:// links. There are some third-party extensions which will handle them, but they need to be installed by the user. I don't want to introduce a button that does nothing by default.

@jeremystretch commented on GitHub (Nov 30, 2018): If anything, I imagine we'd use the Service model for this, rather than adding a new field. But the reason NetBox doesn't currently do this is that most web browsers don't have a built-in mechanism for handling `ssh://` or `telnet://` links. There are some third-party extensions which will handle them, but they need to be installed by the user. I don't want to introduce a button that does nothing by default.
adam commented 2025-12-29 17:22:49 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Nov 30, 2018):

Yes, that would probably make more sense to use the service model versus creating a new field.

I believe Chrome can handle custom URI's such as the ones you mentioned but I can't tell for sure just now.

Perhaps create a setting in the configuration.py that enables or disables this functionality as an end-user desires

@bdlamprecht commented on GitHub (Nov 30, 2018): Yes, that would probably make more sense to use the `service` model versus creating a new field. I _believe_ Chrome can handle custom `URI`'s such as the ones you mentioned but I can't tell for sure just now. Perhaps create a setting in the `configuration.py` that enables or disables this functionality as an end-user desires
adam commented 2025-12-29 17:22:49 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (Jan 10, 2019):

As it depends on the using browser and the using software who could work with this url types we should implement this and give the enduser the choice of supporting url parsing.

for e.g. https://winscp.net/eng/docs/integration_url use do a lot.

For easier implementation it should be parsed as link:
If IP: 192.168.178.2
Protocol: SSH
Parsed URL: ssh://192.168.178.2

If someone use this url to click or not ... depend on the enduser who use netbox.

@bdlamprecht : What do you think ??

@tb-killa commented on GitHub (Jan 10, 2019): As it depends on the using browser and the using software who could work with this url types we should implement this and give the enduser the choice of supporting url parsing. for e.g. https://winscp.net/eng/docs/integration_url use do a lot. For easier implementation it should be parsed as link: If IP: 192.168.178.2 Protocol: SSH Parsed URL: ssh://192.168.178.2 If someone use this url to click or not ... depend on the enduser who use netbox. @bdlamprecht : What do you think ??
adam commented 2025-12-29 17:22:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 15, 2019):

Closing this out, mostly because I don't want to deal with the inevitable repeat issues complaining that it doesn't work in specific browsers. Sorry.

@jeremystretch commented on GitHub (Feb 15, 2019): Closing this out, mostly because I don't want to deal with the inevitable repeat issues complaining that it doesn't work in specific browsers. Sorry.
adam commented 2025-12-29 17:22:49 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Feb 15, 2019):

While it is an unfortunate decision, I can definitely understand where you're coming from.

The current rate of issues being submitted is for sure a problem and this would only increase that exponentially.

Perhaps this can be readdressed in the future when (or if) things settle down.

Thanks for the honest response.

@bdlamprecht commented on GitHub (Feb 15, 2019): While it is an unfortunate decision, I can definitely understand where you're coming from. The current rate of issues being submitted is for sure a problem and this would only increase that exponentially. Perhaps this can be readdressed in the future when (or **_if_**) things settle down. Thanks for the honest response.
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#2160
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?