Latest
Migration Guide for the 3.10 series 🚀¶
Version 3.10 adds four new model fields, so unlike 3.0.1 this upgrade does require a migration. No existing field changes meaning, and no data is rewritten — every new field has a default that preserves the previous behaviour for existing rows.
Steps for Upgrading to Version 3.10.x:¶
-
Backup Your Database:
- As a best practice, always back up your current database before performing an upgrade. This precaution ensures you can restore your application to its previous state if needed.
-
Update Package:
- Upgrade to the latest version by running:
-
Run Migrations:
- This package intentionally does not ship migration files, so generate them against your own project first:
- The new fields are:
Model Field Default Effect Configdefault_to_service_durationTrueAvailability accounts for each service's duration Configslot_gap_timeNULLNo rest time enforced between appointments Serviceuse_service_duration_as_slotTruePer-service fallback when the Config flag is off StaffMemberslot_gap_timeNULLFalls back to the Config value -
Review your slot availability:
default_to_service_durationdefaults toTrue, which means services longer than your configured slot duration will now correctly reserve the time they need. If you were relying on the previous behaviour — where a long service only blocked one slot — your availability will legitimately look tighter after upgrading. Set the flag toFalsein the Config model to opt back out per service.
-
Review and Test:
- After upgrading, thoroughly test your application to ensure all functionalities are working as expected with the new version.
- Pay particular attention to appointment booking, since that is where the slot changes are visible.
Optional follow-ups¶
- Cleanup task: if
django_qis in yourINSTALLED_APPS, a daily cleanup of abandoned appointment requests is now scheduled automatically the first time the app starts. SetAPPOINTMENT_CLEANUP_DAYSif 7 days is not the retention you want, and runpython manage.py cleanup_appointment_requests --dry-runfirst if you'd like to see what it would remove. - Custom templates: nothing to do unless you want them. If you had previously forked a template, you can now override it by name instead — see Custom templates.
Troubleshooting:¶
- Issues Post Migration:
- If you encounter issues after migration, consult the release notes for the specific updates that might affect your setup.
- Check the Django logs for any error messages that can provide insights into issues.
Important Notes 📝:¶
- As with any upgrade, testing in a development or staging environment before applying changes to your production environment is highly recommended.
- Upgrading from a version before 2.0.0? Read the 2.1.0 migration guide first — that release did change the schema significantly.