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 free-form, searchable, labeling/tagging of devices #95

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

Originally created by @ryanmerolle on GitHub (Jun 30, 2016).

Originally assigned to: @jeremystretch on GitHub.

Ability to apply comma separated free form labels or tags to any device that is searchable across all objects.

Originally created by @ryanmerolle on GitHub (Jun 30, 2016). Originally assigned to: @jeremystretch on GitHub. Ability to apply comma separated free form labels or tags to any device that is searchable across all objects.
adam added the status: accepted label 2025-12-29 15:32:40 +01:00
adam closed this issue 2025-12-29 15:32:41 +01:00
adam commented 2025-12-29 15:32:43 +01:00
Author
Owner
Copy Link

@troxil commented on GitHub (Jun 30, 2016):

Same as #129 ?

@troxil commented on GitHub (Jun 30, 2016): Same as #129 ?
adam commented 2025-12-29 15:32:43 +01:00
Author
Owner
Copy Link

@ryanmerolle commented on GitHub (Jun 30, 2016):

I see that argument, so I'll talk this out some more.

The feature I am talking about is not just custom fields, but a way to apply tags that allow for searching through all assets not just assets of the same type. With # 129, if I applied a custom field in the circuit section I imagine it would just be searchable within the circuit section.

Device42 actually treat these two features different functions. I have seen this also implemented in one other opensource iPam tool before.

@ryanmerolle commented on GitHub (Jun 30, 2016): I see that argument, so I'll talk this out some more. The feature I am talking about is not just custom fields, but a way to apply tags that allow for searching through all assets not just assets of the same type. With # 129, if I applied a custom field in the circuit section I imagine it would just be searchable within the circuit section. Device42 actually treat these two features different functions. I have seen this also implemented in one other opensource iPam tool before.
adam commented 2025-12-29 15:32:43 +01:00
Author
Owner
Copy Link

@aabouzaid commented on GitHub (Jul 29, 2016):

I believe that this is absolutely one of most important features!

@aabouzaid commented on GitHub (Jul 29, 2016): I believe that this is absolutely one of most important features!
adam commented 2025-12-29 15:32:44 +01:00
Author
Owner
Copy Link

@aabouzaid commented on GitHub (Jul 29, 2016):

I'd like to create a Python module that uses netbox as dynamic inventory for Ansible.
But I think it will be more useful when netbox has tagging or grouping feature (with multi roles of course) :-)

@aabouzaid commented on GitHub (Jul 29, 2016): I'd like to create a Python module that uses netbox as [dynamic inventory](http://docs.ansible.com/ansible/intro_dynamic_inventory.html) for Ansible. But I think it will be more useful when netbox has tagging or grouping feature (with multi roles of course) :-)
adam commented 2025-12-29 15:32:44 +01:00
Author
Owner
Copy Link

@seismiccollision commented on GitHub (Sep 21, 2016):

I was hoping I'd see the ability to use the new custom fields feature to select multiple options so I could tag individual devices with multiple 'functions'/'purposes'/'categories' etc. but it sounds like what I need is the above. Am I in the right place to +1 this feature?

@seismiccollision commented on GitHub (Sep 21, 2016): I was hoping I'd see the ability to use the new custom fields feature to select multiple options so I could tag individual devices with multiple 'functions'/'purposes'/'categories' etc. but it sounds like what I need is the above. Am I in the right place to +1 this feature?
adam commented 2025-12-29 15:32:45 +01:00
Author
Owner
Copy Link

@Zorlin commented on GitHub (Feb 21, 2017):

This is absolutely essential for us. Right now we're using NetBox because nothing else on the market is quite as good, but free-form tagging would allow us to become a lot more efficient and well-documented without increasing complexity. Additionally, it is crucial for NetBox to become a proper Single Source of Truth in our org.

@Zorlin commented on GitHub (Feb 21, 2017): This is absolutely essential for us. Right now we're using NetBox because nothing else on the market is quite as good, but free-form tagging would allow us to become a lot more efficient and well-documented without increasing complexity. Additionally, it is crucial for NetBox to become a proper Single Source of Truth in our org.
adam commented 2025-12-29 15:32:45 +01:00
Author
Owner
Copy Link

@puck commented on GitHub (Mar 2, 2017):

A bunch of the comments in this thread are implying that people are using, or wanting to use netbox as an asset management system. Probably not the best idea. ;)

Also, this could be achievable by adding a new custom field type: multi-select

@puck commented on GitHub (Mar 2, 2017): A bunch of the comments in this thread are implying that people are using, or wanting to use netbox as an asset management system. Probably not the best idea. ;) Also, this could be achievable by adding a new custom field type: multi-select
adam commented 2025-12-29 15:32:45 +01:00
Author
Owner
Copy Link

@alexjhart commented on GitHub (Apr 25, 2017):

I would like this to apply to more than just devices. For example, I'd like to be able to search a tag that brings up all IP addresses that have the same purpose. I can sort of do this now using the description field, but I like having the multi-select field type (https://select2.github.io/examples.html#multiple). I suppose another alternative would be allowing auto-complete hashtags in existing fields for tagging?

@alexjhart commented on GitHub (Apr 25, 2017): I would like this to apply to more than just devices. For example, I'd like to be able to search a tag that brings up all IP addresses that have the same purpose. I can sort of do this now using the description field, but I like having the multi-select field type (https://select2.github.io/examples.html#multiple). I suppose another alternative would be allowing auto-complete hashtags in existing fields for tagging?
adam commented 2025-12-29 15:32:45 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Oct 19, 2017):

