Conversation
The email-list option in the election wizard told admins:
'BetterVoting will create private voting links and send them by email once
the election starts'
BetterVoting does not send them. Nothing goes out automatically -- not on
finalize, not on opening. finalizeElectionController changes state, defaults
max_rankings and deletes draft ballots; it contains no email call. There is no
cron, node-schedule or interval anywhere in packages/backend/src, so nothing
could fire 'once the election starts' either. The only send paths are the
admin-invoked sendInvites / sendEmail routes.
An admin who believes the wizard finalizes, waits for the start time, and runs
the entire voting window without a single voter being told. Nothing warns them:
there is no error, and the Voters tab looks exactly as expected throughout.
Changes the string to describe what actually happens, keeping the parallel
shape of the neighbouring id_list_description ('Provide X. <what happens>'):
'Provide voter emails. BetterVoting creates a private voting link for each
voter, ready for you to send from the Voters tab'
en.yaml only -- es, pl and pt-BR do not define this key and fall back to
English, so no translation is left promising the old behaviour. The string is
consumed in two places (the wizard step, and the security-option card via
(wizard.email_list_description)) and reads correctly in both.
This is option 1 from Equal-Vote#1558, the smallest change that makes the product honest.
That issue also raises two larger alternatives -- sending on finalize, or
prompting to send as part of the finalize flow -- which are worth considering
separately; this does not preclude either.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
✅ Deploy Preview for bettervoting ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Review limit reached
Next review available in: 13 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Description
Fixes #1558 — option 1, the smallest change that makes the product honest.
The email-list option in the election wizard currently tells admins:
It doesn't. Nothing is sent automatically — not on finalize, not on opening.
Changed to describe what actually happens, keeping the parallel shape of the neighbouring
id_list_description("Provide X. <what happens>"):Why this matters more than a wording nit
An admin who believes the wizard finalizes, waits for the start time, and runs the entire voting window without a single voter being told. Nothing warns them — there's no error, and the Voters tab shows the roll exactly as expected throughout. The failure is only visible once the election is over.
Verified against source
finalizeElectionController.tschanges state, defaultsmax_rankings, deletes draft ballots. No email call.node-scheduleor interval anywhere underpackages/backend/src— so nothing could fire "once the election starts" either.sendInvitesController.ts/sendEmailController.ts, both admin-invoked.Scope
en.yamlonly.es,plandpt-BRdon't define this key and fall back to English, so no translation is left promising the old behaviour.The string is consumed in two places — the wizard's voter-access step, and the security-option card via
$t(wizard.email_list_description)— and reads correctly in both. YAML validated.Notes for the reviewer
Not fixed here, deliberately: the card renders as
…from the Voters tab Recommended to maximize security.— no separator, because the string has no trailing period and$t()concatenates directly. That run-on exists today with the old copy, and identically on the siblingid_list_descriptioncard. It's a pre-existing formatting quirk affecting both cards, so it seemed better as its own small change than smuggled into a copy fix. Happy to include it if you'd prefer.#1558 also raises two larger options — sending on finalize, or prompting to send as part of the finalize flow (probably the best UX, since the flow already routes admins to the Voters tab). This change doesn't preclude either; it just stops the UI making a promise nothing keeps in the meantime.
Screenshots / Videos (frontend only)
Text-only i18n change, no layout impact. The string appears in two places during election creation: the voter-access step of the wizard, and the "Email list" security-option card. Happy to add screenshots if useful.
Related Issues
Fixes #1558. Context in #1556 — two help pages had transcribed this copy faithfully and stated invitations are sent automatically; both are now corrected.