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

Tags enhancements: exclusion groups, model bindings #2524

New Issue
Closed
opened 2025-12-29 18:19:39 +01:00 by adam · 1 comment
adam commented 2025-12-29 18:19:39 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Apr 18, 2019).

Environment

  • Python version: 3.5.2
  • NetBox version: 2.5.10

Proposed Functionality

I would like Tag objects to be extended in the following two ways:

  1. Exclusion groups

    If a tag has an exclusion group assigned, then you cannot add another tag with the same exclusion group value. (Or: all other tags with the same exclusion group are automatically removed)

  2. Model bindings

    A tag can be configured with a set of object type(s) that it can be associated with. If this is present, then this tag can only be applied to those types of object.

    This is similar to the feature that Device Roles have today, where they can be marked as usable for VMs or not.

Both of these are optional. If the exclusion group is unset, the tag can be applied regardless of any other tags. If the model binding is unset, then the tag can be applied to any type of object.

Use Case

For exclusion groups:

  • Tags for environment such as "Production", "Test", "Staging", "Development". If a particular device or VM has such a tag, it can only be one from this set.
  • Tags for physical attributes such as "24-drive-chassis", "36-drive-chassis" where only one can be true
  • Tags for responsible team/owner
  • Tags for inventory item roles such as "OS disk", "Data disk"

For model bindings:

  • Limiting certain tags to inventory items only, e.g. "OS disk", "Data disk"
  • Limiting certain tags to devices + VMs, e.g. responsible team
  • Limiting certain tags to physical devices only, e.g. "24-drive-chassis", "36-drive-chassis"

This would make tags much less of a free-for-all, especially if Netbox prevents creation of new tags dynamically (#2727)

Note: I am aware that some of the above can also be achieved by means of custom fields with "Selection" data type. I have tried this, and it turns out to be very messy.

  1. It messes up the data entry forms and the search forms, with large numbers of fields which are often irrelevant
  2. It's hard to have a single custom field shared by multiple models, such as Device+VM (although in principle this should be allowed by the extras_customfield_obj_type join table). EDIT: Netbox does allow the same custom field to be applied to multiple models
  3. Inventory Items do not allow custom fields at all (#3083), but they do allow tags.

Database Changes

The Tags model would gain:

  • a text field for exclusion group
  • an array of django_content_type ids

It could also be done in a more normalized fashion, with an explicit exclusion group model and join table; and a join table between tag and django_content_type. Personally I'd keep it simple, but it's just a style choice.

External Dependencies

Relates to other tag enhancements made in 2.6 branch: #2324, #2791

Originally created by @candlerb on GitHub (Apr 18, 2019). ### Environment * Python version: 3.5.2 * NetBox version: 2.5.10 ### Proposed Functionality I would like Tag objects to be extended in the following two ways: 1. Exclusion groups If a tag has an exclusion group assigned, then you cannot add another tag with the same exclusion group value. (Or: all other tags with the same exclusion group are automatically removed) 2. Model bindings A tag can be configured with a set of object type(s) that it can be associated with. If this is present, then this tag can only be applied to those types of object. This is similar to the feature that Device Roles have today, where they can be marked as usable for VMs or not. Both of these are optional. If the exclusion group is unset, the tag can be applied regardless of any other tags. If the model binding is unset, then the tag can be applied to any type of object. ### Use Case For exclusion groups: * Tags for environment such as "Production", "Test", "Staging", "Development". If a particular device or VM has such a tag, it can only be one from this set. * Tags for physical attributes such as "24-drive-chassis", "36-drive-chassis" where only one can be true * Tags for responsible team/owner * Tags for inventory item roles such as "OS disk", "Data disk" For model bindings: * Limiting certain tags to inventory items only, e.g. "OS disk", "Data disk" * Limiting certain tags to devices + VMs, e.g. responsible team * Limiting certain tags to physical devices only, e.g. "24-drive-chassis", "36-drive-chassis" This would make tags much less of a free-for-all, especially if Netbox prevents creation of new tags dynamically (#2727) Note: I am aware that some of the above can also be achieved by means of custom fields with "Selection" data type. I have tried this, and it turns out to be very messy. 1. It messes up the data entry forms and the search forms, with large numbers of fields which are often irrelevant 2. ~~It's hard to have a single custom field shared by multiple models, such as Device+VM (although in principle this should be allowed by the `extras_customfield_obj_type` join table).~~ EDIT: Netbox *does* allow the same custom field to be applied to multiple models 3. Inventory Items do not allow custom fields at all (#3083), but they do allow tags. ### Database Changes The Tags model would gain: * a text field for exclusion group * an array of django_content_type ids It could also be done in a more normalized fashion, with an explicit exclusion group model and join table; and a join table between tag and django_content_type. Personally I'd keep it simple, but it's just a style choice. ### External Dependencies Relates to other tag enhancements made in 2.6 branch: #2324, #2791
adam closed this issue 2025-12-29 18:19:39 +01:00
adam commented 2025-12-29 18:19:39 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 18, 2019):

This is way, way overkill for the function tags are intended to provide. A tag is merely a convenient option to allow for arbitrary, opportunistic organization of various resources to complement the structured, constrained fields built into each model. Tags are created on-demand and convey minimal significance. (NetBox v2.6 will add colors and descriptions to the Tag model, which can be added after a tag has been created, but that's it.)

All of the use cases you cite would be better served using a structured field.

Tags for environment such as "Production", "Test", "Staging", "Development". If a particular device or VM has such a tag, it can only be one from this set.

This can be a custom field on Device.

Tags for physical attributes such as "24-drive-chassis", "36-drive-chassis" where only one can be true

This is already conveyed by DeviceType.

Tags for responsible team/owner

See #988

Tags for inventory item roles such as "OS disk", "Data disk"

This might be pushing NetBox's scope a bit: NetBox is not intended to serve as an asset-tracking system. There might be a case to add a role field to InventoryItem, but it would require a separate FR with discussion.

I appreciate the proposal but the work already done in develop-2.6 is as far as we're going to go with tags for the foreseeable future.

@jeremystretch commented on GitHub (Apr 18, 2019): This is way, way overkill for the function tags are intended to provide. A tag is merely a convenient option to allow for arbitrary, opportunistic organization of various resources to complement the structured, constrained fields built into each model. Tags are created on-demand and convey minimal significance. (NetBox v2.6 will add colors and descriptions to the Tag model, which can be added after a tag has been created, but that's it.) All of the use cases you cite would be better served using a structured field. > Tags for environment such as "Production", "Test", "Staging", "Development". If a particular device or VM has such a tag, it can only be one from this set. This can be a custom field on Device. > Tags for physical attributes such as "24-drive-chassis", "36-drive-chassis" where only one can be true This is already conveyed by DeviceType. > Tags for responsible team/owner See #988 > Tags for inventory item roles such as "OS disk", "Data disk" This might be pushing NetBox's scope a bit: NetBox is not intended to serve as an asset-tracking system. There might be a case to add a `role` field to InventoryItem, but it would require a separate FR with discussion. I appreciate the proposal but the work already done in `develop-2.6` is as far as we're going to go with tags for the foreseeable future.
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#2524
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?