b82c1db735
It seems that in django>=3.2 the assumption that an implicit primary key would be an AutoField changed to becoming a BigAutoField (64-bit). django warns now Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'. HINT: Configure the DEFAULT_AUTO_FIELD setting or the UsersConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. I think we took the hint to add this as BigAutoField. However, it seems that we probably made the db tables with the smaller field. When we now start the web container we are told that the models don't match. When I ran "makemigrations" it made a bunch of migration files to update to BigAutoField id's. Because the migrations are made during the installation (I'm guessing), the container doesn't have this migration included with it. I think to avoid getting into a mess of migrations, we should just leave this as is. If upstream decides to set this on an application-basis I think that will override this, and we will get a migration as part of the general installation and that will work fine. The problem is just that we're setting it "outside" the installation. Change-Id: I1679631cd4f7ea14563aab07ad4450c35aa90fd8 |
||
|---|---|---|
| .. | ||
| files | ||
| handlers | ||
| tasks | ||
| templates | ||
| README.rst | ||
Role to configure mailman3.