Skip to content

Refactoring and simplification of spam-related services [RUN ALL RSPEC] [RUN AS-IF-FOSS]

Chad Woolley requested to merge caw-refactor-spam-services-apis into master

What does this MR do?

Overview

Details of refactoring and simplification of spam-related services:

  • Decouple spam-related services to remove dependency on request, use SpamParams parameter object instead
  • Expand SpamParams fields to replace existing direct usages of request
  • Pass SpamParams through services exclusively via constructor arg (required for creation, optional for updates)
  • Hardcode SpamLog via_api to true, it should be deprecated and removed (everything is via API now)
  • Make necessary changes to issue/issueable services constructor calls to accommodate addition of spam_params named argument as last argument.

Note on service constructor signatures and named arguments:

This MR is big! Can it be broken up?

That is the nature of these MRs which are modifying the constructor signatures which involve multiple services and many calls to them. It touches many areas of code, but it's all cohesive and makes sense to do together. See !59182 (merged) for a more in-depth discussion of this topic.

The one part which COULD be pulled out is the removal spam checking from issue create/update via boards (see bullet above). However, that is only a few lines and would not contribute much to reducing the overall size of the MR. If there are strong reviewer/maintainer feelings that this should be pulled out to a separate MR, I can do it, but for now I want to get the review process started.

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

See the testing section of the CAPTCHA epic for detailed instructions on how to test spam/CAPTCHA in a dev environment.

Edited by Chad Woolley

Merge request reports