The candidates_update_twitter_usernames script behaved less than ideally
in the case where none of their Twitter details correspond to a real
Twitter account (typically when they delete their account, or we only
have an old screen name that predates a change of screen name): it would
print out a warning, which would be emailed if the script is run from
a cron job. This isn't ideal because we never want to be linking to
non-existent Twitter accounts from the site - the action you'd take on
seeing this warning is always going to be to remove or fix the bad data.
(The old values will still be in the version history, after all.) You
might want to search for a new Twitter account too, but you can still do
that afterwards if the bad data were deleted.
This commit changes the behaviour of the script so this bad Twitter
account data is deleted automatically; it still emits a warning, so those
cases can be investigated (and in some cases new accounts found) by hand
afterwards.
The candidates_update_twitter_usernames script behaved less than ideally in the case where none of their Twitter details correspond to a real Twitter account (typically when they delete their account, or we only have an old screen name that predates a change of screen name): it would print out a warning, which would be emailed if the script is run from a cron job. This isn't ideal because we never want to be linking to non-existent Twitter accounts from the site - the action you'd take on seeing this warning is always going to be to remove or fix the bad data. (The old values will still be in the version history, after all.) You might want to search for a new Twitter account too, but you can still do that afterwards if the bad data were deleted.
This commit changes the behaviour of the script so this bad Twitter account data is deleted automatically; it still emits a warning, so those cases can be investigated (and in some cases new accounts found) by hand afterwards.