[fix] Load charts using dashboard domain #528
Conversation
…p#477 Replaced archived django-celery-email with actively maintained django-post-office for async email handling. - Updated requirements.txt: django-celery-email -> django-post-office - Changed email backend configuration in Dockerfile - Updated settings.py to use post_office app conditionally Fixes openwisp#477
…penwisp#477 The archived django-celery-email package has been replaced with django-celery-email-reboot, a maintained fork that provides Django 4.x/5.x compatibility. This is a drop-in replacement with identical API. Changes: - Updated requirements.txt to use django-celery-email-reboot>=4.1.0,<5.0.0 - Changed EMAIL_BACKEND to djcelery_email.backends.CeleryEmailBackend - Updated settings.py to check for djcelery_email backend Testing performed following maintainer's approach: - Built all Docker images successfully with django-celery-email-reboot 4.1.0 - Tested email flow: docker compose run dashboard python manage.py sendtestemail - Verified postfix logs showing successful email pipeline: Django → Celery → Postfix (queue ID 95C4120370E8) - Email queued and delivery attempted successfully The entire email pipeline is working correctly with the new package. Fixes openwisp#477
This change addresses issue openwisp#526 by making monitoring charts load from the dashboard domain instead of the API domain. This prevents SSL certificate issues that can confuse new users when the API domain doesn't have a trusted certificate. Changes: - Added DASHBOARD_BASEURL configuration variable - Changed OPENWISP_MONITORING_API_BASEURL to use dashboard domain - Chart loading now uses the same domain as the dashboard interface Fixes openwisp#526
github-project-automation
bot
moved this to To do (general)
in OpenWISP Contributor's Board
Adityashandilya555
force-pushed
the
fix/chart-loading-use-dashboard-domain
branch
from
f063d92 to
8cb14af
Compare
| OPENWISP_NOTIFICATIONS_HOST = API_BASEURL | ||
| OPENWISP_CONTROLLER_API_HOST = API_BASEURL | ||
| OPENWISP_MONITORING_API_BASEURL = API_BASEURL | ||
| OPENWISP_MONITORING_API_BASEURL = DASHBOARD_BASEURL |
There was a problem hiding this comment.
Would removing OPENWISP_MONITORING_API_BASEURL completely work?
There was a problem hiding this comment.
Yes, removing OPENWISP_MONITORING_API_BASEURL completely should work. I checked the openwisp-monitoring source and the default value is None, which means the charts will use relative URLs and load from the current domain (the dashboard domain).
There was a problem hiding this comment.
Let's do that then and simplify this. This way we don't need to define DASHBOARD_BASEURL.
Keep it simple. Please do manual testing to ensure the approach work and record a video showing the result.
requirements-test.txt
Outdated
| @@ -1,2 +1,3 @@ | |||
| docker>=7.1.0,<7.2.0 | |||
| openwisp-utils[qa,selenium]~=1.2.0 | |||
| sphinx<8.0.0 | |||
There was a problem hiding this comment.
This should not be needed anymore.
There was a problem hiding this comment.
Acknowledged. I've removed it while resolving the merge conflict.
nemesifier
changed the title
nemesifier
changed the title
| OPENWISP_NOTIFICATIONS_HOST = API_BASEURL | ||
| OPENWISP_CONTROLLER_API_HOST = API_BASEURL | ||
| OPENWISP_MONITORING_API_BASEURL = API_BASEURL | ||
| OPENWISP_MONITORING_API_BASEURL = DASHBOARD_BASEURL |
There was a problem hiding this comment.
Let's do that then and simplify this. This way we don't need to define DASHBOARD_BASEURL.
Keep it simple. Please do manual testing to ensure the approach work and record a video showing the result.
2 participants
Checklist
Reference to Existing Issue
Closes #526.
Description of Changes
DASHBOARD_BASEURLconfiguration variable using dashboard domainOPENWISP_MONITORING_API_BASEURLto useDASHBOARD_BASEURLinstead ofAPI_BASEURLScreenshot
Please include any relevant screenshots.