Migration of Django Database in Docker image fails with a SystemCheckError

[ebroda]

Description of the issue

As described in #1622 I have some issues with the docker-image. As I was now able to build the image myself (from git @ tag v0.18.2) and continued in the start process (using the docker-compose file), I ended up with the following error and docker stopping the container:

<class 'rest_framework.authtoken.admin.TokenAdmin'>: (admin.E039) An admin for model "myuser" has to be registered to be referenced by TokenAdmin.autocomplete_fields.

Full docker-log (only oeplatform, postgres was started before):

oeplatform_1  | Checking for Configuration
oeplatform_1  | File /app/oeplatform/securitysettings.py does not exist, copying default configuration.
oeplatform_1  | Migrating Databases...
oeplatform_1  | Migrating Django database...
oeplatform_1  | SystemCheckError: System check identified some issues:
oeplatform_1  | 
oeplatform_1  | ERRORS:
oeplatform_1  | <class 'rest_framework.authtoken.admin.TokenAdmin'>: (admin.E039) An admin for model "myuser" has to be registered to be referenced by TokenAdmin.autocomplete_fields.
oep_oeplatform_1 exited with code 1

Steps to Reproduce

1. Build docker image
2. docker-compose up

Ideas of solution

Default configuration data should fulfill the given requirement?

Context and Environment

• Version used: v0.18.2 (self-build docker image based on git @v0.18.2)
• Operating system: Docker
• Environment setup and (python) version: -

Workflow checklist

• [x] I am aware of the workflow in CONTRIBUTING.md

[jh-RLI]

I updated the docker image build workflow because it was pointing to a fixed & very outdated version of the oeplatform. I will fix this within the next few days.

This step of the installation process is missing in the docker setup.

Currently you can only use the docker image for tag v0.18.0.

[ebroda]

Regarding the comment here: https://github.com/OpenEnergyPlatform/oeplatform/issues/1622#issuecomment-2005135147

By fixing the version at 3.14, djangorestframework==3.14, and re-building the docker container, the init works and the server runs. So really seems like the problem is version 3.15 of that lib and the issue you linked in the comment.