45 lines
1.7 KiB
Markdown
45 lines
1.7 KiB
Markdown
# 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.
|