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 support for custom links #5132

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

Originally created by @rodvand on GitHub (Aug 4, 2021).

NetBox version

v3.0-beta1

Feature type

Data model extension

Proposed functionality

Add the ability to define a material design icon for a custom link. The input icon text would be added to the link and give an output like this:
Screenshot 2021-08-04 at 10 00 30

Use case

In setups with a large amount of custom links (to ssh management, console management, NMS and so on) the icons can provide a way of distinguishing the different links. NetBox already utilises icons this way with add/edit/delete icons accompanying the text.

Database changes

Would need to add a CharField on the CustomLink model. Something like this maybe:

link_icon = models.CharField(
        max_length=500,
        required=False,
        verbose_name='Link Icon',
        help_text="MDI tag for icon"
    )

External dependencies

Just update the relevant documentation to point users to where they can figure out what text to put in the icon field.

Originally created by @rodvand on GitHub (Aug 4, 2021). ### NetBox version v3.0-beta1 ### Feature type Data model extension ### Proposed functionality Add the ability to define a material design icon for a custom link. The input icon text would be added to the link and give an output like this: <img width="212" alt="Screenshot 2021-08-04 at 10 00 30" src="https://user-images.githubusercontent.com/56864/128145579-35e6d203-e914-4347-b653-74d0ca835968.png"> ### Use case In setups with a large amount of custom links (to ssh management, console management, NMS and so on) the icons can provide a way of distinguishing the different links. NetBox already utilises icons this way with add/edit/delete icons accompanying the text. ### Database changes Would need to add a CharField on the CustomLink model. Something like this maybe: ``` link_icon = models.CharField( max_length=500, required=False, verbose_name='Link Icon', help_text="MDI tag for icon" ) ``` ### External dependencies Just update the relevant documentation to point users to where they can figure out what text to put in the icon field.
adam added the type: feature label 2025-12-29 19:24:35 +01:00
adam closed this issue 2025-12-29 19:24:35 +01:00
adam commented 2025-12-29 19:24:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 4, 2021):

How would users specify an icon, just plain text? How would you validate that?

@jeremystretch commented on GitHub (Aug 4, 2021): How would users specify an icon, just plain text? How would you validate that?
adam commented 2025-12-29 19:24:36 +01:00
Author
Owner
Copy Link

@tb-killa commented on GitHub (Aug 4, 2021):

The easiest way would be to let the "link_icon" field be plain text and render them as icon_class or mdi icon class.
If no input it shouldn´t be rendered, if user paste for eg. 'fa fa-plus' it should be rendered.

Because of validation i would say: if someone insert class or name he should know them or copy paste them by searching on the right info page. this is something for power-users :)

@tb-killa commented on GitHub (Aug 4, 2021): The easiest way would be to let the "link_icon" field be plain text and render them as icon_class or mdi icon class. If no input it shouldn´t be rendered, if user paste for eg. 'fa fa-plus' it should be rendered. Because of validation i would say: if someone insert class or name he should know them or copy paste them by searching on the right info page. this is something for power-users :)
adam commented 2025-12-29 19:24:36 +01:00
Author
Owner
Copy Link

@rodvand commented on GitHub (Aug 4, 2021):

I also think this should be something we require the user to know what they are doing. And in the worst case, what harm can it do that they input the wrong data? It would just end up in the link class and maybe make the link appearance a bit messy.

I guess since material design is what's being used we need to limit it to this? We could even limit it to just using the material design icon name, and applying the mdi in the template code itself.

So the user would input "console" in the custom link creation, and we would sanitise to make sure everything is safe. In the template we would do a check if link_icon is set and if it is add the "mdi-console" to the class on the link.

@rodvand commented on GitHub (Aug 4, 2021): I also think this should be something we require the user to know what they are doing. And in the worst case, what harm can it do that they input the wrong data? It would just end up in the link class and maybe make the link appearance a bit messy. I guess since material design is what's being used we need to limit it to this? We could even limit it to just using the material design icon name, and applying the mdi in the template code itself. So the user would input "console" in the custom link creation, and we would sanitise to make sure everything is safe. In the template we would do a check if link_icon is set and if it is add the "mdi-console" to the class on the link.
adam commented 2025-12-29 19:24:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 4, 2021):

this is something for power-users :)

IMO this does not meet the bar we want to uphold for the user experience. If we're going to make something available in the UI, it needs to include robust validation.

And in the worst case, what harm can it do that they input the wrong data?

The user opens a bug report because they think it's broken, or they seek out assistance here or elsewhere, and we end up rehashing the same conversation repeatedly. The UI needs to validate the selected choice to prevent this.

Additionally, what happens if we need to migrate away from Material Design icons, as we have from Font Awesome?

@jeremystretch commented on GitHub (Aug 4, 2021): > this is something for power-users :) IMO this does not meet the bar we want to uphold for the user experience. If we're going to make something available in the UI, it needs to include robust validation. > And in the worst case, what harm can it do that they input the wrong data? The user opens a bug report because they think it's broken, or they seek out assistance here or elsewhere, and we end up rehashing the same conversation repeatedly. The UI needs to validate the selected choice to prevent this. Additionally, what happens if we need to migrate away from Material Design icons, as we have from Font Awesome?
adam commented 2025-12-29 19:24:36 +01:00
Author
Owner
Copy Link

@rodvand commented on GitHub (Aug 4, 2021):

IMO this does not meet the bar we want to uphold for the user experience. If we're going to make something available in the UI, it needs to include robust validation.

