permission for revoking add tag doesn't work #2247

New Issue

adam · 2025-12-29T17:24:04+01:00

adam commented

2025-12-29 17:24:04 +01:00

Originally created by @a31amit on GitHub (Dec 22, 2018).

Environment

Python version: 3.7
NetBox version: 2.5.2

Steps to Reproduce

Revoke "taggit|tag|can add tag" permission.
Add a new tag to any device

Also, I could not understand what is different between permission of taggit|tag vs taggit|tagged item, Having an explanation could be helpful.

Expected Behavior

The user should not be able to add any new tag.

Observed Behavior

Netbox Allow to add new or update tags to the device.

Originally created by @a31amit on GitHub (Dec 22, 2018).  ### Environment * Python version: 3.7 * NetBox version: 2.5.2  ### Steps to Reproduce Revoke "taggit|tag|can add tag" permission. Add a new tag to any device Also, I could not understand what is different between permission of taggit|tag vs taggit|tagged item, Having an explanation could be helpful.  ### Expected Behavior The user should not be able to add any new tag.  ### Observed Behavior Netbox Allow to add new or update tags to the device.

adam added the type: bug status: accepted labels 2025-12-29 17:24:04 +01:00

adam closed this issue

2025-12-29 17:24:04 +01:00

adam commented

2025-12-29 17:24:05 +01:00

@DanSheps commented on GitHub (Dec 30, 2018):

@a31amit When you say "new" tag, is it a completely new tag in all of netbox, or is it a new tag specific to that device?

@DanSheps commented on GitHub (Dec 30, 2018): @a31amit When you say "new" tag, is it a completely new tag in all of netbox, or is it a new tag specific to that device?

adam commented

2025-12-29 17:24:05 +01:00

@jeremystretch commented on GitHub (Jan 4, 2019):

NetBox doesn't enforce permissions specifically for creating or assigning tags. Adding or removing a tag is considered modifying an object, so object type permissions (e.g. "can change devices") are used. Do you have a use case where users should be able to modify an object but not add/remove tags? That might be tricky to implement.

Also, I could not understand what is different between permission of taggit|tag vs taggit|tagged item

This is an unfortunate artifact of the database schema through which tags are represented. A tag is the tag itself, whereas a "tagged item" is the generic relationship between an object and an assigned tag.

@jeremystretch commented on GitHub (Jan 4, 2019): NetBox doesn't enforce permissions specifically for creating or assigning tags. Adding or removing a tag is considered modifying an object, so object type permissions (e.g. "can change devices") are used. Do you have a use case where users should be able to modify an object but not add/remove tags? That might be tricky to implement. > Also, I could not understand what is different between permission of taggit|tag vs taggit|tagged item This is an unfortunate artifact of the database schema through which tags are represented. A tag is the tag itself, whereas a "tagged item" is the generic relationship between an object and an assigned tag.

adam commented

2025-12-29 17:24:05 +01:00

@a31amit commented on GitHub (Jan 4, 2019):

@DanSheps

@a31amit When you say "new" tag, is it a completely new tag in all of netbox, or is it a new tag specific to that device?

I think the behavior is the same for both situations

NetBox doesn't enforce permissions specifically for creating or assigning tags. Adding or removing a tag is considered modifying an object, so object type permissions (e.g. "can change devices") are used. Do you have a use case where users should be able to modify an object but not add/remove tags? That might be tricky to implement.

Well, I originally wanted to retrict users for not creating/change/delete a tags as different people can add a tags with different names but most likely those are similar or same. so that I can keep a consitant names. And During testing permission I found that this issue.

So my usecase which I was trying to handle is user shouldn't able to create a new tag or assign. Only few people who have access can do it as to maintain a consitantcy with tags names.

for example User A, can add "API_SERVICE" as tag where as another user can add "SERVICE_API". Different tags but same meaning.

This could be tricky too. But I propose if we could add some check if user doesn't have a create permission on tags, user should only be assign/remove tags from devices objects rather to create new tag during assignment of tags.

@a31amit commented on GitHub (Jan 4, 2019): @DanSheps > @a31amit When you say "new" tag, is it a completely new tag in all of netbox, or is it a new tag specific to that device? I think the behavior is the same for both situations > NetBox doesn't enforce permissions specifically for creating or assigning tags. Adding or removing a tag is considered modifying an object, so object type permissions (e.g. "can change devices") are used. Do you have a use case where users should be able to modify an object but not add/remove tags? That might be tricky to implement. Well, I originally wanted to retrict users for not creating/change/delete a tags as different people can add a tags with different names but most likely those are similar or same. so that I can keep a consitant names. And During testing permission I found that this issue. So my usecase which I was trying to handle is user shouldn't able to create a new tag or assign. Only few people who have access can do it as to maintain a consitantcy with tags names. for example User A, can add "API_SERVICE" as tag where as another user can add "SERVICE_API". Different tags but same meaning. This could be tricky too. But I propose if we could add some check if user doesn't have a create permission on tags, user should only be assign/remove tags from devices objects rather to create new tag during assignment of tags.

adam commented

2025-12-29 17:24:05 +01:00

@tb-killa commented on GitHub (Jan 9, 2019):

We use Tags for some query stuff and need this options too.
With Tags we allow the Stuff behind netbox to do things automaticly.
If e.g. someone remove tag "nagios" it would result that the automatic check doesnt poll anymore.

The Permissions should be [ADD] , [DELETE] , [MODIFY]
Maybe somethings like [ADD-OWN] and [ADD-Fixed] would be great.
[ADD-Fixed] could be some predefined Tags who are only selectable.

