[ENG-10340] Check for flag#11792
Conversation
341cbde to
26e58cf
Compare
26e58cf to
4c6cf27
Compare
| return False | ||
|
|
||
| text = name_content.lower() | ||
| if any(suffix in text for suffix in ['m.sc.', 'msc.', 'phd.', 'ph.d.', 'msc.pt', 'pt.', 'prof.', 'dr.', 'md.', 'jd.', 'esq.']): |
There was a problem hiding this comment.
This is far too specific and only handles the cases we know of, not the potential future cases. I think we need to adjust the DOMAIN_REGEX to be better (it should grab complete URLs), and also maybe if the domain regex finds something, pass the suspected domain through urllib.parse.urlsplit to see if it has a scheme and a netloc. If it doesn't have both of those, we could probably return false, since it won't link in an email to a location.
sh-andriy
left a comment
There was a problem hiding this comment.
@bodintsov I agree with @brianjgeiger, the suffix list is just going to rot as new name formats show up. The urlsplit idea (only count it if it parses to a scheme + netloc) is the cleaner, future-proof version.
One thing though: even a perfect regex only fixes the trigger, not the disable itself. Accounts still get disabled with SPAM_ACCOUNT_SUSPENSION_ENABLED off because user.confirm_spam() calls deactivate_account() directly (user.py:1485), skipping both the suspension flag and the is_hammy check that suspend_spam_user has. So the save() → confirm_spam() path can still nuke an assumed-ham user. To actually hit the AC (assumed-ham never auto-disabled, manual only, excluded domain → flagged) we need to guard there too, flag instead of confirm_spam for hammy users.
Ticket
https://openscience.atlassian.net/browse/ENG-10340
Purpose
Fix the user's account getting disabled
Changes
Added a check for the frag in the method
Side Effects
TBD
QE Notes
TBD
CE Notes
TBD
Documentation
TBD