Skip to content

[ci] Added Django 6.0 to CI test matrix#199

Open
nemesifier wants to merge 4 commits into
masterfrom
add-django-6.0-ci
Open

[ci] Added Django 6.0 to CI test matrix#199
nemesifier wants to merge 4 commits into
masterfrom
add-django-6.0-ci

Conversation

@nemesifier
Copy link
Copy Markdown
Member

Checklist

  • I have read the OpenWISP Contributing Guidelines.
  • I have manually tested the changes proposed in this pull request.
  • I have written new test cases for new code and/or updated existing tests for changes to existing code.
  • I have updated the documentation.

@nemesifier nemesifier added the dependencies Pull requests that update a dependency file label Jan 14, 2026
@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Jan 14, 2026

📝 Walkthrough

Walkthrough

Updates to add and verify compatibility with newer Django versions: CI now tests Django 6.0, requirements expand Django upper bound to <6.1 and point openwisp-utils to master. README compatibility tables updated (Python 3.9+ entry and multiple Django compatibility rows). Tests in admin and admin inline were relaxed to check for geometry/image content text rather than specific HTML widget structure. ReadOnlyMixin now disables form fields (field.disabled = True) and sets widget.read_only = True for view-only handling, with expanded docstring describing Django 6.0+ behavior.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 1 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Description check ⚠️ Warning The PR description is incomplete. It only includes a partial checklist without addressing the required sections of Description of Changes, Reference to Existing Issue, and Screenshots. Add the 'Description of Changes' section explaining the changes, include 'Reference to Existing Issue' if applicable, and provide the 'Screenshot' section if relevant.
✅ Passed checks (1 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: adding Django 6.0 to the CI test matrix in the GitHub Actions workflow.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings


📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d1cc0e1 and c8a8021.

📒 Files selected for processing (1)
  • django_loci/base/admin.py
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: Python==3.13 | django~=6.0.0
  • GitHub Check: Python==3.12 | django~=5.1.0
  • GitHub Check: Python==3.12 | django~=5.2.0
  • GitHub Check: Python==3.12 | django~=6.0.0
  • GitHub Check: Python==3.11 | django~=5.1.0
🔇 Additional comments (2)
django_loci/base/admin.py (2)

26-32: Clear and informative docstring.

The docstring effectively explains the Django 6.0+ compatibility approach and the rationale for using disabled instead of readonly. The backward compatibility note for custom widget templates is helpful.


34-59: Sound approach for Django 6.0 compatibility.

The implementation correctly addresses Django 6.0's changed behavior:

  1. Setting field.disabled = True renders widgets fully while preventing edits—the HTML disabled attribute ensures browser-disabled inputs are not submitted
  2. Preserving widget.read_only = True maintains backward compatibility with custom templates
  3. Django's form machinery adds an additional safety layer by ignoring any submitted values for disabled fields and using the initial value instead

The permission logic is correct, applying only to users with view-only access (view permission without change permission).

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.


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

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)

35-41: Add matrix exclusions for unsupported Python versions with Django 6.0.

Django 6.0 supports Python 3.12, 3.13, and 3.14. This release also drops support for Python 3.10 and 3.11, requiring Python 3.12 or higher.

The current matrix includes Python 3.10 and 3.11, but Django 6.0 doesn't support these versions. Without exclusions, those CI jobs will fail during installation or test execution.

🔧 Proposed fix to add exclusions
         exclude:
           # Python 3.13 supported only in Django >=5.1.3
           - python-version: "3.13"
             django-version: django~=4.2.0
           - python-version: "3.13"
             django-version: django~=5.0.0
+          # Python 3.10 and 3.11 are not supported in Django 6.0
+          - python-version: "3.10"
+            django-version: django~=6.0.0
+          - python-version: "3.11"
+            django-version: django~=6.0.0
📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4f38773 and 693587a.

📒 Files selected for processing (1)
  • .github/workflows/ci.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (15)
  • GitHub Check: Python==3.12 | django~=5.2.0
  • GitHub Check: Python==3.13 | django~=5.1.0
  • GitHub Check: Python==3.12 | django~=6.0.0
  • GitHub Check: Python==3.11 | django~=5.0.0
  • GitHub Check: Python==3.13 | django~=5.2.0
  • GitHub Check: Python==3.11 | django~=5.1.0
  • GitHub Check: Python==3.12 | django~=4.2.0
  • GitHub Check: Python==3.10 | django~=4.2.0
  • GitHub Check: Python==3.12 | django~=5.0.0
  • GitHub Check: Python==3.11 | django~=4.2.0
  • GitHub Check: Python==3.12 | django~=5.1.0
  • GitHub Check: Python==3.10 | django~=5.1.0
  • GitHub Check: Python==3.11 | django~=5.2.0
  • GitHub Check: Python==3.10 | django~=5.0.0
  • GitHub Check: Python==3.10 | django~=5.2.0

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

