Pulp

Solution 1 seems more user-friendly since user doesn't need to do anything, however this will run with every django-migrate.

Solution 2 is a Django-native way to fill in the database, it's explicit and can be run on_demand. It's less user-friendly since it's one more step.

I hear a strong resistance in the community with regards to signals, so maybe solution #2 is the way.
I'm also somewhat concerned what to do if/when data model changes for the data we load in. Is any of the solutions provide a better way to handle that? and also a check that a certain migration applied before loading the data.

https://docs.djangoproject.com/en/2.2/howto/initial-data/#providing-data-with-fixtures

Note this means that if you change one of the rows created by a fixture and then run loaddata again, you’ll wipe out any changes you’ve made.

It seems like fixture way handles existing data and it overwrites it in case someone changed any row.

The overwriting nature of fixtures I think is not a good fit for this need because users can customize the AccessPolicy at any point and we can't overwrite it.

I also read the #django recommendation to not use signals, but I didn't read any evidence with it, so I put it into the fear, uncertainty, and doubt category. Solution 1 has a great user experience, so I think we should prototype solution 1 and see how reliable (or not) it is for us.