starred/modoboa-modoboa

Fork 0

mirror of https://github.com/modoboa/modoboa.git synced 2026-04-25 00:46:03 +03:00

[GH-ISSUE #3029] 1.7.0 to 2.1.2 upgrade not straightforward, New Admin not working, DJango complaints with (models.W042) #1737

New issue

Closed

opened 2026-02-27 11:18:51 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 11:18:51 +03:00

Owner

Originally created by @gianks on GitHub (Jul 16, 2023).
Original GitHub issue: https://github.com/modoboa/modoboa/issues/3029

Impacted versions

OS Type: Debian
OS Version: Bookworm
Database Type: PostgreSQL
Database version: 15.3
Modoboa: 2.1.2
installer used: Wish i was an elephant, probably so
Webserver: Nginx

Steps to reproduce

Upgraded via PIP, had to install all current plugins to allow migrate.
Also had to drop dkim view as suggested by other issue report, then recreated it.
Done manual frontend installation. To be noted, frontend was not already present, so using default config.json.

Current behavior

Problem 1:
Django reports a lot of warnings all time and i keep receiving the notifications every 2 minutes about it.

admin.Alarm: (models.W042) 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 AdminConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.

I believe the update procedure did not work properly in setting up some django configuration

Problem 2:
Old Admin works, proposes new Admin which just redirects to the home page in a loop.
/frontend reports:
Sorry
The requested page does not exist.

Again I think that my installation is kind of inconsistent.

Expected behavior

Automagic dealing with dkim view.
No errors/warning reported by cron manage.py commands, hence no sysadmin email harassment.
New frontend being accessible (not sure even if the old one shall be still here or not)

I guess a self coherence status script might be desirable in cases like these to detected what is there, what should not be and what really is.

This installation was started in 2018 as of my memories. It got updated up to 1.7 without much issues but there were already minor warnings reported by python about nginx plugin few times a day. Those are gone now, while these new django warnings are appearing constantly. It seems that the last round of sys and modoboa updates, including a PIP refresh of the venv, has fixed some things anyway, what's left seems to be purely modoboa related.

Thanks!

Originally created by @gianks on GitHub (Jul 16, 2023). Original GitHub issue: https://github.com/modoboa/modoboa/issues/3029 # Impacted versions * OS Type: Debian * OS Version: Bookworm * Database Type: PostgreSQL * Database version: 15.3 * Modoboa: 2.1.2 * installer used: Wish i was an elephant, probably so * Webserver: Nginx # Steps to reproduce Upgraded via PIP, had to install all current plugins to allow migrate. Also had to drop dkim view as suggested by other issue report, then recreated it. Done manual frontend installation. To be noted, frontend was not already present, so using default config.json. # Current behavior Problem 1: Django reports a lot of warnings all time and i keep receiving the notifications every 2 minutes about it. admin.Alarm: (models.W042) 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 AdminConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'. I believe the update procedure did not work properly in setting up some django configuration Problem 2: Old Admin works, proposes new Admin which just redirects to the home page in a loop. /frontend reports: Sorry The requested page does not exist. Again I think that my installation is kind of inconsistent. # Expected behavior Automagic dealing with dkim view. No errors/warning reported by cron manage.py commands, hence no sysadmin email harassment. New frontend being accessible (not sure even if the old one shall be still here or not) I guess a self coherence status script might be desirable in cases like these to detected what is there, what should not be and what really is. This installation was started in 2018 as of my memories. It got updated up to 1.7 without much issues but there were already minor warnings reported by python about nginx plugin few times a day. Those are gone now, while these new django warnings are appearing constantly. It seems that the last round of sys and modoboa updates, including a PIP refresh of the venv, has fixed some things anyway, what's left seems to be purely modoboa related. Thanks!

kerem

2026-02-27 11:18:51 +03:00

closed this issue
added the
feedback-needed

stale
labels

kerem commented

2026-02-27 11:18:52 +03:00

Author

Owner

@gianks commented on GitHub (Jul 16, 2023):

As Django Doc states i've added the following to settings.py
DEFAULT_AUTO_FIELD='django.db.models.AutoField'

This has fixed the million warnings issue (manage.py generate_rights).
But this feels as i am working around something, i expect i would not have had to do so on a clean installation.
But it's some progress...

@gianks commented on GitHub (Jul 16, 2023): As Django Doc states i've added the following to settings.py DEFAULT_AUTO_FIELD='django.db.models.AutoField' This has fixed the million warnings issue (manage.py generate_rights). But this feels as i am working around something, i expect i would not have had to do so on a clean installation. But it's some progress...

kerem commented

2026-02-27 11:18:52 +03:00

Author

Owner

@gianks commented on GitHub (Jul 16, 2023):

Well, apparently i missed that the new frontend is accessible via /new-admin/ and not /frontend/.
Got to the login page but the login does not work.
Ajax request returns a 500. No particular error is reported either by nginx,
"POST /api/v2/token/ HTTP/1.1" 500

or uwsgi/app/modoboa_instance.log,
POST /api/v2/token/ => generated 870 bytes in 202 msecs (HTTP/1.1 500) 7 headers in 244 bytes (1 switches on core 0)

@gianks commented on GitHub (Jul 16, 2023): Well, apparently i missed that the new frontend is accessible via /new-admin/ and not /frontend/. Got to the login page but the login does not work. Ajax request returns a 500. No particular error is reported either by nginx, "POST /api/v2/token/ HTTP/1.1" 500 or uwsgi/app/modoboa_instance.log, POST /api/v2/token/ => generated 870 bytes in 202 msecs (HTTP/1.1 500) 7 headers in 244 bytes (1 switches on core 0)

kerem commented

2026-02-27 11:18:52 +03:00

Author

Owner

@appetrosyan commented on GitHub (Jul 22, 2023):

I encountered the same issues on the regular install. No upgrade. I know it's a Python package so my expectations were low, but holy crap!

@appetrosyan commented on GitHub (Jul 22, 2023): I encountered the same issues on the regular install. No upgrade. I know it's a Python package so my expectations were low, but holy crap!

kerem commented

2026-02-27 11:18:52 +03:00

Author

Owner

@Spitfireap commented on GitHub (Jul 23, 2023):

Hi, @gianks can you share your nginx config ?

@Spitfireap commented on GitHub (Jul 23, 2023): Hi, @gianks can you share your nginx config ?

kerem commented

2026-02-27 11:18:52 +03:00

Author

Owner

@stale[bot] commented on GitHub (Oct 15, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale[bot] commented on GitHub (Oct 15, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

kerem commented

2026-02-27 11:18:52 +03:00

Author

Owner

@appetrosyan commented on GitHub (Mar 17, 2024):

Oh wow! Devs do nothing, the stale bot marks issue as stale and it’s marked as completed! How didn’t I think of that? I thought you’re supposed to fix the issue first!

@appetrosyan commented on GitHub (Mar 17, 2024): Oh wow! Devs do nothing, the stale bot marks issue as stale and it’s marked as completed! How didn’t I think of that? I thought you’re supposed to **fix the issue** first!