Context
While scoping PR #1272 (Issue 1238 — poll finalize bypasses RSVP capacity), plus-one handling was pulled out as a separate, lower-priority concern.
Polls carry no +1 concept — a voter doesn't express a +1 when casting their vote. _seat_voter in backend/community/_poll_finalize.py currently seats a winning voter using whatever has_plus_one value already exists on their standing EventRSVP row, if one exists:
# Polls carry no +1 concept; only an existing row's standing +1 survives.
has_plus_one = existing is not None and existing.has_plus_one
This is an edge case (a voter who already had an RSVP with a +1 before the poll ran) rather than the common path, but the intended behavior hasn't been decided — should their standing +1 carry through to a seat won by poll, should it be dropped, or should something else happen?
What needs to happen
Decide and implement the intended behavior for a poll voter who has an existing RSVP with has_plus_one=True at the time the poll they voted in is finalized.
Acceptance criteria
Context
While scoping PR #1272 (Issue 1238 — poll finalize bypasses RSVP capacity), plus-one handling was pulled out as a separate, lower-priority concern.
Polls carry no +1 concept — a voter doesn't express a +1 when casting their vote.
_seat_voterinbackend/community/_poll_finalize.pycurrently seats a winning voter using whateverhas_plus_onevalue already exists on their standingEventRSVProw, if one exists:This is an edge case (a voter who already had an RSVP with a +1 before the poll ran) rather than the common path, but the intended behavior hasn't been decided — should their standing +1 carry through to a seat won by poll, should it be dropped, or should something else happen?
What needs to happen
Decide and implement the intended behavior for a poll voter who has an existing RSVP with
has_plus_one=Trueat the time the poll they voted in is finalized.Acceptance criteria