fix(sounds): fall back when the server has no play-sounds capability

[bakiburakogun]

☑️ Resolves

• Ref Sound setting not saved across restarts talk-desktop#1087 (sound setting not saved across restarts)

Since Talk 24 the sounds store reads the user's "play sounds" setting from the capabilities (config.call.play-sounds). That works against a Talk 24+ server, but servers before Talk 24 don't have that capability at all, so getTalkConfig('local', 'call', 'play-sounds') returns undefined there: sounds are off after every start and the toggle in the settings dialog doesn't stick, which is the talk-desktop issue above again (the 2.2.x desktop client bundles the Talk 24 frontend and still supports NC 32/33 servers), just with the default flipped to silent.

The capability is read once at module level and stays the first source for users; for older servers there are two fallbacks:

1. capability (Talk 24+)
2. value remembered in browser storage
3. enabled, as before Talk 24

Guests are unchanged: browser storage first, then the capability (guests_play_sounds), then enabled. On change, setPlaySounds() gets hasUserAccount && hasPlaySoundsCapability, so a server that can't hand the value back isn't written to either and the setting stays in the browser. Against Talk 24+ nothing changes.

Known limitation on older servers: a change made in another browser/device isn't picked up until the toggle is used locally, since there is no way to read the value back. That's the same trade-off @Antreesy described in the linked issue.

Added a small spec for the store's initial value and the action; the store computes its initial value at import time, so the tests reload the module.

🖼️ Screenshots

n/a

🚧 Tasks

• Code
• Tests

🏁 Checklist

• ⛑️ Tests are included or not possible
• 📘 User documentation in https://github.com/nextcloud/documentation/tree/master/user_manual/talk is updated or not required
• 📗 Admin documentation in https://github.com/nextcloud/documentation/tree/master/admin_manual/talk is updated or not required
• 📕 Developer documentation in docs/ is updated or not required
• 🔖 Capability is added or not needed

[nickvergessen]

Hi @bakiburakogun thanks for your frequent involvement. In case you are interested you can send me an email to <my github handle>@nextcloud.com so I can invite you to our Talk Developer chat.
Also the Nextcloud Conference and Contributor Week is happening soon in Berlin, if you are close and want to join us there: https://nextcloud.com/conference-2026/

[bakiburakogun]

Thanks a lot @nickvergessen, glad it's useful. I'll get in touch by email about the developer chat, and the conference sounds great, I'll see if I can make it to Berlin.

Side note: the Psalm failure here doesn't seem related to this change (no PHP touched), the other recent PRs show the same error in RoomPlugin.php.

[Antreesy]

Thanks! Left some notes on the new changes: approach is correct to close the gap Talk Desktop has with old server, but we can do it in a simpler way

Don't worry about Static analysis / static-psalm-analysis CI - it might just be blocked on forks

[bakiburakogun]

All three applied.

The capability is read once at module level now, and the fallback order is the one you sketched. I kept your order as written, so a guest with a remembered value still wins over the capability. Say so if you meant the capability to come first for guests as well.

Dropping loadState had a knock-on effect worth mentioning. With hasUserAccount && hasPlaySoundsCapability as the first argument, setPlaySounds() already takes its BrowserStorage.setItem() branch when the server cannot take the value, so the explicit mirror in setShouldPlaySounds() became a second write of the same key. I removed it rather than keep both.

Tests updated accordingly: the two loadState cases are gone, and the old-server case now asserts setPlaySounds(false, 'no') instead of a direct BrowserStorage.setItem(). The ten cases pass locally and eslint is clean on both files.

[Antreesy]

Checked locally, adjusted test so they don't contradict (e.g. BrowserStorage.setItem should be called for guests) - see last commit

a guest with a remembered value still wins over the capability

Correct, otherwise they won't be able to rewrite it

I removed it rather than keep both.

Yup, service function already takes care of it

Thanks again!

[Antreesy]

/backport to stable35

[Antreesy]

/backport to stable34