fix(conversations): apply the selected preset's parameters when creating a conversation - #6649
Conversation
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/33898044737/artifacts/9946813233 |
eb2dcca to
b6bd25c
Compare
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/33950426057/artifacts/9964745178 |
b6bd25c to
0d12eca
Compare
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/33961731118/artifacts/9968253024 |
0d12eca to
86afe4c
Compare
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/34091550865/artifacts/10007189181 |
6f175b7 to
f916e09
Compare
…ing a conversation The creation screen sent only the preset identifier, but the endpoint derives just the conversation attributes from it and stores whatever parameters the request carried. Voice rooms were therefore neither listable nor expiring, and channels granted call and media permissions instead of reactions only. Allowing guests now sets the room type, so the switch creates a public conversation instead of having no effect, and the password travels in the creation request where the server supports it. Servers without conversation-creation-all are served by follow up requests instead, which no longer discard a conversation that was already created when one of them fails. Assisted-by: Claude Code:claude-opus-5 Claude-Session: https://claude.ai/code/session_014YnDswTbCmRrVETnwE4twB Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
f916e09 to
bfd84fb
Compare
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/34105529188/artifacts/10012945676 |
…alog state RoomCreationOptions already knows whether it's rendering the "set password" or "change password" row, so let it pass an onClick directly instead of having ConversationOption re-infer the click target from switch nullness and its own password state read. Assisted-by: Claude Code:claude-sonnet-5 Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
|
/backport to stable-25.0.x |
The conversation creation screen sent only the preset identifier to the creation endpoint. That
endpoint derives just the conversation attributes from it and stores whatever parameters the request
carried, so the parameters of the selected conversation type never arrived:
(257), which contradicts our own
nc_channel_descriptionstring.roomTypewas hardcoded to group, so nopublic conversation was ever created, and the password was then set on a private one.
On top of that the redundant
POST /listableafter creation is gone, the voice room type is hiddenwhere calls are disabled server wide, and servers without
conversation-creation-allare served byfollow-up requests instead of silently losing the participants, the description and the listable
state.
This is the first of three stacked PRs; the conversation types themselves move to the presets
endpoint in the follow-up.
🖼️ Screenshots
No visual change other than the voice room type being hidden where calls are disabled server wide,
so no before/after shots.
🚧 TODO
🏁 Checklist
/backport to stable-xx.xCapabilities checked:
conversation-creation-all,conversation-creation-password(added here),conversation-presets,announcement-presetandconfig => call => enabled.🤖 AI (if applicable)
🤖 Generated with Claude Code
https://claude.ai/code/session_014YnDswTbCmRrVETnwE4twB