Hybrid meetings (room + Talk conversation) never appear on the Talk dashboard

[Rikdekker]

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

1. Create a calendar event and fill the location field with a physical room (e.g. Meeting room 2.04)
2. Add a Talk conversation to that event with the "Add Talk conversation" button
3. 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:

1. In Talk — also search DESCRIPTION and isolate the URL from the
   surrounding prose. Small and self-contained, but it means matching a link
   inside free text.
2. In the server — make CONFERENCE searchable, 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

[Rikdekker]

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:

1. Talk also searches DESCRIPTION (what fix(calendar): find call links of hybrid meetings #19472 does)
2. The server makes CONFERENCE searchable
3. Calendar writes CONFERENCE, and Talk learns to read it

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/:

LOCATION -> 1 hit
CONFERENCE -> 0 hits
DESCRIPTION -> 1 hit

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]

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