Remove local development URLs (localhost:3000 and 127.0.0.1:3000) from
CORS_ALLOWED_ORIGINS configuration. This restricts CORS to only allow
requests from the production domain (attunehearttherapy.com), improving
security by preventing unauthorized cross-origin requests from
development environments.
- Replace dynamic admin_dashboard_url construction with hardcoded production URL (https://attunehearttherapy.com/admin/dashboard)
- Add target="_blank" to admin notification email button to open dashboard in new tab
- Improves user experience by preventing email client navigation disruption
Add extra blank lines in booking_system and meetings views to improve
code structure and visual separation between logical sections. This
enhances code readability without affecting functionality.
Changes:
- booking_system/views.py: added blank line after availability_system section
- meetings/views.py: added blank line after get_queryset method
- Replace generic placeholder data with specific examples in API root documentation
- Update example email from 'user@example.com' to 'saanii929@gmail'
- Update example names from 'John Doe' to 'Saani Iddi'
- Update example phone number to '+233552732025'
- Add POST method support to user_appointments endpoint
- Add request_fields and example_request to user_appointments documentation
Note: Consider using generic placeholder data instead of real personal information in API documentation examples.
- Change support email from hello@attunehearttherapy.com to admin@attunehearttherapy.com across all email templates
- Remove support contact section from admin notification template
- Standardize email addresses by hardcoding admin email in templates
- Remove unused CSS comment from base email template
This ensures consistent support contact information across the application and directs user inquiries to the appropriate admin channel.
Changed the fallback admin email from 'hello@' to 'admin@attunehearttherapy.com' in the email service. This ensures admin notifications are sent to the correct administrative email address when ADMIN_EMAIL setting is not configured.
Add `null=True` to `jitsi_meet_url` and `jitsi_room_id` fields in the AppointmentRequest model. This allows these optional fields to be NULL at the database level in addition to accepting blank values, which is the proper Django pattern for optional string-based fields.
This change requires a database migration to be generated and applied.
- Increase max_length from 100 to 255 for first_name and last_name encrypted fields
- Increase phone field max_length from 20 to 255 to accommodate encryption overhead
- Add 'id' field to AppointmentRequest admin list_display for easier reference
- Remove redundant docstring from _convert_to_datetime method
The increased field lengths ensure adequate storage for encrypted data, which typically requires more space than plaintext values.
Enhanced the API root documentation for the appointments system with improved formatting and updated description to include "flexible availability" feature. Restructured the endpoint documentation for better readability and maintainability while preserving all endpoint information including Jitsi meeting integration details.
Changed the user_appointment_stats endpoint from GET to POST method
and added email as a required field. This change allows for more
flexible querying of appointment statistics by requiring user email
in the request body rather than URL parameters.
BREAKING CHANGE: The /api/meetings/user/appointments/stats/ endpoint
now accepts POST requests instead of GET and requires an email field
in the request body.
Modified UserAppointmentStatsView to accept POST requests instead of GET
and retrieve email from request body rather than from authenticated user.
This allows querying appointment statistics for any email address instead
of being limited to the current user's email.
Changes:
- Changed HTTP method from GET to POST
- Added email parameter extraction from request.data
- Updated filter to use provided email instead of request.user.email
Add CSRF_TRUSTED_ORIGINS setting to whitelist the production domains
(attunehearttherapy.com and its api subdomain) for CSRF verification.
This ensures secure cross-origin POST requests from the frontend.
Also add documentation comment for CORS configuration section.
Modified requirements.txt to update project dependencies. The file
appears to have encoding changes or significant content modifications.
Unable to display specific package changes due to binary diff format.
**Security Improvements:**
- Fix DEBUG setting to properly parse boolean from environment variable
- Remove hardcoded SMTP password fallback, rely solely on env var
- Update Celery to use REDIS_URL environment variable instead of hardcoded localhost
**Static File Serving:**
- Add WhiteNoise middleware for production-grade static file serving
- Configure CompressedManifestStaticFilesStorage for optimized delivery
**Configuration Updates:**
- Enable CORS credentials support
- Remove duplicate CORS_ALLOWED_ORIGINS configuration
- Update API documentation title from "Blog API" to "Attune Heart Therapy API"
- Clean up code formatting and remove unnecessary comments
These changes make the application more secure by eliminating hardcoded
credentials and more deployment-ready by properly handling environment
variables and serving static files efficiently in production.
Consolidate CORS_ALLOWED_ORIGINS default value onto a single line
to fix formatting issue. Removes unnecessary line break and trailing
whitespace that was splitting the URL string across multiple lines.
Add attunehearttherapy.com to the CORS_ALLOWED_ORIGINS setting to enable cross-origin requests from the production domain. This allows the frontend application hosted at the production URL to communicate with the backend API.
Change ALLOWED_HOSTS from a hardcoded list to be read from environment
variable with comma-separated values support. Maintains '*' as default
fallback for backward compatibility. This allows more restrictive host
configuration in production environments while improving security posture.
- Install and configure drf-spectacular for OpenAPI/Swagger documentation
- Add Swagger UI endpoints at /api/schema/ and /api/docs/
- Configure SPECTACULAR_SETTINGS with API metadata
- Refactor meetings views from function-based to class-based views
(ScheduleAppointmentView, RejectAppointmentView, AvailableDatesView,
UserAppointmentsView, AppointmentStatsView, UserAppointmentStatsView)
- Update URL patterns to use new class-based views
- Simplify ALLOWED_HOSTS configuration to accept all hosts
This improves API discoverability through interactive documentation
and modernizes the codebase by using class-based views for better
code organization and reusability.
Add documentation for the new user-specific appointment statistics endpoint
to the API root view. This endpoint provides authenticated users with their
appointment analytics including total requests, pending reviews, scheduled,
rejected, and completed appointments along with completion rate.
The endpoint is available at /api/meetings/user/appointments/stats/ and
requires authentication via GET request.
- Add dj-database-url package for parsing DATABASE_URL
- Replace hardcoded PostgreSQL config with DATABASE_URL environment variable
- Add connection pooling with conn_max_age and health checks
- Fallback to SQLite for local development when DATABASE_URL is not set
- Remove obsolete production config comments
- Update requirements.txt with new dependency
This change improves deployment flexibility by supporting standard DATABASE_URL format commonly used in cloud platforms (Heroku, Railway, etc.) while maintaining backward compatibility with local development using SQLite.
Replace SQLite database configuration with PostgreSQL to improve
scalability and production readiness. PostgreSQL configuration uses
environment variables (POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD,
POSTGRES_HOST, POSTGRES_PORT) for flexible deployment across different
environments.
- Remove redundant comments for cleaner readability
- Simplify COPY commands using relative paths
- Condense pip installation RUN command to single line
- Add 3 workers to gunicorn for improved concurrent request handling
- Remove accidentally included .dockerignore content from Dockerfile
This improves Dockerfile maintainability and production performance
by configuring multiple gunicorn workers for better throughput.
