Netbox: Template variable access for custom links on device page

[lampwins]

Issue type: feature request

To mirror our conversation on the networktocode slack, I would love to be able to create custom links to external systems that show up on the device pages. Similar to the context surrounding interface graphs, I want access to the templating variables to create the links.

For example, a link to a configuration management system with the context of the given device:
http://my.nms.local/config/?device={{ device.name }}

I would also want access to the custom attributes for the device, as I store important information that would be used in this links.

I was also thinking buttons instead of standard links would be cool but not a strict requirement. I do want control over the target attribute for the link, so I can define if it would open in the same window or new tab, etc.

The overall goal is to be able to go to a device page in netbox and have a link I can click to go to another related system with that device's context.

Please let me know if more information is needed, happy to discus further.

[jeremystretch]

An important consideration is whether we want to simply expose device attributes to the comment field, or whether an additional model is necessary. The former would offer the most flexibility; the later would be needed to add links or buttons elsewhere on the device page.

[cimnine]

An important consideration is whether we want to simply expose device attributes to the comment field, or whether an additional model is necessary.

My only input to this is to prefix each of these possibilities with their own prefix, so that eventually both can be supported. And ideally the prefix is not the model's name, because custom fields can be defined on multiple models at the same time. So instead of {{ device.name }} it would better be {{ attributes.name }}.

I do want control over the target attribute for the link, so I can define if it would open in the same window or new tab, etc.

This is considered 'oldschool' thinking among my peers, as it robs the user from his freedom to choose how he or she would like to open the linked content. Without the target set, every user can decide (with ctrl or shift) if he or she would like to open the link in a new tab, a new window or if he or she would just like to navigate away in the same window. With the target set, at least one choice is taken away.

[mf69]

Another great use case for this...
Dell support has predicable URLs for obtaining the as-shipped system configuration like
http://www.dell.com/support/home/us/en/19/product-support/servicetag/dvc6b42/configuration
where dvc6b42 is the service tag or serial number.

[mryauch]

This seems similar to #600. However it is solved, I currently have a custom URL field on my prefixes/aggregates and would love to populate it with a link to ARIN or a routing registry.

[cyberjacob]

I would be in favour of an additional model, and making the links global (or at least device-/prefix-/etc-wide). Anything device-specific can go in the comments anyway.

Example of what this could look like, from a duplicate feature request I just raised:

[cyberjacob]

I've started working on this here. Still needs a bit of work, but that should have most of it done. At this point, just needs UIs and some testing.

[NEOhidra]

I suppose that my idea to allow markdown in services description is somehow connected with this feature request.

Would you add a functionality to render hyperlinks to external knowledgeable in each service description?

[mmahacek]

I created a new file in netbox/templates/inc and add an include on the device page. This creates a button that includes links to connect to the device, but could also have links to other systems as well.

https://gist.github.com/mmahacek/3f69b10d2c6709e8e9ea91768282bca9

[bdlamprecht]

That is a very clever "hack" @mmahacek . I kind of like it in weird sort-of-way. :smile:

[chicks-net]

https://github.com/netbox-community/netbox/wiki/Frequently-Asked-Questions#user-content-why-does-netbox-support-only-image-attachments indicates that this issue is still in progress, but it seems to be done.