Limit tags to specific object types #7537

New Issue

adam · 2025-12-29T20:24:53+01:00

adam commented

2025-12-29 20:24:53 +01:00

Originally created by @candlerb on GitHub (Jan 20, 2023).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.4.2

Feature type

Data model extension

Proposed functionality

Currently, once you've created a tag, it can be assigned to any object of any type.

I propose that tags can be optionally linked to a set of object types, in the same way that custom fields are linked to object types. Then, when editing a particular object, you'd only be able to select and add tags bound to that object's type.

Tags which are not bound to any object type would be continue to be applicable to all object types.

Use case

There are a wide range of uses for tags: classifying devices, interfaces, IP addresses etc. However, many tags are only meaningful to specific object types.

Being able to restrict them in this way would:

Reduce the size of drop-down menus for tag selection, making it quicker and easier for users to add tags
Prevent unsuitable tags being added to objects, in a way which is much easier to maintain and more transparent than custom validators

Database changes

There would need to be a new many-to-many join between tag and content type, just like custom fields:

class CustomField(CloningMixin, ExportTemplatesMixin, WebhooksMixin, ChangeLoggedModel):
    content_types = models.ManyToManyField(
        to=ContentType,
        related_name='custom_fields',
        limit_choices_to=FeatureQuery('custom_fields'),
        help_text=_('The object(s) to which this field applies.')
    )

External dependencies

None

Originally created by @candlerb on GitHub (Jan 20, 2023). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.4.2 ### Feature type Data model extension ### Proposed functionality Currently, once you've created a tag, it can be assigned to any object of any type. I propose that tags can be optionally linked to a set of object types, in the same way that custom fields are linked to object types. Then, when editing a particular object, you'd only be able to select and add tags bound to that object's type. Tags which are not bound to any object type would be continue to be applicable to all object types. ### Use case There are a wide range of uses for tags: classifying devices, interfaces, IP addresses etc. However, many tags are only meaningful to specific object types. Being able to restrict them in this way would: * Reduce the size of drop-down menus for tag selection, making it quicker and easier for users to add tags * Prevent unsuitable tags being added to objects, in a way which is much easier to maintain and more transparent than custom validators ### Database changes There would need to be a new many-to-many join between tag and content type, just like custom fields: ``` class CustomField(CloningMixin, ExportTemplatesMixin, WebhooksMixin, ChangeLoggedModel): content_types = models.ManyToManyField( to=ContentType, related_name='custom_fields', limit_choices_to=FeatureQuery('custom_fields'), help_text=_('The object(s) to which this field applies.') ) ``` ### External dependencies None

adam added the status: accepted type: feature labels 2025-12-29 20:24:53 +01:00

adam closed this issue

2025-12-29 20:24:54 +01:00

adam commented

2025-12-29 20:24:54 +01:00

@jeremystretch commented on GitHub (Jan 20, 2023):

I think this makes sense. With regard to associating tags to object types, we would need to employ validation to check for any existing assignments to objects of non-specified types, but that should be fairly straightforward.

@jeremystretch commented on GitHub (Jan 20, 2023): I think this makes sense. With regard to associating tags to object types, we would need to employ validation to check for any existing assignments to objects of non-specified types, but that should be fairly straightforward.

adam commented

2025-12-29 20:24:54 +01:00

@candlerb commented on GitHub (Jan 20, 2023):

I'd be interested to know how custom fields deal with this case today: you create a custom field, link it to object type A, create some data on objects of that type, then unlink the custom field from that object type.

Experimentally: the custom field data is quietly deleted.

For tags, that might be a bit drastic, because you are going from the current open situation (allow this tag on all object types) to a more restricted option, and there's a risk of accidentally deleting tags.

I guess you could give the user a choice:

There are existing tags X on objects of type Y and Z. Do you want to:

Remove all tags X from Y and Z?

Allow objects of type Y and Z to use tag X?

Or maybe just do the second option (the safe thing) automatically. If the user wants to manually remove all the tags X from those objects, then remove those object types from the tag, they can do so.

@candlerb commented on GitHub (Jan 20, 2023): I'd be interested to know how custom fields deal with this case today: you create a custom field, link it to object type A, create some data on objects of that type, then unlink the custom field from that object type. Experimentally: the custom field data is quietly deleted. For tags, that might be a bit drastic, because you are going from the current open situation (allow this tag on all object types) to a more restricted option, and there's a risk of accidentally deleting tags. I guess you could give the user a choice: > There are existing tags X on objects of type Y and Z. Do you want to: > * Remove all tags X from Y and Z? > * Allow objects of type Y and Z to use tag X? Or maybe just do the second option (the safe thing) automatically. If the user wants to manually remove all the tags X from those objects, *then* remove those object types from the tag, they can do so.

adam commented

2025-12-29 20:24:55 +01:00

@jsenecal commented on GitHub (Jan 21, 2023):

@candlerb unfortunately such functionality would require a wizard-like input. A validation error could be raised instead which would require a manual intervention to achieve either of the above...

What do you think?

@jsenecal commented on GitHub (Jan 21, 2023): @candlerb unfortunately such functionality would require a wizard-like input. A validation error could be raised instead which would require a manual intervention to achieve either of the above... What do you think?

adam commented

2025-12-29 20:24:55 +01:00

@candlerb commented on GitHub (Jan 21, 2023):

A validation error would be fine, as long as it listed all the object types which had this tag but were not included in the set, and returned to the same populated form. Then the user could add them by hand to the set of enabled object types for that tag.

As for "wizard" I don't think it needs to be that complex:

There is a confirmation form shown in various situations already in Netbox, e.g. for certain types of bulk delete. So "Remove all tags X from objects of type Y and Z?" could be a confirmation form - it could also show the numbers of objects to be affected. This would be consistent with behaviour of custom fields (except you don't even get the confirmation)
By "doing the safe thing by default" I meant: whenever you edit a tag, the set of enabled object types automatically gets extended by the object types for which at least one object has that tag (unless the list is empty, which allows all objects anyway).

@candlerb commented on GitHub (Jan 21, 2023): A validation error would be fine, as long as it listed all the object types which had this tag but were not included in the set, and returned to the same populated form. Then the user could add them by hand to the set of enabled object types for that tag. As for "wizard" I don't think it needs to be that complex: * There is a confirmation form shown in various situations already in Netbox, e.g. for certain types of bulk delete. So "Remove all tags X from objects of type Y and Z?" could be a confirmation form - it could also show the numbers of objects to be affected. This would be consistent with behaviour of custom fields (except you don't even get the confirmation) * By "doing the safe thing by default" I meant: whenever you edit a tag, the set of enabled object types automatically gets extended by the object types for which at least one object has that tag (unless the list is empty, which allows all objects anyway).

adam referenced this issue

2025-12-29 23:27:05 +01:00

[PR #16407] [MERGED] 7537 add serial number to virtual machines #14847

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#7537