Corp/backend/scheduling/README.md

Scheduling module

scheduling extends the third-party django-scheduler app used by the API under /api/v1/schedule/.

Responsibilities

• patch.py fixes recurrence parameter handling in schedule.Event;
• models.py stores EUSRR-specific calendar bindings;
• services.py contains scheduling integration logic;
• rules.py registers object-level calendar and event rules;
• notifications/ creates calendar notifications through notify.send;
• signals.py and notifications/signals.py connect lifecycle events.

The app must follow schedule in INSTALLED_APPS. SchedulingConfig.ready() applies the compatibility patch and imports signals.

Permissions

Rules are based on CalendarRelation and include can_view_calendar, can_edit_calendar, can_delete_calendar, can_view_event, can_edit_event and can_delete_event. API viewsets add their own model/object permission checks; the current endpoint and payload contract is published in /api/docs/.

Notifications

Creating, changing or deleting an event can call notify_event_created, notify_event_changed or notify_event_cancelled. Recipients are active users related to the calendar; the actor is excluded when available. Delivery then uses the common notification router, preferences, DND and Celery.

Do not add a direct dependency on django-notifications-hq or call notification senders directly. See the notification guide.

Verification

cd backend
pytest tests/scheduling tests/test_schedule_permissions.py tests/test_celery_schedule.py -q

Additional schedule API coverage is distributed across domain suites; use pytest --collect-only -q | rg schedule to discover it.