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

Only allow selection from pre-defined tags #3023

New Issue
Closed
opened 2025-12-29 18:24:51 +01:00 by adam · 6 comments
adam commented 2025-12-29 18:24:51 +01:00
Owner
Copy Link

Originally created by @candlerb on GitHub (Nov 21, 2019).

Originally assigned to: @jeremystretch on GitHub.

Environment

  • Python version: 3.5.2
  • NetBox version: 2.6.7

Proposed Functionality

Currently, the way you create tags is:

  • go to an arbitrary device (etc)
  • type in a random tag

I would like it so that you can only choose between predefined tags, in the same way as Manufacturers, Platforms, Roles etc.

The change boils down to:

  1. The way to create a new tag would be to go to /extras/tags/ (which already exists) and click an Add button
  2. When adding tags to an object, you can only choose between pre-defined ones.

I would expect the normal object perms mechanism to be able to prevent unauthorized users from creating new tags.

CSV import of tags would be nice-to-have, if easy to implement.

Use Case

This prevents accidental use of junk tags / mispelled tags, and uncontrolled addition of tags. Even if you are happy with a free-for-all, you can grant permissions to everyone to create tags, they at least have to make a conscious decision to go create a new tag.

It also gives a clearer opportunity to define the properties of a tag, such as its colour, when creating it. Currently you have to first apply it to a device, then change its colour.

Database Changes

None.

External Dependencies

None.

This is perhaps just a clearer proposal for #2727

Originally created by @candlerb on GitHub (Nov 21, 2019). Originally assigned to: @jeremystretch on GitHub. ### Environment * Python version: 3.5.2 * NetBox version: 2.6.7 ### Proposed Functionality Currently, the way you create tags is: - go to an arbitrary device (etc) - type in a random tag I would like it so that you can only choose between predefined tags, in the same way as Manufacturers, Platforms, Roles etc. The change boils down to: 1. The way to create a new tag would be to go to `/extras/tags/` (which already exists) and click an Add button 2. When adding tags to an object, you can only choose between pre-defined ones. I would expect the normal object perms mechanism to be able to prevent unauthorized users from creating new tags. CSV import of tags would be nice-to-have, if easy to implement. ### Use Case This prevents accidental use of junk tags / mispelled tags, and uncontrolled addition of tags. Even if you are happy with a free-for-all, you can grant permissions to everyone to create tags, they at least have to make a conscious decision to go create a new tag. It also gives a clearer opportunity to define the properties of a tag, such as its colour, when creating it. Currently you have to first apply it to a device, *then* change its colour. ### Database Changes None. ### External Dependencies None. This is perhaps just a clearer proposal for #2727
adam added the status: acceptedtype: deprecation labels 2025-12-29 18:24:51 +01:00
adam closed this issue 2025-12-29 18:24:51 +01:00
adam commented 2025-12-29 18:24:52 +01:00
Author
Owner
Copy Link

@hellerve commented on GitHub (Nov 21, 2019):

On the operational side I’m kind of torn because I get that getting tags wrong is too easy as it currently stands, and it’s nice to have a more controlled environment for them to be created. I also think that they should be as lightweight & simple to add and delete, and this process would make it a little too daunting IMO.

On the technical side I see the problem that we’re currently using a third-party plugin for tags and outsource most of the work of handling tags to that plugin, and changing the workflow would be going against the grain of the plugin. We could probably change the plugin or roll it ourselves, but that’s a bigger change, and in the “rolling it ourselves” case it also introduces a whole lot of technical debt into the system. In either case, it definitely doesn’t have “No database changes” and “no external dependencies”.

I’m not going to argue for or against it, but I want to make clear that this is in fact kind of a major change, and definitely something that we should be taking on lightly.

@hellerve commented on GitHub (Nov 21, 2019): On the operational side I’m kind of torn because I get that getting tags wrong is too easy as it currently stands, and it’s nice to have a more controlled environment for them to be created. I also think that they should be as lightweight & simple to add and delete, and this process would make it a little too daunting IMO. On the technical side I see the problem that we’re currently using a third-party plugin for tags and outsource most of the work of handling tags to that plugin, and changing the workflow would be going against the grain of the plugin. We could probably change the plugin or roll it ourselves, but that’s a bigger change, and in the “rolling it ourselves” case it also introduces a whole lot of technical debt into the system. In either case, it definitely doesn’t have “No database changes” and “no external dependencies”. I’m not going to argue for or against it, but I want to make clear that this is in fact kind of a major change, and definitely something that we should be taking on lightly.
adam commented 2025-12-29 18:24:52 +01:00
Author
Owner
Copy Link

@hellerve commented on GitHub (Nov 21, 2019):

Nevermind, I just realized that the dependency only handles tag management in forms and has a base model that we use 🤦‍♂. Mea maxima culpa.

@hellerve commented on GitHub (Nov 21, 2019): Nevermind, I just realized that the dependency only handles tag management in forms and has a base model that we use 🤦‍♂. Mea maxima culpa.
adam commented 2025-12-29 18:24:52 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Nov 24, 2019):

You can already do this somewhat using permissions, no? Just remove the permission to create a new tag?

@tyler-8 commented on GitHub (Nov 24, 2019): You can already do this somewhat using permissions, no? Just remove the permission to create a new tag?
adam commented 2025-12-29 18:24:53 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (Nov 24, 2019):

Maybe that's true, but even as a superuser, I don't want to be able to accidentally create new tags by mistyping them. I have done this too many times.

@candlerb commented on GitHub (Nov 24, 2019): Maybe that's true, but even as a superuser, I don't want to be able to accidentally create new tags by mistyping them. I have done this too many times.
adam commented 2025-12-29 18:24:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 19, 2019):

Forcing the creation of tags before they can be assigned is appealing from a development standpoint as it mitigates some issues (mentioned above), however I'm hesitant to remove established functionality without robust feedback from the community. Hoping we can get some solid 👍 / 👎 votes on this.

@jeremystretch commented on GitHub (Dec 19, 2019): Forcing the creation of tags before they can be assigned is appealing from a development standpoint as it mitigates some issues (mentioned above), however I'm hesitant to remove established functionality without robust feedback from the community. Hoping we can get some solid :+1: / :-1: votes on this.
adam commented 2025-12-29 18:24:53 +01:00
Author
Owner
Copy Link

@tyler-8 commented on GitHub (Dec 19, 2019):

I would suggest not using the superuser account as your daily driver account if the concern is mistyping an existing tag. Then you could fully rely on the existing permissions system as is.

That said - I do see value in being able to create tags outside of editing/creating an object (that'd be a different FR though), which I don't think is currently possible in the GUI. That would give you the ability to enter tag comments and choose colors in a much simpler workflow.

[Edit] Seeing in the associated issue (#2727) it sounds like permissions don't behave as I expected with tags.

@tyler-8 commented on GitHub (Dec 19, 2019): I would suggest not using the superuser account as your daily driver account if the concern is mistyping an existing tag. Then you could fully rely on the existing permissions system as is. That said - I _do_ see value in being able to create tags outside of editing/creating an object (that'd be a different FR though), which I don't think is currently possible in the GUI. That would give you the ability to enter tag comments and choose colors in a much simpler workflow. [Edit] Seeing in the associated issue (#2727) it sounds like permissions don't behave as I expected with 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 type: deprecation
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#3023
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?