# 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](../../docs/guides/NOTIFICATIONS.md).

## Verification

```bash
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.