Repository navigation
Hybrid meetings (room + Talk conversation) never appear on the Talk dashboard #19471
Description
Tip
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Steps to reproduce
- Create a calendar event and fill the location field with a physical room (e.g.
Meeting room 2.04) - Add a Talk conversation to that event with the "Add Talk conversation" button
- Open Talk and look at the dashboard on the home screen
Expected behaviour
The meeting shows up as an upcoming meeting, the same way a call-only meeting does.
Actual behaviour
The meeting is not listed at all.
The Calendar app only writes the call link to LOCATION when that field is
still empty. For a hybrid meeting the room address is already there, so the
link goes to DESCRIPTION instead (see
AddTalkModal.vue#L199-L214).
CalendarIntegrationService searches LOCATION only, so those events are
never found.
This is not an edge case: booking a room and a conversation is the normal
shape of a hybrid meeting.
What I measured
Same calendar, three events, searching for /call/:
| Event | On the dashboard |
|---|---|
Link in LOCATION |
yes |
Room in LOCATION, link in DESCRIPTION |
no |
Room in LOCATION, link in CONFERENCE |
no |
CONFERENCE (RFC 7986) looks like the right property for this, but it cannot
be searched — the CalDAV search index does not cover it:
LOCATION -> 1 hit
CONFERENCE -> 0 hits
DESCRIPTION -> 1 hit
Which way should this go?
Two directions, and I would rather hear which one you prefer before opening a PR:
- In Talk — also search
DESCRIPTIONand isolate the URL from the
surrounding prose. Small and self-contained, but it means matching a link
inside free text. - In the server — make
CONFERENCEsearchable, then Talk can look for the
property that actually means "this is where the call is". Cleaner, but it
is a server change and Calendar would have to start writing that property.
I have option 1 working with unit tests on
this branch,
and I am happy to open a PR if that is the direction you want.
Talk app
Talk app version: 25.0.0
Custom Signaling server configured: no
Custom TURN server configured: no
Custom STUN server configured: no
Server configuration
Operating system: Debian GNU/Linux 13 (trixie), Docker
Web server: Apache
Database: MySQL
PHP version: 8.5.10
Nextcloud Version: 35.0.0
Calendar app version: 6.6.0-rc.2
Activity
Rikdekker commentedon Sep 19, 2026
Some context that may matter for the triage: I have opened nextcloud/calendar#8951, which makes Calendar write the conversation to CONFERENCE (RFC 7986) instead of relying on LOCATION and DESCRIPTION alone.
That adds a third option to the two in the issue above:
The catch is that CONFERENCE is not searchable today. On Nextcloud 35.0.0 with Calendar 6.6.0-rc.2, searching the same calendar for
/call/:So an event that carries the link only in CONFERENCE stays invisible in Talk, even with #19472 applied. That is why #8951 deliberately leaves the LOCATION/DESCRIPTION behaviour in place: with both changes, CONFERENCE is the source of truth and DESCRIPTION keeps the event findable.
It works, but it means Talk finds these events through a fallback rather than through the property that actually describes the online location. If CONFERENCE became searchable, or if Talk could read it some other way, that fallback could eventually go.
Antreesy commentedon Sep 22, 2026
Thanks for opening a PR! We'll discuss internally on how to proceed.
It's a nice addition, but should be clarified from both Calendar/Talk sides, that behaviour and support level are staying the same for any type