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

Issue saving group ruleset with permissions on DCIM>Interfaces and Virtualization>Interfaces #8358

New Issue
Closed
opened 2025-12-29 20:35:44 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:35:44 +01:00
Owner
Copy Link

Originally created by @ConvexSERV on GitHub (Jul 21, 2023).

NetBox version

v3.5.5

Python version

3.8

Steps to Reproduce

Added a Group Permission on DCIM > Interface, applied to a given group, and constrained by {"device__tenant__slug": "tenant-name"}.

Then add another Group Permission on Virtualization > Interface, applied to the same group, and constrained by {"virtual_machine__tenant__slug": "tenant-name"}.

I was unable to save the ruleset for the group with the following error: Objectpermission-group relationship with this Objectpermission and Group already exists.

Expected Behavior

The ruleset should save without errors.

Observed Behavior

Error returned is: Objectpermission-group relationship with this Objectpermission and Group already exists.

I found a workaround, which is to apply the rule to each user in the group instead of the group. I can save the permission and the effect is the same in the application.
Afterwards, I can go back into the permission entry (the group will be there already), and remove the users. Then ruleset will save without an error.

BTW - Thanks for all of your hard work!

Originally created by @ConvexSERV on GitHub (Jul 21, 2023). ### NetBox version v3.5.5 ### Python version 3.8 ### Steps to Reproduce Added a Group Permission on DCIM > Interface, applied to a given group, and constrained by `{"device__tenant__slug": "tenant-name"}`. Then add another Group Permission on Virtualization > Interface, applied to the same group, and constrained by `{"virtual_machine__tenant__slug": "tenant-name"}`. I was unable to save the ruleset for the group with the following error: Objectpermission-group relationship with this Objectpermission and Group already exists. ### Expected Behavior The ruleset should save without errors. ### Observed Behavior Error returned is: Objectpermission-group relationship with this Objectpermission and Group already exists. I found a workaround, which is to apply the rule to each user in the group instead of the group. I can save the permission and the effect is the same in the application. Afterwards, I can go back into the permission entry (the group will be there already), and remove the users. Then ruleset will save without an error. BTW - Thanks for all of your hard work!
adam added the type: bugstatus: revisions needed labels 2025-12-29 20:35:44 +01:00
adam closed this issue 2025-12-29 20:35:45 +01:00
adam commented 2025-12-29 20:35:45 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jul 23, 2023):

I cannot replicate this. Please revise your steps.

image

@kkthxbye-code commented on GitHub (Jul 23, 2023): I cannot replicate this. Please revise your steps. ![image](https://github.com/netbox-community/netbox/assets/400797/adcec7c0-f628-4c5a-9d9e-4192708c6a26)
adam commented 2025-12-29 20:35:45 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Jul 29, 2023):

I think this is, unfortunately, a quirk of the Django permissions system.

The permission creation window is opened in a new tab/window, when you create the permission, you can assign it to the group within hte permission. This doesn't update it within the group itself, but the permission is already assigned to the group from assigning it in the permission creation page.

It might get cleaned up in the next feature release with the new permission system.

Either way, this hasn't been updated in a week, if it isn't updated by Monday I say we close this out.

@DanSheps commented on GitHub (Jul 29, 2023): I think this is, unfortunately, a quirk of the Django permissions system. The permission creation window is opened in a new tab/window, when you create the permission, you can assign it to the group within hte permission. This doesn't update it within the group itself, but the permission is already assigned to the group from assigning it in the permission creation page. It might get cleaned up in the next feature release with the new permission system. Either way, this hasn't been updated in a week, if it isn't updated by Monday I say we close this out.
adam commented 2025-12-29 20:35:46 +01:00
Author
Owner
Copy Link

@ConvexSERV commented on GitHub (Jul 31, 2023):

@DanSheps that sounds right to me. I was originally thinking that it had to do with device and vm interfaces, but when I went in to reproduce the error, I found the same behavior setting a permission on a completely different object. Please close for now. The work around works if I run into it again.

@ConvexSERV commented on GitHub (Jul 31, 2023): @DanSheps that sounds right to me. I was originally thinking that it had to do with device and vm interfaces, but when I went in to reproduce the error, I found the same behavior setting a permission on a completely different object. Please close for now. The work around works if I run into it again.
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: revisions needed 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#8358
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?