@tb-killa commented on GitHub (Jan 9, 2019): We use Tags for some query stuff and need this options too. With Tags we allow the Stuff behind netbox to do things automaticly. If e.g. someone remove tag "nagios" it would result that the automatic check doesnt poll anymore. The Permissions should be [ADD] , [DELETE] , [MODIFY] Maybe somethings like [ADD-OWN] and [ADD-Fixed] would be great. [ADD-Fixed] could be some predefined Tags who are only selectable.

adam commented

2025-12-29 17:24:05 +01:00

@XioNoX commented on GitHub (Mar 21, 2019):

+1 for [ADD-Fixed]
It would be useful for an admin to define a fixed fist of tags that users are allowed to use.
This is to avoid fragmentation and typoes in the tags (eg. "production", "prod", etc...), while letting the users manage their tags.

@XioNoX commented on GitHub (Mar 21, 2019): +1 for [ADD-Fixed] It would be useful for an admin to define a fixed fist of tags that users are allowed to use. This is to avoid fragmentation and typoes in the tags (eg. "production", "prod", etc...), while letting the users manage their tags.

adam commented

2025-12-29 17:24:05 +01:00

@candlerb commented on GitHub (Apr 12, 2019):

I just came across this problem. I had a number of device with tag "move1". I edited another device and gave it tag "Move1". This was treated as a a completely separate tag but I had no warning.

Worse: I did a bulk remove of tag "Move2" but this had no effect, because the tags were actually "move2".

My suggestion is different: I think you should define allowed tags up-front, and then you should only be allowed to add tags which come from this pre-defined set - rather than allowing arbitrary tags to be added.

This would be consistent with (e.g.) Manufacturer - you have to define Manufacturers up front, and then you can pick from them.

It would also give an opportunity for adding attributes to tags, such as colour and description - I think this feature may have been requested separately. Potentially it would allow tags to be renamed. You could have tags in exclusivity groups (i.e. you are only allowed to assign one tag out of the group at any one time) - I'd really like that. You could define which types of object each tag is permitted to be associated with - in the same way that Device Roles can be marked as applicable to VMs or not.

Maybe this requires a separate feature request, but I think it would also solve the permissions issue here, which boils down to "I don't want random users to be able to create new tags, but to pick from the existing set"

@candlerb commented on GitHub (Apr 12, 2019): I just came across this problem. I had a number of device with tag "move1". I edited another device and gave it tag "Move1". This was treated as a a completely separate tag but I had no warning. Worse: I did a bulk remove of tag "Move2" but this had no effect, because the tags were actually "move2". My suggestion is different: I think you should define allowed tags up-front, and then you should only be allowed to add tags which come from this pre-defined set - rather than allowing arbitrary tags to be added. This would be consistent with (e.g.) Manufacturer - you have to define Manufacturers up front, and then you can pick from them. It would also give an opportunity for adding attributes to tags, such as colour and description - I think this feature may have been requested separately. Potentially it would allow tags to be renamed. You could have tags in exclusivity groups (i.e. you are only allowed to assign one tag out of the group at any one time) - I'd really like that. You could define which types of object each tag is permitted to be associated with - in the same way that Device Roles can be marked as applicable to VMs or not. Maybe this requires a separate feature request, but I think it would also solve the permissions issue here, which boils down to "I don't want random users to be able to create new tags, but to pick from the existing set"

adam commented

2025-12-29 17:24:05 +01:00

@candlerb commented on GitHub (Apr 12, 2019):

Found the other tickets: #2324 (Add color picker for tags) and #2791 (Add comment field for tags)

It looks like #2324 is already implemented in develop-2.6, where an explicit tag model has been created. I would expect that as a side effect of this, there will be permissions for creation, editing and deletion of tags.

@candlerb commented on GitHub (Apr 12, 2019): Found the other tickets: #2324 (Add color picker for tags) and #2791 (Add comment field for tags) It looks like #2324 is already implemented in develop-2.6, where an explicit tag model has been created. I would expect that as a side effect of this, there will be permissions for creation, editing and deletion of tags.

adam commented

2025-12-29 17:24:05 +01:00

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

@candlerb There has always been an explicit Tag model; #2324 does not have any effect on permissions.

@jeremystretch commented on GitHub (Apr 12, 2019): @candlerb There has always been an explicit Tag model; #2324 does not have any effect on permissions.

adam commented

2025-12-29 17:24:06 +01:00

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

I've marked this as a bug because NetBox's behavior deviates from what a user would expect in this context. However, I don't believe this is feasible to implement while automatic tag creation is enabled; there's simply no sane point in the workflow to evaluate tag-related permissions and return a clean error.

Marking this as blocked by #3703.

@jeremystretch commented on GitHub (Dec 13, 2019): I've marked this as a bug because NetBox's behavior deviates from what a user would expect in this context. However, I don't believe this is feasible to implement while automatic tag creation is enabled; there's simply no sane point in the workflow to evaluate tag-related permissions and return a clean error. Marking this as blocked by #3703.

adam commented

2025-12-29 17:24:06 +01:00

@jeremystretch commented on GitHub (Jun 17, 2020):

#3703 has been implemented for the v2.9 release. Permissions will be enforced as automatic tag creation will no longer be supported beginning with v2.9.0.

@jeremystretch commented on GitHub (Jun 17, 2020): #3703 has been implemented for the v2.9 release. Permissions will be enforced as automatic tag creation will no longer be supported beginning with v2.9.0.

adam referenced this issue

2025-12-29 22:20:59 +01:00

[PR #2247] [CLOSED] Added mac_address to IPAddressInterfaceSerializer #12342

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