Having an arbitrary set of tags, at least on Device and VM, would be hugely useful for me.

I'd use this for categorising assets under management: for example, recording which service(s) are impacted by this device/VM, and which callout team(s) are responsible for it. Custom Fields are creaking at the seams here (#1625), especially when you consider that Device and VirtualMachine are separate tables, so Custom Fields have to be duplicated between both, and the inability to multi-select in a list.

I envisage it as an extension of "Role", so that at the simplest level, one Device/VM can be linked to multiple Roles instead of just one.

These more generic tags could also subsume Prefix/VLAN Role, IP address Roles, Rack Roles. Already, device/VM roles have a flag to say whether each one is suitable for VM use or not; implicitly they are all usable for Device. This could be extended to say whether a role is suitable for Device, Prefix, VLAN, IP Address, Rack (and indeed any other object type). Then you just have to allow many tags to be applied to the same object.

Tags could probably also subsume Platform, and even Rack Groups, Tenant Groups, Cluster Groups etc.

I am not sure that "comma separated" is the best way to do this, but that's just an implementation detail. Conceptually it's a many-to-many database relation, and could be implemented as such. If so, it could use GenericForeignKey such that tags can be applied to any objects - including Racks, Sites, Circuits etc.

If it's a comma-separated field then every taggable object needs a tags field. Better include a comma at the start and the end too:

,14,23,99,

so you can search for tags like '%,14,%' and it doesn't matter if it's at the start or end of the line. Use numeric tag IDs, so tags can be renamed.

It would be useful for the tags themselves to be grouped. The full tag name would then be <group>:<tag>

Examples:

  • tag group service
    • tag mail
    • tag web
    • tag database
    • ...
  • tag group platform
    • tag Ubuntu 14.04
    • tag Ubuntu 16.04
    • ...

(It makes sense to allow a machine to be tagged with multiple service tags. Admittedly it makes less sense to tag it with multiple platform tags)

@candlerb commented on GitHub (Oct 19, 2017): Having an arbitrary set of tags, at least on Device and VM, would be hugely useful for me. I'd use this for categorising assets under management: for example, recording which service(s) are impacted by this device/VM, and which callout team(s) are responsible for it. Custom Fields are creaking at the seams here (#1625), especially when you consider that Device and VirtualMachine are separate tables, so Custom Fields have to be duplicated between both, and the inability to multi-select in a list. I envisage it as an extension of "Role", so that at the simplest level, one Device/VM can be linked to multiple Roles instead of just one. These more generic tags could also subsume Prefix/VLAN Role, IP address Roles, Rack Roles. Already, device/VM roles have a flag to say whether each one is suitable for VM use or not; implicitly they are all usable for Device. This could be extended to say whether a role is suitable for Device, Prefix, VLAN, IP Address, Rack (and indeed any other object type). Then you just have to allow many tags to be applied to the same object. Tags could probably also subsume Platform, and even Rack Groups, Tenant Groups, Cluster Groups etc. I am not sure that "comma separated" is the best way to do this, but that's just an implementation detail. Conceptually it's a many-to-many database relation, and could be implemented as such. If so, it could use [GenericForeignKey](https://docs.djangoproject.com/en/1.11/ref/contrib/contenttypes/#generic-relations) such that tags can be applied to *any* objects - including Racks, Sites, Circuits etc. If it's a comma-separated field then every taggable object needs a tags field. Better include a comma at the start and the end too: ~~~ ,14,23,99, ~~~ so you can search for `tags like '%,14,%'` and it doesn't matter if it's at the start or end of the line. Use numeric tag IDs, so tags can be renamed. It would be useful for the tags themselves to be grouped. The full tag name would then be `<group>:<tag>` Examples: * tag group `service` * tag `mail` * tag `web` * tag `database` * ... * tag group `platform` * tag `Ubuntu 14.04` * tag `Ubuntu 16.04` * ... (It makes sense to allow a machine to be tagged with multiple service tags. Admittedly it makes less sense to tag it with multiple platform tags)
adam commented 2025-12-29 15:32:46 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 27, 2018):

Looks like an ArrayField is our best bet here. The django-array-tags project has a great reference implementation.

@jeremystretch commented on GitHub (Jan 27, 2018): Looks like an [ArrayField](https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/fields/#arrayfield) is our best bet here. The [django-array-tags](https://github.com/funkybob/django-array-tags) project has a great reference implementation.
adam commented 2025-12-29 15:32:46 +01:00
Author
Owner
Copy Link

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

Making good progress on this in the 132-tags branch.

@jeremystretch commented on GitHub (Mar 30, 2018): Making good progress on this in the `132-tags` branch.
adam commented 2025-12-29 15:32:46 +01:00
Author
Owner
Copy Link

@sevagh commented on GitHub (Apr 25, 2018):

If you need any volunteers/help to test your branch, I'm available - I'd like to have this feature.

In the 132-tags branch/current implementation, is there a notion of ACLs for adding/removing tags?

@sevagh commented on GitHub (Apr 25, 2018): If you need any volunteers/help to test your branch, I'm available - I'd like to have this feature. In the 132-tags branch/current implementation, is there a notion of ACLs for adding/removing tags?
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
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#95
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?