Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Django Permission 'codenames` Duplicated #2624

Closed
bdlamprecht opened this issue Nov 28, 2018 · 2 comments
Closed

Django Permission 'codenames` Duplicated #2624

bdlamprecht opened this issue Nov 28, 2018 · 2 comments
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@bdlamprecht
Copy link
Contributor

Environment

  • Python version: 3.6
  • NetBox version: v2.5-beta2

Steps to Reproduce

I'm using @cimnine's Docker deployment instructions mentioned here.
Although I couldn't get that one-liner to work for whatever reason, if I manually execute that code, I still see these permission codenames:

add_interface
add_interfaceconnection
change_interface
change_interfaceconnection
delete_interface
delete_interfaceconnection
view_interface
view_interfaceconnection
add_interfaceconnection         <- Duplicated
change_interfaceconnection      <- Duplicated
delete_interfaceconnection      <- Duplicated
view_interfaceconnection        <- Duplicated

This causes problems as it is expected for each permission to have a unique codename.

Expected Behavior

The permissions should take effect without erroring out.

Observed Behavior

When I try and bring up my Dockerized version of NetBox using v2.5-beta2, I get this error:

  File "/usr/local/lib/python3.6/site-packages/django/db/models/query.py", line 403, in get
    (self.model._meta.object_name, num)
django.contrib.auth.models.MultipleObjectsReturned: get() returned more than one Permission -- it returned 2!
@bdlamprecht
Copy link
Contributor Author

This is a screenshot from the WebUI admin page:
image

You can see the duplicated permissions much easier this way.

@jeremystretch
Copy link
Member

This is happening because we delete the InterfaceConnection model and then introduce a new InterfaceConnection proxy model in the 0066_cables DCIM migration under v2.5. For reference:

v2.4.8:

netbox=> select * from auth_permission where codename like '%interfaceconnection%';
 id  |              name               | content_type_id |          codename          
-----+---------------------------------+-----------------+----------------------------
 112 | Can add interface connection    |              38 | add_interfaceconnection
 113 | Can change interface connection |              38 | change_interfaceconnection
 114 | Can delete interface connection |              38 | delete_interfaceconnection
(3 rows)

After migrating to v2.5-beta2:

netbox=> select * from auth_permission where codename like '%interfaceconnection%';
 id  |              name               | content_type_id |          codename          
-----+---------------------------------+-----------------+----------------------------
 112 | Can add interface connection    |              38 | add_interfaceconnection
 113 | Can change interface connection |              38 | change_interfaceconnection
 114 | Can delete interface connection |              38 | delete_interfaceconnection
 315 | Can add interface connection    |              37 | add_interfaceconnection
 316 | Can change interface connection |              37 | change_interfaceconnection
 317 | Can delete interface connection |              37 | delete_interfaceconnection
 318 | Can view interface connection   |              37 | view_interfaceconnection
(7 rows)

So there are actually two issues here:

  1. The content type and permissions for the old InterfaceConnection model aren't getting deleted along with the model. This appears to be normal Django behavior, but we can accomplish this manually in the migration.

  2. The new proxy console/power/interface connection models are getting add/change/delete permissions created for them, which are unnecessary and unusable. I'll open a new issue for this second point.

In the meantime, this can be resolved by cleaning out stale content types with the following management command:

manage.py remove_stale_contenttypes

@jeremystretch jeremystretch added type: bug A confirmed report of unexpected behavior in the application status: accepted This issue has been accepted for implementation beta labels Nov 28, 2018
jeremystretch added a commit that referenced this issue Nov 28, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jan 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

2 participants