Unexpected migration behaviour with django.contrib.auth

Hey folks,

Thanks so much for the replies! @leandrodesouzadev - I really like your strategy of having a separate set_permissions management command - I guess the idea is to make this idempotent, so that it can be run after every migrate whether or not any new permissions need to be created, and will always result in the correct permissions state? Thank you!

@sevdog , aha, yep, you’re quite correct - the gist is an “edited highlights” of the parts of my app that give the problem, the app itself is open source (and you can see the PR that prompted this question here, but there’s a lot going on there so figured i’d try and pull out a more focused example). Leandro is correct though - relying on django.contrib.auth isn’t needed in this instance, as it’s loaded in INSTALLED_APPS, and the permissions are getting created, just in a slightly unexpected order.

I now (thanks to the “related posts” feature) suspect this is the same underlying issue that is described here which also proposes another solution - explicitly calling django.contrib.auth’s permissions syncinc function from within each migration that changes the schema, but i think i favour Leandro’s solution, as it wouldn’t require us to remember the fix every time we change our schema, just to ensure that permissions are always set in the additional admin command to be run after all migrations.

Thanks all!