[bmestrallet]

Why
After a meeting held in eXo's video meeting, its recordings must be found from the meeting itself, by the agenda and by the assistant, with the viewer's own rights (EXO-91998; Tech Spec note 55129 §2.2, §2.3, §3.2, §3.5).

How

• uploadFile: the recording upload carries its own limit, exo.webconferencing.recording.uploadLimitMB (0 = unlimited by default), registered under a random upload id and removed in finally; the failure path now passes the upload info, so a refused recording is notified.
• saveFile: new optional mixin exo:callRecording (conf/webconferencing-nodetypes.xml) stamps the call id, provider, owner, title, start and save dates; exo:title becomes « call title – date », the node name is unchanged.
• CallProvider.findCallId(url): new optional SPI method, null by default.
• WebConferencingService.getCallRecordings / getCallRecordingsByConference, in storage/CallRecordingStorage: call-level check (space membership or super manager; owner or participant), then a JCR-SQL query run as the viewer (made the current conversation state around the session), merged with the unstamped files named after the call; exo.webconferencing.recording.occurrenceGraceHours (12) is added to to. Each recording carries startedDate, read from the recorder's file name in the recorder's time zone, exo.webconferencing.recording.recorderTimeZone (default UTC; an invalid value falls back to UTC with a warning): Jibri writes its JVM's local time with no zone, and a local time repeated when clocks go back reads as its earlier instant.
• REST: GET /webconferencing/rest/calls/{callId}/recordings and GET /webconferencing/rest/recordings/byConference?url=, optional from/to; fixed message codes on 400/403/404/500, Cache-Control: no-store.
• MCP tool get_meeting_recordings(conference_url, recorded_from?, recorded_to?), read-only: MeetingRecordingMcpTool, its ai-tool-definitions.json entry, mcp-server-tools as a provided dependency and the -parameters flag. A date it cannot read (RFC3339 or yyyy-MM-dd only) is refused with a message naming the argument and the accepted formats.

The jitsi PR implementing findCallId compiles once this one is merged and published.

Upgrade / Ops: where the Jibri JVM does not run in UTC, set exo.webconferencing.recording.recorderTimeZone to its zone (e.g. Europe/Paris); otherwise every recording's start is shifted by that offset. Recording uploads are no longer capped by exo.uploadLimit (200 MB by default): set exo.webconferencing.recording.uploadLimitMB to bound them.

Knowledge: Meeds-io/eng-standards#695, Meeds-io/eng-standards#696

This change is classified N1 at 842b1090 — its approver must be an Archi/Dev who knows it is N1, not an approval on AI review alone; author ≠ approver.

🤖 Generated with Claude Code

[bmestrallet]

Self-review close-out (AI, rounds 2–4 of the delivery #429 · #430 · #431 · jitsi#173 · agenda#1241 · agenda#1242 · ppd#648)

Rounds after the first fixes: delivery checks ×3, a fresh reviewer (round 2), a fresh closing reviewer (rounds 3–4, clean).

#	Sev	Finding	Status
D1	🟡	Jibri writes the time in a recording's file name in its JVM's local zone (FileSink.kt:38, LocalDateTime.now()), not UTC	✅ ccefae9a: exo.webconferencing.recording.recorderTimeZone (default UTC, invalid → UTC + warning); pinned, mutation-verified
D4	🟡	configuration.xml line endings converted in the fix commit	✅ restored, 3-line diff
D5	🟢	DST overlap unstated	✅ Javadoc + aRepeatedLocalTimeReadsAsItsEarlierInstant
R1	🟡	startedDate unasserted past recordingStart; zone wiring untested	✅ 335242c5; mutants at the call site (UTC, null) both fail the suite
R2/F1	🟡	Body missed recorderTimeZone, and that uploads are no longer capped by exo.uploadLimit	✅ body: How + Upgrade / Ops
R5	🟢	Orphaned test Javadoc, fully-qualified names	✅ 335242c5
F3	🟢	MeetingRecordingModel missing @param startedDate	✅ 388ac29d
R4	🟡	Tech Spec note still says UTC	➖ spec resync at close-out

Verified conform (closing reviewer, in source): the read as the viewer, traced through the JCR engine (SessionProvider.getSession → RepositoryImpl.login → BaseAuthenticator.authenticate() = current state) and pinned by a test that sees the login identity; the random upload id and its limit removed on every path; the JCR-SQL statement parsed by the repository's own parser; call-level access before the repository ACL; the MCP tool's identity from the request.

Tests at 335242c5: mvn -o verify -Pcoverage -pl services: 66 run, 0 failures, 0 errors; all coverage checks met. 388ac29d adds Javadoc only.

This change is classified N1 at 388ac29d — its approver must be an Archi/Dev who knows it is N1, not an approval on AI review alone; author ≠ approver.