"Restrict Tag Usage by Object Type" - restricting a tag with existing uses #8451

New Issue

adam · 2025-12-29T20:36:54+01:00

adam commented

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

Originally created by @ITJamie on GitHub (Aug 10, 2023).

NetBox version

v3.6-beta1

Python version

3.10

Steps to Reproduce

1: customization > tags > goto a tag with existing uses (lets say device objects)
2: edit the tag and assign an object type (eg circuits only)
3: save tag object
(note I consider this the first issue, it should throw an exception about existing uses)

4: goto a device object with that tag already assigned
5: edit the device, save
(second issue)

Expected Behavior

first issue:
it should not be possible to restrict a tag further than its existing uses.
eg if there are currently uses for of the tag on the "site" model attempting to scope it to just devices objects should throw an exception until existing uses of the tag on the site objects are removed.

second issue:
when editing an object with a tag assigned that it shouldn't have there is no exception or warning thrown (and the tag is still assigned to the object)

Observed Behavior

no exceptions or errors are thrown when limiting a tag to specific objects even when there are other uses of that tag
no exceptions or errors are thrown when editing/saving an object with a tag assigned (that it shouldn't be allowed have)

Originally created by @ITJamie on GitHub (Aug 10, 2023). ### NetBox version v3.6-beta1 ### Python version 3.10 ### Steps to Reproduce 1: customization > tags > goto a tag with existing uses (lets say device objects) 2: edit the tag and assign an object type (eg circuits only) 3: save tag object (note I consider this the first issue, it should throw an exception about existing uses) 4: goto a device object with that tag already assigned 5: edit the device, save (second issue) ### Expected Behavior **first issue:** it should not be possible to restrict a tag further than its existing uses. eg if there are currently uses for of the tag on the "site" model attempting to scope it to just devices objects should throw an exception until existing uses of the tag on the site objects are removed. **second issue:** when editing an object with a tag assigned that it shouldn't have there is no exception or warning thrown (and the tag is still assigned to the object) ### Observed Behavior - no exceptions or errors are thrown when limiting a tag to specific objects even when there are other uses of that tag - no exceptions or errors are thrown when editing/saving an object with a tag assigned (that it shouldn't be allowed have)

adam added the type: bug beta labels 2025-12-29 20:36:54 +01:00

adam closed this issue

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

adam commented

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

@jeremystretch commented on GitHub (Aug 10, 2023):

it should not be possible to restrict a tag further than its existing uses.

This is not an intended behavior of the implementation. Allowing this flexibility enables users to migrate away from the use of tags for specific objects while preventing new assignments. If you'd like to propose a more restrictive behavior, please open a feature request citing your use case so we can collect feedback.

when editing an object with a tag assigned that it shouldn't have there is no exception or warning thrown

No validation is performed because the assigned tags did not change. This behavior is inherent to the way many-to-many relationships are handled internally. Really this is just a symptom of your first point anyway, and would be obviated if we preempt the restriction of tags based on existing assignments. (Validation does fail for new tag assignments.)

@jeremystretch commented on GitHub (Aug 10, 2023): > it should not be possible to restrict a tag further than its existing uses. This is not an intended behavior of the implementation. Allowing this flexibility enables users to migrate away from the use of tags for specific objects while preventing new assignments. If you'd like to propose a more restrictive behavior, please open a feature request citing your use case so we can collect feedback. > when editing an object with a tag assigned that it shouldn't have there is no exception or warning thrown No validation is performed because the assigned tags did not change. This behavior is inherent to the way many-to-many relationships are handled internally. Really this is just a symptom of your first point anyway, and would be obviated if we preempt the restriction of tags based on existing assignments. (Validation _does_ fail for new tag assignments.)

adam commented

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

@ITJamie commented on GitHub (Aug 10, 2023):

👍 just wanted to flag it as it reacts differently than I expected

@ITJamie commented on GitHub (Aug 10, 2023): 👍 just wanted to flag it as it reacts differently than I expected

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#8451