Every ModelAdmin now emits an ECS audit event when an object is created,
changed or deleted, and when a bulk action runs. Actions are templated
as admin.<target>.<verb>, after the model name. A signed-in account
without staff access reaching the admin is recorded as a denied
admin.access.
The wiring is a custom AdminSite installed through AdminConfig.default_site:
it mixes the auditing into every admin class at registration, including the
ones Django declares, so a new ModelAdmin is covered without doing anything.
It hangs off log_addition, log_change, log_deletions and get_actions, which
Django calls in every path, rather than off save_model. Deletions noted by
log_deletions are emitted from delete_model and delete_queryset, once their
outcome is known.
Changed field names are always reported; their values only for the
admin_values each model is registered with, and never for anything that
looks like a secret. An account acted upon is reported as user.target:
the target itself when it is a user, else the account its model
registers as user_target, as the user an access grants a role to. The
emitter derives it for every event, so user.provision names the user it
creates as well.
Describe the audit event shape, the catalogue, how views and other code
emit events, the environment variables configuring them, how the
project registers its actions, models and authentication classes.
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.
Add a ROOM_DELETED_RETENTION_DAYS setting, unset by default. The
purge_inactive_rooms command now also deletes rooms soft deleted more
than that many days ago, whether they are inactive or not. Inactive
soft-deleted rooms are now purged under ROOM_INACTIVITY_DELETION_DAYS
too. As for inactive rooms, a room holding a saved recording that has
not expired yet is kept.
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>
Switch from the minio client to the boto3 python client, in the metadata
collector agent and the summary service. AWS_S3_REGION_NAME is passed
as-is to boto3, the region is not looked up from the bucket.
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.
Recording lifecycle previously relied exclusively on the MinIO storage-hook
endpoint to transition from STOPPED to SAVED, which made the system dependent
on MinIO bucket notifications and lifecycle configuration. Introduce support
for LiveKit egress_ended webhook (EGRESS_COMPLETE, EGRESS_LIMIT_REACHED) as
an alternative finalization mechanism for self-hosted deployments that do
not use MinIO / S3 hooks.
Change behavior of existing configuation RECORDING_STORAGE_EVENT_ENABLE.
When the LiveKit mechanism is enabled (RECORDING_STORAGE_EVENT_ENABLE=False),
RecordingEventsService.handle_complete is triggered from
LiveKitEventsService._handle_egress_ended.
We should be able to use other transcription services,
those usually relie on response_format="diarized_json"
to produce what we need.
Note that as part of this change, we stop using
openai library for making this call to avoid
casting the result to a payload that doesn't
contain the elements we used to rely on.
(setting this specific format auto cast the
results in openai lib). We keep the old
result class used.
Expose RECORDING_ENCODING_* settings to override the default LiveKit
Egress preset (H264_720P_30). When RECORDING_ENCODING_ENABLED is True,
the provided width/height/framerate/bitrate/keyframe values are passed
as advanced EncodingOptions. Lowering framerate and bitrate reduces
recording file size and egress worker CPU load.
Disabled by default, preserving current behaviour.
Add detailed documentation on signaling server configuration
and associated environment variables to help administrators properly
configure WebRTC connection establishment.
Add documentation noting subtitle functionality is currently under
active development to set appropriate expectations for administrators
and prevent deployment assumptions about feature maturity.
Add comprehensive telephony documentation explaining system requirements
and component interactions to help administrators understand infrastructure
needs.
Add comprehensive recording documentation explaining system requirements
and component interactions to help administrators understand infrastructure
needs and troubleshoot recording functionality.
Expand authentication documentation to clarify supported authentication
mechanisms and their configuration nuances, helping administrators
understand different authentication flows and choose appropriate methods
for their deployment security requirements.
briquet