Any authenticated participant can now start a recording on trusted
and public rooms. This is essential, requested by many users, and
should encourage people to authenticate on public rooms. It also
means the starter may hold no role on the room, so who gets access
to the recording has to be decided explicitly.
The part open to discussion is the recording access: who should be
owner/admin on the recording. This commit picks the simplest
design:
* The room's owners and administrators get an `OWNER`
`RecordingAccess`: they can retrieve, download, stop and delete
the recording.
* The starter gets a `MEMBER` `RecordingAccess`, unless they already
own or administer the room, in which case they get `OWNER`. A
member can retrieve and download the recording but cannot delete
it: deletion is irreversible and affects everyone with access, so
it stays with the people responsible for the room.
* Everyone with an access, members included, receives the
"recording ready" email.
* Room roles are copied when the recording starts: later changes
to the room's accesses do not affect existing recordings.
The people responsible for a meeting should control its recording
and transcript, and whoever initiated it should be able to access
it on their own. The starter owns the output and is responsible for
sharing it with their colleagues.
Recording members could not retrieve a recording before this
commit. No code path created such accesses until now, but one added
manually through the admin now grants read access.
One constraint is respected: the summary service creates a doc,
and the docs API can only attribute it to a single owner. The
summary therefore goes to the oldest access, and the starter's
access is created before the room owners/admins ones, so the
starter receives it. The lookup does not filter on role, since the
starter may only be a member. The previous lookup took `.first()`
with the default newest-first ordering, which with several owners
would have picked a room admin.
Alternatives considered:
* Granting access to every participant allowed to record, or to
those present when the recording starts: it requires listing
participants from LiveKit and creating an access for each, and
widens access by default, for a need no user has expressed.
* A `creator` attribute on the recording row: it only adds a
migration without adding value to access control, so it was
dropped.
* Restricting access to the link owner even when someone else
starts the recording: some organizations may want this for
security reasons, but it is YAGNI until a few large clients ask
for it.
I think we should contribute to Docs' api to allow sharing the
transcription document with several users.
Before this commit:
1. Rooms could be hard-deleted from the internal API (unused by the
frontend).
2. The external API had no way to delete a room.
3. The admin could hard-delete rooms.
What this commit does:
1. Add a `deleted_at` field to Room. `Room.objects` hides soft-deleted
rooms; `all_objects` stays the default manager so deleted rooms keep
reserving their slug and PIN code.
2. Soft delete rooms from the internal API (replacing hard delete) and
the external API (new DELETE, owner only, `rooms:delete` scope). The
LiveKit room is closed and its participants disconnected; if closing
fails, the soft delete is rolled back and an error is returned.
3. Answer 410 Gone on detail operations on a deleted room (after
permission checks). Its can still be read but not modified.
4. Close LiveKit rooms recreated after deletion by participants still
holding a valid token (room_started webhook).
5. Frontend: participants in the call land on the feedback page without
the rejoin button, lobby participants see a "meeting deleted" screen,
and opening the link shows an error instead of recreating the room.
Untouched by this commit:
- The admin still hard-deletes rooms, without closing the LiveKit room,
and lists soft-deleted rooms alongside active ones.
- Purging soft-deleted rooms (hard deletion) is not handled.
- Scheduled deletion is not handled.
Explain the switch to django-lasuite marketing: removed BREVO_*
and MARKETING_SERVICE_CLASS settings, new LASUITE_MARKETING_BACKEND
and LASUITE_MARKETING_PARAMETERS variables, dummy backend default,
and the now-required Celery worker.
The `Unreleased` section of `UPGRADE.md` was not bumped when v1.33
was released, so follow-up changes landed under the wrong heading.
Reorganize the file so v1.33 is properly closed and a fresh
`Unreleased` section is opened on top.
Add new options to query start-start recording API. A resolution
("540p", "720p", "1080p") and a profile ("talking_heads", "text", "mixed")
are resolved to provide a width, height, fps and bitrate which
are passed on to the encoder. Using profiles allows for some flexibility
on quality if necessary without changing front facing user config.
Co-authored-by: sarthakbahal <sarthakbahal.45@gmail.com>
The media ingresses and their ExternalName services defaulted to the
MinIO service of the development stack, which is now Garage.
Self-hosted relying on these defaults must set serviceMedia*.host and the
upstream-vhost annotations explicitly, see UPGRADE.md.
Recordings used to be finalized by an inbound notifications sent by
S3. This tied the recording lifecycle to bucket notifications, adding
complexity and dependency to limited S3 services.
The LiveKit egress_ended webhook, added as a fallback in aee1847, does
the same job without any object-storage dependency. Make it the only
mechanism: RecordingEventsService.handle_complete is now called on
EGRESS_COMPLETE / EGRESS_LIMIT_REACHED unconditionally, instead of only
when RECORDING_STORAGE_EVENT_ENABLE is False. Remove the storage-event
path entirely.
This commit introduces a boilerplate inspired by https://github.com/numerique-gouv/impress.
The code has been cleaned to remove unnecessary Impress logic and dependencies.
Changes made:
- Removed Minio, WebRTC, and create bucket from the stack.
- Removed the Next.js frontend (it will be replaced by Vite).
- Cleaned up impress-specific backend logics.
The whole stack remains functional:
- All tests pass.
- Linter checks pass.
- Agent Connexion sources are already set-up.
Why clear out the code?
To adhere to the KISS principle, we aim to maintain a minimalist codebase. Cloning Impress
allowed us to quickly inherit its code quality tools and deployment configurations for staging,
pre-production, and production environments.
What’s broken?
- The tsclient is not functional anymore.
- Some make commands need to be fixed.
- Helm sources are outdated.
- Naming across the project sources are inconsistent (impress, visio, etc.)
- CI is not configured properly.
This list might be incomplete. Let's grind it.
lebaudantoine