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

Deletion of tag allowed when referenced in config context #11857

New Issue
Closed
opened 2025-12-29 21:50:47 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:50:47 +01:00
Owner
Copy Link

Originally created by @kevclarx on GitHub (Nov 20, 2025).

NetBox Edition

NetBox Community

NetBox Version

v4.0.11

Python Version

3.10

Steps to Reproduce

  1. Create a tag
  2. Create a config context and set assignment to tag just created
  3. Delete the tag

Expected Behavior

Expect Netbox to warn that the tag is referenced in certain objects like the config context and fail deletion

Observed Behavior

Tag is deleted and config context is updated with tag removed. All devices in Netbox now have this config context applied since it has no assignments.

Originally created by @kevclarx on GitHub (Nov 20, 2025). ### NetBox Edition NetBox Community ### NetBox Version v4.0.11 ### Python Version 3.10 ### Steps to Reproduce 1. Create a tag 2. Create a config context and set assignment to tag just created 3. Delete the tag ### Expected Behavior Expect Netbox to warn that the tag is referenced in certain objects like the config context and fail deletion ### Observed Behavior Tag is deleted and config context is updated with tag removed. All devices in Netbox now have this config context applied since it has no assignments.
adam added the type: bugnetbox labels 2025-12-29 21:50:47 +01:00
adam closed this issue 2025-12-29 21:50:48 +01:00
adam commented 2025-12-29 21:50:48 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 20, 2025):

Thanks for the report, @kevclarx. I'm very not clear on if this behavior is intentional or not, given that the same appears to be true for the other M2M related fields on ConfigContext like sites, locations, platforms, device_types, etc. To be clear, the decision to use raw ManyToManyFields for ConfigContext was made in #1349, in this comment. The decision to add tags to ConfigContext was made in #3664, after TaggedItem was already in use elsewhere in the project. I'm not clear if the decision to use a bare ManyToMany relation to Tag was intentionally chosen over using TaggedItem.

I don't see any discussion in either of these two issues, or their related PRs, about the side-effects of these decisions with regards to the behavior this issue describes.

I'm going to raise this with the other maintainers. In the meantime, you might be able to employ permission constraints to disallow the deletion of sensitive objects to avoid the behavior reported.

@jnovinger commented on GitHub (Nov 20, 2025): Thanks for the report, @kevclarx. I'm very not clear on if this behavior is intentional or not, given that the same appears to be true for the other M2M related fields on `ConfigContext` like `sites`, `locations`, `platforms`, `device_types`, etc. To be clear, the decision to use raw `ManyToManyField`s for `ConfigContext` was made in #1349, in this [comment](https://github.com/netbox-community/netbox/issues/1349#issuecomment-362095504). The decision to add tags to `ConfigContext` was made in #3664, _after_ `TaggedItem` was already in use elsewhere in the project. I'm not clear if the decision to use a bare `ManyToMany` relation to `Tag` was intentionally chosen over using `TaggedItem`. I don't see any discussion in either of these two issues, or their related PRs, about the side-effects of these decisions with regards to the behavior **this** issue describes. I'm going to raise this with the other maintainers. In the meantime, you might be able to employ permission constraints to disallow the deletion of sensitive objects to avoid the behavior reported.
adam commented 2025-12-29 21:50:49 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 20, 2025):

If it wasn't clear from my first comment, I was able to reproduce the reported behavior in the current NetBox release, v4.4.6, locally with both Tags and Sites.

@jnovinger commented on GitHub (Nov 20, 2025): If it wasn't clear from my first comment, I was able to reproduce the reported behavior in the current NetBox release, v4.4.6, locally with both Tags and Sites.
adam commented 2025-12-29 21:50:49 +01:00
Author
Owner
Copy Link

@kevclarx commented on GitHub (Nov 21, 2025):

We were thinking of writing a CustomValidator for Tag(and other) delete events to check for context references first, it might be slow but it's not something that happens very often.

Restricting write permission on Config Context objects is not enough as our users don't have write access to contexts, just some of the tags they may reference. It shows up in the change log as that user editing the config context in this case even though they lack permission to do so.

@kevclarx commented on GitHub (Nov 21, 2025): We were thinking of writing a CustomValidator for Tag(and other) delete events to check for context references first, it might be slow but it's not something that happens very often. Restricting write permission on Config Context objects is not enough as our users don't have write access to contexts, just some of the tags they may reference. It shows up in the change log as that user editing the config context in this case even though they lack permission to do so.
adam commented 2025-12-29 21:50:50 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 25, 2025):

Expect Netbox to warn that the tag is referenced in certain objects like the config context and fail deletion

I disagree that this should be expected behavior. The same is not true for any other objects with which a config context may be associated (sites, tenants, etc.). Tags are not any different in this context. If we were to implement this behavior, it would need to be done so consistently for all related objects, which does not seem prudent IMO.

I'm not clear if the decision to use a bare ManyToMany relation to Tag was intentionally chosen over using TaggedItem.

We use a ManyToMany relation to Tag here because the relation signifies that the config context applies to objects with the selected tags assigned. This is different from a tag being applied to the context itself (which is how tags are typically used).

@jeremystretch commented on GitHub (Nov 25, 2025): > Expect Netbox to warn that the tag is referenced in certain objects like the config context and fail deletion I disagree that this should be expected behavior. The same is not true for any other objects with which a config context may be associated (sites, tenants, etc.). Tags are not any different in this context. If we were to implement this behavior, it would need to be done so consistently for _all_ related objects, which does not seem prudent IMO. > I'm not clear if the decision to use a bare ManyToMany relation to Tag was intentionally chosen over using TaggedItem. We use a ManyToMany relation to Tag here because the relation signifies that the config context applies to objects with the selected tags assigned. This is different from a tag being applied to the context itself (which is how tags are typically used).
adam commented 2025-12-29 21:50:50 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Nov 25, 2025):

We use a ManyToMany relation to Tag here because the relation signifies that the config context applies to objects with the selected tags assigned. This is different from a tag being applied to the context itself (which is how tags are typically used).

Closing as expected behavior.

@jnovinger commented on GitHub (Nov 25, 2025): > We use a ManyToMany relation to Tag here because the relation signifies that the config context applies to objects with the selected tags assigned. This is different from a tag being applied to the context itself (which is how tags are typically used). Closing as expected behavior.
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 netbox type: bug
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#11857
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?