Skip to content
Snippets Groups Projects
Commit 92815998 authored by zpg-hq2-h's avatar zpg-hq2-h Committed by Fynn Becker
Browse files

Incase migrations create the same permission twice 

When upgrading from Django 2.0 to 3.2, Django decided
to create the one or other permission with the exact
same name but with a different content_type!

That's why we needed to ensure 'our' content_type
is the one we want to get and not the duplicate from
django!
parent b8ac7d0d
No related merge requests found
Show whitespace changes
Inline Side-by-side
  • Art :lizard: @lukyanch

    mentioned in commit 23e86d6f

     ·

    mentioned in commit 23e86d6f

    Toggle commit list
  • Art :lizard: @lukyanch ·

    Umm... Sorry I had to revert it.

    This is whole the point of .get by codename without content_type, such that this function can use permissions created by django or django.contrib which mostly have content_type different from the user model.

    What was the particular project / situation when it refused to work? I am almost sure it had something to do with models being moved from one project to another, and old permissions never cleaned up...

    @beckerfy @zpg-hq2-h

  • Art :lizard: @lukyanch ·

    So basically it uses the user model content type as fallback, when it needs a permission, but has no good model to attach it to. (I will add more comments into the code. I will also try to workaround the situation you experienced.)

    Edited by Art
  • Art :lizard: @lukyanch ·

    14c5d9ff

  • Fynn Becker :crab: @beckerfy ·

    It was research (of course it was). It uses a custom 'view_project' permission and by upgrading Django it also introduced a 'view_project' permission generated by Django because there are view permissions now and research happens to have a Project model.

    But yeah, indeed makes sense to not include the content_type in the lookup.

0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment