summaryrefslogtreecommitdiff
path: root/Mailman/Commands/cmd_set.py
diff options
context:
space:
mode:
authorbwarsaw2002-08-15 17:15:23 +0000
committerbwarsaw2002-08-15 17:15:23 +0000
commit6b662bde2d2729020a3fe495f7469e2eb6a2d175 (patch)
tree07f3e5c937aa03b0be80b240e2140ac16915bdec /Mailman/Commands/cmd_set.py
parenta6da7badfd5a96dafa446e3934c5625c209e357a (diff)
downloadmailman-6b662bde2d2729020a3fe495f7469e2eb6a2d175.tar.gz
mailman-6b662bde2d2729020a3fe495f7469e2eb6a2d175.tar.zst
mailman-6b662bde2d2729020a3fe495f7469e2eb6a2d175.zip
Fix a nasty bug that could cause disabled members to be deleted from
the list too early! This scenario: - a member starts bouncing and gets an initial bounce score, but isn't yet disabled - their mail starts working again for a while - we start getting bounces for them again, but now their old info is stale, so we reset it The bug was that when we reset the info, we actually didn't reset their bounce score, we reset their "notifications-left" value! That means that if they accumulated more bounce scores and got disabled, they'd immediate get removed from the list because they'd have no bounce notifications left! Ouch. The fix is to enshrine the reset semantics in default arguments for _BounceInfo.reset(): default for score is 0, default for date is None (meaning use Day 1), default for notices left is None, is basically a placeholder. registerBounce(): If we're going to reset stale bounce info, use the defaults, except for noticesleft, which gets its value from bounce_you_are_disabled_warnings. Thanks to Danny Terweij for being the guinea pig. ;)
Diffstat (limited to 'Mailman/Commands/cmd_set.py')
0 files changed, 0 insertions, 0 deletions