Upgrade back-end code from Django 4.2 to 5.2 LTS

[acwhite211]

Fixes #8046

Upgrade Django from 4.2 to LTS version 5.2.

https://docs.djangoproject.com/en/6.0/releases/5.2/

Changes:

• removed USE_L10N (A localization setting, that is now defaulted to true)
• added new migration to fix many-to-many fields (django-generated)
• Migrated GET request to logout to a POST request to be in HTTP (and django) spec
  • changed the logOut user tool (in Header/userToolDefinitions) to point to a new front-end endpoint: /specify/command/logout to match the cache clearing endpoint
  • this new endpoint (defined in Router/Routes.tsx) renders the Logout component
  • the Logout component makes the POST request to the backend and returns a loading screen

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add relevant issue to release milestone
• Add pr to documentation list
• Add automated tests

Testing instructions

Note for dev testers
If you are testing on your local instance, change

specify7/docker-compose.yml

Line 61 in 4da3228

command: npx webpack -w --mode development --color

from --mode development to --mode production. This is because in development mode, webpack will duplicate web requests, which when sending the POST request, the first one is aborted by the second, which causes ajax to flash an error on-screen before refreshing to the login page. This does not happen in production mode, as far as I have seen.

• Ensure strings are localized correctly
  • verify that labels are not raw schema labels, i.e. ensure schema config labels are respected.
  • Ensure that switching languages behaves correctly.
• Log out from several locations
  • Ensure that no error dialogs flash on the screen
  • Logging back in takes you to the splash screen
• General UI/UX testing
  • especially the workbench and attachments/attachment bulk upload

Summary by CodeRabbit

• New Features

  • Added a dedicated logout flow with loading feedback and redirect handling.
  • Improved logout navigation from collection, agent, and user menus.

• Bug Fixes

  • Updated relationship mappings and database migrations for more reliable data handling.
  • Improved compatibility with current Django and authentication tooling.

• Refactor

  • Simplified URL routing across backend endpoints without changing their primary destinations.
  • Updated date/time and boolean field configuration for Django compatibility.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Changes

Django platform upgrade