coderabbitai[bot]
coderabbitai Bot previously approved these changes Jan 14, 2026
@github-project-automation github-project-automation Bot moved this from To do (general) to In progress in OpenWISP Contributor's Board Jan 14, 2026
- Remove expectation of img tag for floorplan images in readonly mode
- Remove expectation of geometry map div in readonly location views
- Update floorplan image assertion to use name instead of url for object locations
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@README.rst`:
- Around line 66-70: The Python compatibility table in README.rst has duplicate
version key "1.1" with conflicting requirements; update the second "1.1" entry
(the line showing ">=3.9") to the correct version (e.g., "1.2") so each version
key is unique and matches its intended Python requirement, ensuring the table
rows read "1.0 >=3.7", "1.1 >=3.8", "1.2 >=3.9", "dev >=3.10" (or the correct
version label your project uses).
🧹 Nitpick comments (2)
requirements.txt (1)

5-5: Same concern: pinning to master branch.

As noted in requirements-test.txt, using the master branch creates reproducibility issues. This should be updated to a tagged release once openwisp-utils publishes Django 6.0 support.

requirements-test.txt (1)

3-3: Pinning to master branch introduces CI instability risk.

Using the master branch tarball means CI builds may break unexpectedly when upstream changes are pushed. The latest stable release (v1.2, Oct 2025) does not support Django 6.0, which explains the master branch dependency. Once OpenWISP releases a stable version with Django 6.0 support, pin to that version.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 693587a and 66de0dd.

📒 Files selected for processing (5)
  • README.rst
  • django_loci/tests/base/test_admin.py
  • django_loci/tests/base/test_admin_inline.py
  • requirements-test.txt
  • requirements.txt
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (16)
  • GitHub Check: Python==3.13 | django~=5.1.0
  • GitHub Check: Python==3.13 | django~=5.2.0
  • GitHub Check: Python==3.11 | django~=4.2.0
  • GitHub Check: Python==3.11 | django~=5.0.0
  • GitHub Check: Python==3.11 | django~=5.1.0
  • GitHub Check: Python==3.13 | django~=6.0.0
  • GitHub Check: Python==3.12 | django~=6.0.0
  • GitHub Check: Python==3.12 | django~=5.1.0
  • GitHub Check: Python==3.10 | django~=5.2.0
  • GitHub Check: Python==3.11 | django~=5.2.0
  • GitHub Check: Python==3.12 | django~=5.0.0
  • GitHub Check: Python==3.12 | django~=5.2.0
  • GitHub Check: Python==3.12 | django~=4.2.0
  • GitHub Check: Python==3.10 | django~=4.2.0
  • GitHub Check: Python==3.10 | django~=5.0.0
  • GitHub Check: Python==3.10 | django~=5.1.0
🔇 Additional comments (4)
README.rst (1)

72-78: LGTM!

The Django version compatibility table is well-structured and correctly documents the supported Django versions for each release.

django_loci/tests/base/test_admin.py (1)

244-245: LGTM - appropriate relaxation for Django 6.0 compatibility.

The assertion now checks for the presence of the image URL rather than a specific <img> tag structure. This accommodates Django 6.0's readonly field rendering changes while still validating that the image URL is present in the response.

django_loci/tests/base/test_admin_inline.py (1)

903-908: Inconsistent image assertion between readonly tests.

This test uses fl.image.name (line 908), while test_readonly_indoor_location (line 883) uses fl.image.url. These properties return different values:

  • .name: relative path (e.g., floorplans/test.png)
  • .url: full URL path (e.g., /media/floorplans/test.png)

Is this inconsistency intentional due to different rendering contexts in Django 6.0, or should both tests use the same property?

requirements.txt (1)

1-1: Version constraint is appropriate. Django 6.0 was released stably on December 3, 2025, making the <6.1.0 upper bound suitable for Django 6.0 support.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

Comment thread README.rst
Comment on lines 66 to 70
1.0 >=3.7
1.1 >=3.8
1.1 >=3.9
dev >=3.10
=========== ==============
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Duplicate version entry in Python compatibility table.

There are two entries for version 1.1 with different Python requirements (>=3.8 on line 67 and >=3.9 on line 68). This appears to be an error—one of these should likely be a different version number (e.g., 1.2).

Suggested fix
 =========== ==============
 django-loci Python version
 1.0         >=3.7
-1.1         >=3.8
-1.1         >=3.9
+1.1         >=3.8
+1.2         >=3.9
 dev         >=3.10
 =========== ==============
🤖 Prompt for AI Agents
In `@README.rst` around lines 66 - 70, The Python compatibility table in
README.rst has duplicate version key "1.1" with conflicting requirements; update
the second "1.1" entry (the line showing ">=3.9") to the correct version (e.g.,
"1.2") so each version key is unique and matches its intended Python
requirement, ensuring the table rows read "1.0 >=3.7", "1.1 >=3.8", "1.2 >=3.9",
"dev >=3.10" (or the correct version label your project uses).

Django 6.0 no longer renders widgets for readonly fields. Instead,
readonly fields display the plain text value of the field.

- Remove assertions checking for 'geometry-div-map' widget in readonly views
- Remove assertions checking for 'id_indoor_map' widget in readonly views
- Add assertion to verify geometry value is displayed as text
- Update comment to explain Django 6.0 behavior change
Django 6.0 changed how readonly fields are handled in the admin. Setting
read_only=True on a widget no longer renders the widget - instead it shows
only plain text values.

The recommended approach for Django 6.0+ is to disable the field instead
of marking it readonly. This allows the widget to render fully while
preventing editing, giving readonly users an interactive but non-editable
view of the field (e.g., a functional but non-interactive map).

Changes:
- Modify ReadOnlyMixin.set_readonly_attribute() to use field.disabled=True
- Keep read_only attribute on widget for backwards compatibility
- Add explanatory comments about Django 6.0 behavior change
- All 58 tests pass including readonly field tests

This preserves the intended UX where view-only users can see interactive
map widgets while being prevented from making changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

1 participant