Evaluate possible improvements to BLOCK case handling for spam verdicts.
The following discussion from !52385 (merged) should be addressed:
-
@cablett started a discussion: WDYT about creating an issue for whatever further iterations are planned for this? Otherwise this comment isn't very helpful since everything is already a draft
🙂
Initially, when work started on improving GitLab's spam-handling capabilities, only ALLOW
, DISALLOW
and CONDITIONAL_ALLOW
were handled by spam_action_service.rb
. However, with the introduction of https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/spam/spamcheck and active usage within the product !52385 (merged), there's now a need to process all verdicts. Thus, the BLOCK
case was added. At the moment, BLOCK
behaves exactly as DISALLOW
, however, going forward and as Spamcheck matures, we should add functionality that actually enacts a user block, upon doing so admins can get a notification, etc. This opens the door for more automations that reduce engineering time spent enacting BLOCK
verdicts.
when BLOCK_USER
# TODO: improve BLOCK_USER handling, non-existent until now
target.spam! unless target.allow_possible_spam?
create_spam_log(api)