logSpamTrigger does not match getFinalDecision, resulting in the wrong action type being logged

[Xon]

Affected version

2.2.15

The XF\Spam\AbstractChecker::logSpamTrigger computes a single discussion which doesn't match how XF\Spam\AbstractChecker::getFinalDecision implements it.

This can result in the spam log entry having the wrong spam trigger action. ie moderated vs denied.

Additionally logSpamTrigger skips logging on "accept" but, this doesn't match the API usage which can result in dropped logs.

Finally, it looks like logSpamTrigger will update the existing log entry (ie post gets edited and forced back into the approval queue) rather than generating a new log entry. For a log design that is deeply unexpected.

 

[Xon]

Except for the spam trigger log admin page, nothing reads from this table (well beyond pruning code). So removing the unique constraint and making logSpamTrigger append without overwriting and using getFinalDecision should be backwards compatible.

 

[Xon]

A major problem is how getFinalDecision is used, is a number of hard-coded switch statements use it, which makes implementing say "accept & report" (instead of moderate or deny) very hard to implement.