Layer / File(s)	Summary
Runtime and test foundation requirements.txt, requirements-testing.txt, specifyweb/settings/__init__.py	Django, authentication, JWT, and testing dependencies are upgraded. USE_TZ is disabled and USE_L10N is removed.
URL routing modernization specifyweb/backend/*/urls.py, specifyweb/specify/urls.py, specifyweb/backend/context/testurls.py, specifyweb/urls.py	Regex routes are replaced with path() routes. Typed converters are used for task IDs, viewset levels, and property names.
Model field compatibility migration specifyweb/specify/utils/case_insensitive_bool.py, specifyweb/specify/migrations/*	NullBooleanField now extends the local BooleanField. A migration updates many-to-many field metadata and subsequent migration dependencies.

Frontend logout flow

Layer / File(s)	Summary
Logout route and component specifyweb/frontend/js_src/lib/components/Router/Routes.tsx, specifyweb/frontend/js_src/lib/components/Logout/index.tsx	A lazy command/logout route loads Logout. The component posts to /accounts/logout/, displays loading state, handles errors, and redirects to login.
Logout entry points specifyweb/frontend/js_src/lib/components/ChooseCollection/index.tsx, specifyweb/frontend/js_src/lib/components/Core/Main.tsx, specifyweb/frontend/js_src/lib/components/Header/userToolDefinitions.ts	Logout links now target /specify/command/logout/. The collection action sends an explicit POST request.

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant Router
  participant Logout
  participant AccountsLogout
  participant LoginPage
  User->>Router: Open command/logout
  Router->>Logout: Lazy-load Logout
  Logout->>AccountsLogout: POST /accounts/logout/
  AccountsLogout-->>Logout: Return response
  Logout->>LoginPage: Redirect with nextUrl

Loading

Possibly related PRs

• specify/specify7#8229: Updates overlapping testing dependencies such as pytest, coverage, and pytest-django.
• specify/specify7#8237: Updates migration metadata for SpecifyUser.spprincipals.

Suggested reviewers: carolinedenis, emenslin

🚥 Pre-merge checks | ✅ 4 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Automatic Tests	⚠️ Warning	The PR changes 20 paths, adds a logout component and migrations, but changes no test files; focused searches found no related tests, and the checklist leaves automated tests unchecked.	Add automatic tests for the POST logout flow and redirect, route registration, and migration/settings behavior, or document why each changed behavior does not require coverage.
Testing Instructions	⚠️ Warning	Instructions cover logout symptoms but omit explicit checks for the new migration, USE_TZ behavior, and numerous path() API routes; “several locations” and “General UI/UX testing” are vague.	Add exact logout locations and expected POST, redirect, nextUrl, cache, and localization results. Add migration/relationship, timezone/date, and representative backend URL checks with steps.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the primary change: upgrading the back-end from Django 4.2 to Django 5.2 LTS.
Linked Issues check	✅ Passed	The dependency, settings, migration, URL, field, and logout changes support the Django 5.2 upgrade objective in [#8046].
Out of Scope Changes check	✅ Passed	The changes are related to Django 5.2 compatibility and the linked logout-flow requirements; no unrelated code changes are evident.

✨ Finishing Touches 💡 1

⚔️ Resolve merge conflicts 💡

• Resolve merge conflict in branch issue-8046

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch issue-8046

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Warning

One or more dependencies are approaching or past End-of-Life.
Please plan upgrades accordingly.

STATUS=WARNING
NODE_VERSION=20
NODE_CYCLE=20
EOL_DATE=2026-04-30
DAYS_REMAINING=-105

--- Node.js ---
Version: 20
EOL: 2026-04-30
Status: WARNING

STATUS=OK
PYTHON_VERSION=3.12
PYTHON_CYCLE=3.12
EOL_DATE=2028-10-31
DAYS_REMAINING=810

--- Python ---
Version: 3.12
EOL: 2028-10-31
Status: OK

STATUS=OK
DJANGO_VERSION=5.2
DJANGO_CYCLE=5.2
EOL_DATE=2028-04-30
DAYS_REMAINING=626

--- Django ---
Version: 5.2
EOL: 2028-04-30
Status: OK

[rijulpoudel]

I completed the manual testing:

• Labels are localized correctly and schema-config labels are respected
• Switching languages works correctly
• Logging out from several locations works without a flashing error
• Logging back in takes me to the splash screen
• General UI/UX testing
• WorkBench
• Attachments and attachment bulk upload

Everything worked as expected except that opening the Attachments panel displays two error dialogs. Both report:

'datetime.date' object has no attribute 'utcoffset'
Not sure if it's related to the upgrade. The Attachments features still worked after dismissing the dialogs.

[g1rly-c0d3r]

@rijulpoudel I think that is outside of the scope of this PR, I think it is happening here:

specify7/specifyweb/backend/attachment_gw/dataset_views.py

Line 60 in 6e084ca

'timestamp': datetime.datetime.now(datetime.UTC).isoformat()

as that is the only place we use datetime.UTC, which is not a part of django. Might be a different issue to write up.

[combs-a]

• Ensure strings are localized correctly
  • verify that labels are not raw schema labels, i.e. ensure schema config labels are respected.
  • Ensure that switching languages behaves correctly.
• Log out from several locations
  • Ensure that no error dialogs flash on the screen
  • Logging back in takes you to the splash screen
• General UI/UX testing
  • especially the workbench and attachments/attachment bulk upload

---

It's a bit difficult to tell if switching languages is behaving correctly, as several are incomplete, but from what I could see all of the expected areas were still localized.

Edited since I hadn't spotted Rijul's testing before I submitted my review--apologies! There's a lot of screenshots that can be moved over to the issue

Rijul's issue didn't exist in main from my testing. It appears that date fields having no utcoffset is causing issues saving or accessing any newly created records, since I created a record set from Workbench, and found that the timestamps were off, and that I could not open the recordset(s). This affects other new records, such as Collection Objects.

We should wait until this issue is fixed regardless of whether it's within the scope of this PR or not to check general UI/UX, as it's affecting the basic functionality.

Below are all of the screenshots of the UTC offset issues I got.

From this branch:

When opening the record set(s):

Specify 7 Crash Report - 2026-07-29T16_47_28.993Z.txt

From main:

There are some oddities in timestamps because of this. Newly created record sets/queries appear to have a different timestamp from main. Above is an example--the two recordset created '5 hours ago' were actually created in main, recently, while the one recordset created an hour ago (ID 498) was created in the branch and appears to be accurate. On main, recordset 498 has a timestamp of 'now.'

Further evidence: from the branch, you can see that it the most recent query was created 15 minutes ago. This is accurate. On main, however, the timestamp created says 'now.'

Database is sdnhmherps_2026_07_17 with a login of sdnhmherp for verification/testing, as well. If this gets split into another issue, I'll move all of this over.

Thank you for the work on this Eos! 🫡

[g1rly-c0d3r]

I don't think this should be a different issue actually. I combed through the Django release notes again, as well as our Django settings, saw something I missed. In 5.0, they set the default value for USE_TZ from False to True. We never specified that setting, so our code dealt with timezone info. The change to True meant that now the datetime.date object was stored in UTC, not local time. I believe changing this to False will fix the regressions that @combs-a and @rijulpoudel noticed. I will do some testing myself first.

[rijulpoudel]

• Ensure strings are localized correctly
  • verify that labels are not raw schema labels, i.e. ensure schema config labels are respected.
  • Ensure that switching languages behaves correctly.
• Log out from several locations
  • Ensure that no error dialogs flash on the screen
  • Logging back in takes you to the splash screen
• General UI/UX testing
  • especially the workbench and attachments/attachment bulk upload

All tests pass like before and no error message on the Attachment Panel this time. I did not encounter any crashes, utcoffset errors, flashing error dialogs, or other UI regressions. Excellent job Eos!

[CarolineDenis]

@g1rly-c0d3r