Tracing through html/inc/forum_banishment_vote.inc and its two callers (forum_banishment_vote.php, forum_banishment_vote_action.php), I want to check whether this is the intended design or an incomplete implementation:
- Starting a vote (
start_vote()) immediately suspends the accused user for exactly 6 hours (banished_until = time() + 21600), before a single vote is cast. That same 6-hour window is also the vote's own deadline (vote_is_in_progress() checks end_time > now).
- The notification email tells the accused they'll be banned for 14 days if the vote succeeds (
send_banish_vote_email() is called with 86400*14 as the duration), but I can't find anywhere that this 14-day figure — or the vote's tally at all — is ever actually applied. vote_yes()/vote_no() just record a row and re-print the current tally; nothing checks for a majority, nothing extends banished_until based on the result, and I couldn't find any cron task or other code path that revisits a vote after its 6-hour window closes.
So as far as I can tell, the practical effect of a banishment vote is entirely the automatic 6-hour suspension that fires the moment it's started — the vote itself (and the 14-day figure promised in the email) appears to be advisory only, with no automated follow-through. A moderator would have to separately notice the outcome and use the unrelated direct "Banish author" tool if they want an actual longer ban.
Confirmed present on current master. Is this the intended behavior (vote as a soft signal + built-in cooldown, real enforcement left to human judgment), or is there meant to be a mechanism that acts on the tally after the vote closes that's missing/broken? Happy to look into a fix once there's clarity on the intended design.
This report (investigation) was prepared with AI assistance (Claude Sonnet 5). All findings were verified against the actual BOINC source.
Tracing through
html/inc/forum_banishment_vote.incand its two callers (forum_banishment_vote.php,forum_banishment_vote_action.php), I want to check whether this is the intended design or an incomplete implementation:start_vote()) immediately suspends the accused user for exactly 6 hours (banished_until = time() + 21600), before a single vote is cast. That same 6-hour window is also the vote's own deadline (vote_is_in_progress()checksend_time > now).send_banish_vote_email()is called with86400*14as the duration), but I can't find anywhere that this 14-day figure — or the vote's tally at all — is ever actually applied.vote_yes()/vote_no()just record a row and re-print the current tally; nothing checks for a majority, nothing extendsbanished_untilbased on the result, and I couldn't find any cron task or other code path that revisits a vote after its 6-hour window closes.So as far as I can tell, the practical effect of a banishment vote is entirely the automatic 6-hour suspension that fires the moment it's started — the vote itself (and the 14-day figure promised in the email) appears to be advisory only, with no automated follow-through. A moderator would have to separately notice the outcome and use the unrelated direct "Banish author" tool if they want an actual longer ban.
Confirmed present on current
master. Is this the intended behavior (vote as a soft signal + built-in cooldown, real enforcement left to human judgment), or is there meant to be a mechanism that acts on the tally after the vote closes that's missing/broken? Happy to look into a fix once there's clarity on the intended design.This report (investigation) was prepared with AI assistance (Claude Sonnet 5). All findings were verified against the actual BOINC source.