Not sure how we can validate this. Read wherever the icons exist (not sure where they are located atm) and check that the value exists there when the user saves the custom link? It does not feel like a very good way of doing it, but I can't see any other way. But if we are able to read the data with the icons we could provide the user a selection instead of requiring plain-text input.

Additionally, what happens if we need to migrate away from Material Design icons, as we have from Font Awesome?

The whole custom link creation kinda depends on the user knowing what she/he is doing. There is no way for us to validate the jinja2 template code used in the link text or link url fields. And if/when a data model changes today the user have to go in and change the custom link setup, just as would be required on an icon pack change. As for user help, it shouldn't take more than two lines in the documentation to point the user to where the icon names can be found (if we can't provide a selection menu).

@rodvand commented on GitHub (Aug 4, 2021): > IMO this does not meet the bar we want to uphold for the user experience. If we're going to make something available in the UI, it needs to include robust validation. Not sure how we can validate this. Read wherever the icons exist (not sure where they are located atm) and check that the value exists there when the user saves the custom link? It does not feel like a very good way of doing it, but I can't see any other way. But if we are able to read the data with the icons we could provide the user a selection instead of requiring plain-text input. > Additionally, what happens if we need to migrate away from Material Design icons, as we have from Font Awesome? The whole custom link creation kinda depends on the user knowing what she/he is doing. There is no way for us to validate the jinja2 template code used in the link text or link url fields. And if/when a data model changes today the user have to go in and change the custom link setup, just as would be required on an icon pack change. As for user help, it shouldn't take more than two lines in the documentation to point the user to where the icon names can be found (if we can't provide a selection menu).
adam commented 2025-12-29 19:24:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 4, 2021):

Read wherever the icons exist (not sure where they are located atm) and check that the value exists there when the user saves the custom link? It does not feel like a very good way of doing it, but I can't see any other way. But if we are able to read the data with the icons we could provide the user a selection instead of requiring plain-text input.

That sounds like the way to go. Maybe we could keep it simple by curating a list of a few dozen supported icons. This would allow users to easily select an available icon, as well as providing a "wrapper" in the event we need to migrate in the future. Of course then you'll have people submitting feature requests to add random icons all the time, so we would need to communicate that no further icons will be added.

There is no way for us to validate the jinja2 template code used in the link text or link url fields.

Not on creation/update, but NetBox displays an error icon and message whenever a custom link fails to render. This way the user has a clue to check their code instead of assuming it's a bug in NetBox.

@jeremystretch commented on GitHub (Aug 4, 2021): > Read wherever the icons exist (not sure where they are located atm) and check that the value exists there when the user saves the custom link? It does not feel like a very good way of doing it, but I can't see any other way. But if we are able to read the data with the icons we could provide the user a selection instead of requiring plain-text input. That sounds like the way to go. Maybe we could keep it simple by curating a list of a few dozen supported icons. This would allow users to easily select an available icon, as well as providing a "wrapper" in the event we need to migrate in the future. Of course then you'll have people submitting feature requests to add random icons all the time, so we would need to communicate that no further icons will be added. > There is no way for us to validate the jinja2 template code used in the link text or link url fields. Not on creation/update, but NetBox displays an error icon and message whenever a custom link fails to render. This way the user has a clue to check their code instead of assuming it's a bug in NetBox.
adam commented 2025-12-29 19:24:37 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Aug 5, 2021):

FWIW, you can already add icons to custom links by just using the appropriate MDI markup for the link text, e.g. I use the following for hyperlinks to device web interfaces:

{% if obj.status == 'active' %}<i class="mdi mdi-earth"></i> {{ obj.name }}{% endif %}

Presuming a "power user" can find the appropriate markup from https://materialdesignicons.com/ and copy/paste, does this not achieve the intended goal?

@bellwood commented on GitHub (Aug 5, 2021): FWIW, you can already add icons to custom links by just using the appropriate MDI markup for the link text, e.g. I use the following for hyperlinks to device web interfaces: ``` {% if obj.status == 'active' %}<i class="mdi mdi-earth"></i> {{ obj.name }}{% endif %} ``` Presuming a "power user" can find the appropriate markup from https://materialdesignicons.com/ and copy/paste, does this not achieve the intended goal?
adam commented 2025-12-29 19:24:37 +01:00
Author
Owner
Copy Link

@rodvand commented on GitHub (Aug 5, 2021):

FWIW, you can already add icons to custom links by just using the appropriate MDI markup for the link text, e.g. I use the following for hyperlinks to device web interfaces:


{% if obj.status == 'active' %}<i class="mdi mdi-earth"></i> {{ obj.name }}{% endif %}

Presuming a "power user" can find the appropriate markup from https://materialdesignicons.com/ and copy/paste, does this not achieve the intended goal?

Great stuff, that's precisely what I wanted. No reason to add extra complexity to the data model when we can do this!

@rodvand commented on GitHub (Aug 5, 2021): > FWIW, you can already add icons to custom links by just using the appropriate MDI markup for the link text, e.g. I use the following for hyperlinks to device web interfaces: > > > > ``` > > {% if obj.status == 'active' %}<i class="mdi mdi-earth"></i> {{ obj.name }}{% endif %} > > ``` > > > > Presuming a "power user" can find the appropriate markup from https://materialdesignicons.com/ and copy/paste, does this not achieve the intended goal? Great stuff, that's precisely what I wanted. No reason to add extra complexity to the data model when we can do this!
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 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#5132
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?