[rdenarie]

Why
A call people already joined, attached to a single planned event, stayed listed as upcoming in the video list drawer until 15 minutes before the event, hiding a running call from its invitees (EXO-91106, eXIP 7.3.0.41 US06).

How

• VisioMerge.js: normalizeEvent marks an entry recurrent when the agenda payload carries an occurrence, a parent or a recurrence (computed and exceptional occurrences of a series). canHoldCall no longer applies the JOIN_AHEAD_MS window to a single event: its started call makes it live whatever its date. An occurrence of a series keeps the 15-minute rule, so a later occurrence never shows the call of one the user declined, which the drawer does not read.
• VisioCard.vue: a live scheduled meeting shows no elapsed time before its slot's start. Ad hoc calls and rooms, whose start is the server's, are not compared with the browser's clock.
• The drawer is shared by every provider: the same rule applies to Jitsi calls.

Known limits

• An occurrence of a series joined more than 15 minutes ahead still shows as upcoming.
• A participant list that stays stale after a participant leaves is not addressed here.

Verification
A throwaway harness (not committed, per the frontend norm) over normalizeEvent and buildEntries on raw agenda payloads, with the card's progress rule transcribed from VisioCard.vue, run on git archive 57d358c5 of VisioDrawer: node simple.mjs js/VisioMerge.js → 12 PASS / 0 FAIL.

Scenario	Result
Single event in 2 h, call started	live, no elapsed time
Single event in 5 days, call started	live
Single event in 2 h, call not started	upcoming
Single event in progress, call started	live, elapsed time shown
Single event ended 1 h ago, call still started	live
Series occurrence in 2 h, call started	upcoming
Series occurrence in 10 min, call started	live
Today's occurrence declined (not read), next week's accepted, call started	upcoming
Exceptional occurrence in 2 h, call started	upcoming
Payload with a parent id only, or a recurrence only, in 2 h, call started	upcoming
Ad hoc call whose server start is 30 s ahead of the browser	elapsed time shown

The base code fails the two single-event-ahead scenarios; marking recurrent from the occurrence alone fails the parent-id-only and recurrence-only ones.
mvn -pl webapp -am verify -Pcoverage -Prun-its at 57d358c: Tests run: 171, Failures: 0, Errors: 0, Skipped: 0, BUILD SUCCESS. eslint on both files: 0 errors.

Knowledge: pending — EXO-91195

Classification (advisory on this developer FB, computed on git diff origin/feature/security-fix...HEAD at 57d358c): N2 — no REST/DAO/schema/ACL surface touched, behaviour change in the drawer shared by every call provider. The eXip is classified on its full diff at its feature/mips integration PR.

[rdenarie]

Self-review close-out — EXO-91106 @ 57d358c

#	Finding	Severity	Status
R1-1	A later accepted occurrence of a series held the running call of an occurrence the user declined (shown live, Join led to the declined meeting)	🟡	✅ Fixed — occurrences of a series keep the 15-minute rule; only single events are exempt
R1-2	Elapsed time compared a server start with the browser clock	🟡	✅ Fixed — only a scheduled slot is compared with the browser clock
R1-3	JOIN_AHEAD_MS doc overstated the rule	🟢	✅ Fixed
DC	Elapsed-time guard applied to ad hoc calls and rooms	🟢	✅ Fixed — guard limited to entries with a slot end

Final reviewer round at 57d358c: clean, nothing to fix.

Verified conform: recurrent matches the agenda REST payloads (computed occurrences carry occurrence, exceptional ones occurrence and parent, single events neither); normalizeEvent → buildEntries → liveCallOwners → canHoldCall has no other consumer; visibility (canParticipate, the ACCEPTED read) and join are untouched; no REST, DAO, schema, ACL or i18n change. Throwaway harness 12/12 at 57d358c, full module suite 171 tests, 0 failures.

Classification: N2, advisory on this developer FB (shared drawer, no REST/DAO/schema/ACL surface), computed at 57d358c; the eXip is classified at its feature/mips integration PR.