Show the single answer poll subtitle when enforceUniqueVote is set - #6704

Goal

Poll.getSubtitle() shows "Select one or more" for polls that only allow a single answer, when those polls were created by the iOS SDK.

getSubtitle() decides the subtitle from maxVotesAllowed alone:

val maxVotes = maxVotesAllowed?.let { min(it, options.size) }
return when (maxVotes) {
    1 -> ...stream_ui_poll_description_single_answer
    null -> ...stream_ui_poll_description_unlimited_answers
    else -> ...stream_ui_poll_description_multiple_answers
}

Poll also carries enforceUniqueVote: Boolean, which is the authoritative "one answer only" signal, and it is ignored here.

Why this only shows up for iOS-created polls. When the Android SDK creates a single-answer poll it sets both fields (AttachmentsPickerPollUtils.kt: maxVotesAllowed = 1, enforceUniqueVote = true), so the 1 -> branch is hit and the subtitle is correct. The iOS SDK sends enforce_unique_vote: true and omits max_votes_allowed (the nil value is skipped by Swift's synthesized Encodable). The Android client therefore deserializes maxVotesAllowed == null, falls into the null -> branch, and renders the unlimited-answers string for a poll that permits exactly one vote.

When this became reachable. #6209 moved maxVotesAllowed from Int to Int? so that null could mean "unlimited votes". That is a deliberate and correct meaning for polls created without a vote limit — this PR does not undo it. The problem is that a payload omitting max_votes_allowed is currently treated as "unlimited" even when enforce_unique_vote: true is present, and enforceUniqueVote is exactly the field that disambiguates the two cases.

The broken branch ordering is unchanged as of the latest release, v7.11.0, and unchanged on current develop (this PR is based on 929fd8c51f4).

Cross-platform inconsistency. StreamChatSwiftUI's PollAttachmentView already checks enforceUniqueVote before maxVotesAllowed:

} else if poll.enforceUniqueVote == true {
    L10n.Message.Polls.Subtitle.selectOne
} else if let maxVotes = poll.maxVotesAllowed, maxVotes > 0 {

So the same poll reads "Select one" on iOS and "Select one or more" on Android.

Both Android render paths are affected, since they share this helper:

• stream-chat-android-compose/.../ui/components/messages/PollMessageContent.kt
• stream-chat-android-ui-components/.../messages/list/adapter/view/internal/PollView.kt

Tracked in AND-1539, filed by the Stream team after this PR was opened.

Implementation

The subtitle

One added branch in stream-chat-android-ui-common/.../utils/extensions/Poll.kt — check enforceUniqueVote before the maxVotesAllowed branches, so it wins regardless of whether maxVotesAllowed is present:

if (closed) {
    return context.getString(R.string.stream_ui_poll_description_closed)
}
if (enforceUniqueVote) {
    return context.getString(R.string.stream_ui_poll_description_single_answer)
}
val maxVotes = maxVotesAllowed?.let { min(it, options.size) }

The closed short-circuit and the min(maxVotesAllowed, options.size) clamp are unchanged. No public API signature changes (apiCheck passes with no dump needed).

The TalkBack role

PollOptionVotingRow.kt in the Compose kit derived its toggle role from maxVotesAllowed alone, so the same poll that now reads "Select one" was still announced to TalkBack as a checkbox. Raised by @andremion in review; folded in here rather than left for a follow-up, since shipping the subtitle fix alone would leave the visible text and the screen reader disagreeing about the same poll:

val toggleRole = if (poll.enforceUniqueVote || poll.maxVotesAllowed == 1) {
    Role.RadioButton
} else {
    Role.Checkbox
}

The row's KDoc is updated to match. Role is semantics-only, so this changes what TalkBack announces, not what is drawn. The cast/remove gating on the following lines is untouched and still reads maxVotesAllowed through canCastVote().

canCastVote() is deliberately left alone

public fun Poll.canCastVote(): Boolean {
    val limit = maxVotesAllowed ?: return true
    return ownVotes.size < limit
}

I asked whether this needed the same treatment. Answered in review: returning true for an enforceUniqueVote poll with a null maxVotesAllowed is correct, because the server treats a vote on a different option as a vote change.

The reverse case is a real bug, but a separate one. Polls created by the Android SDK carry both maxVotesAllowed = 1 and enforceUniqueVote = true, so canCastVote() returns false once the user holds a vote and a tap on another option is swallowed at PollOptionVotingRow.kt:111 and PollView.kt:308; the user has to deselect first, where iOS lets the switch through. That gates real vote casting across both UI kits and turns on server semantics, so it is out of scope here and left with the Stream team.

🎨 UI Changes

Text-only change on the poll subtitle line, for enforceUniqueVote polls with no maxVotesAllowed:

No visual change beyond that line: the accompanying Compose change affects only the announced TalkBack role.

Existing Paparazzi snapshots are unaffected — PreviewPollData.poll1 sets maxVotesAllowed = 1 alongside enforceUniqueVote = true, so its subtitle is unchanged. :stream-chat-android-compose:verifyPaparazziDebug --tests "*PollMessageContentTest*" passes without re-recording.

Testing

To reproduce: create a poll from the iOS SDK with "Multiple answers" left off (and no per-person vote limit set), then view that poll in either Android UI kit. Before this change the subtitle reads "Select one or more"; after, "Select one".

PollExtensionsTest covers the branch table. Added:

• enforceUniqueVote = true, maxVotesAllowed = null → single-answer string (the bug)
• enforceUniqueVote = true, maxVotesAllowed = 1 → single-answer string (unchanged)
• enforceUniqueVote = false, maxVotesAllowed = null → unlimited-answers string (regression guard: genuinely unlimited polls must not be caught by the new branch)

The pre-existing getSubtitle cases also had to pin enforceUniqueVote = false explicitly. They relied on randomPoll, whose enforceUniqueVote default is randomBoolean(), so once the new branch exists they would flake roughly half the time.

./gradlew :stream-chat-android-ui-common:testDebugUnitTest --tests "*PollExtensionsTest*"   # 10 tests, 0 failures
./gradlew :stream-chat-android-ui-common:spotlessCheck :stream-chat-android-ui-common:detekt :stream-chat-android-ui-common:apiCheck   # BUILD SUCCESSFUL
./gradlew :stream-chat-android-compose:verifyPaparazziDebug --tests "*PollMessageContentTest*"   # BUILD SUCCESSFUL

./gradlew :stream-chat-android-compose:spotlessCheck :stream-chat-android-compose:detekt   # BUILD SUCCESSFUL

The Compose change is not covered by a new test. It is a semantics-only role flip with no assertion on Role in the existing suites, and adding the harness for one felt disproportionate; happy to add one if you would rather have it pinned.

I ran module-scoped tasks only, not the full ./gradlew check or the instrumented/E2E suites.

☑️Contributor Checklist

General

• I have signed the Stream CLA (required)
• Assigned a person / code owner group (required)
• PR targets the develop branch
• PR is linked to the GitHub issue it resolves (AND-1539)

Code & documentation

• New code is covered by unit tests
• Comparison screenshots added for visual changes — text-only, described in the table above
• Affected documentation updated (KDocs, docusaurus, tutorial) — the existing KDoc still describes the behaviour accurately

Summary by CodeRabbit

• Bug Fixes
  • Poll subtitles now accurately describe single-answer voting when unique voting is enforced.
  • Poll subtitles continue to reflect multiple-answer and unlimited-answer settings correctly.