Remove spam comments and faulty admin logins from primary activity report

[krogsgard]

The spam comments and faulty admin login attempts overwhelm the activity stream, making the primary report mostly useless to me.

I'd recommend a) the option to not track that info at all, and/or at least b) Remove it from the primary activity report.

In regard to (b), you could simply keep a count in the report div (22 admin login attempts, 245 spam comments today), but not show the activity itself without drilling down further. That would keep more important information (like posts publishing, real comments, real-username login failures, and page changes) more visible, and therefore the default report would be much more valuable.

[lukecarbis]

Hey @krogsgard - have you tried adjusting the Exclude settings? You can find them in Stream > Settings > Exclude.

There's a tick box down the bottom to hide existing entries, too. Does that help?

[krogsgard]

I was apparently looking in the wrong place. I just found Failed Login thanks to your screenshot. Marked as Spam doesn't show up for me though.

Perhaps a legend or (?) indicator or link to docs or something would help people discover what could be useful? Also, perhaps some pre-configured "popular" exclusions could help? Something to help guide users the right direction? I highly doubt I'm the only person that'd want to not see hundreds of spam comments in these reports...

So, in short, perhaps even if we find the answer in exclusions, there are some things worth considering here for default behavior?

[Japh]

Fantastic suggestions, @krogsgard, thanks! We'll be improving our docs over the next little while, and adding references to them as we do. Great idea for us to discuss some potential sensible defaults there too.

👍

[krogsgard]

Weirdly enough, when I went back in to try again, Marked as Spam came up. However, it doesn't appear to actually remove these items from the Stream. You can see my screenshot here (which is a spam comment up top, right after the Activity setting change) https://cloudup.com/cBSj671Af84

[Japh]

@krogsgard If you tick the checkbox, it should then hide previous entries as well. If that doesn't work, please try without the checkbox ticked (see #475).

Also, as you see above, we've opened a ticket for further discussion on your suggestion in #474.

[lukecarbis]

I'm closing this as I believe it's being addressed as multiple separate issues:

• Tracking information with high potential to flood streams #474
• Excluding actions hides previous records even when the checkbox is unticked #475
• Refactoring the UI for improved Connector/Context/Action display #484

[krogsgard]

Hey guys,

I think this is still unaddressed, or lost in the fray of those other tickets.

"Marked as spam" as an action doesn't actually trigger the filter.

You can see here where I changed it to that action and the spam came through anyway: https://cloudup.com/cGK25Shsf8L

I think it's bypassing it bc marking as spam happens earlier. It's not published comment > spam comment. It's just comment entry > spam.

I talked to @Japh about this some via Skype, but I'd love to see this fixed. Right now I have to block out all comments via the connector, but I'd really love to track legit comments.

[shadyvb]

Hey @krogsgard,

I think this is a bit tricky to handle, since as you mentioned the 'Marking as spam' action takes place after actually logging the record.

We have a few scenarios here:
1- A comment is added, and Akismet reports that it is a spam comment.
Solution: We can probably delay logging the comment addition to end of session, so Akismet action is account for. A pretty straight forward approach.

2- A comment is added, passed Akismet validation, a user later marks it as spam.
This should probably be logged properly, as a comment added log, then a user update log. Since this is considered 'an admin action' that should be logged via Stream.

I know some would like user-marked spam comments to still be filtered via 'Marked as spam',
so the obvious solution to such a problem would be to update Stream log with comment status after being spammed or approved by the user. But that is something that we'll probably want to refrain from doing, talking about updating records, because if you start going down that path, lots of inconsistencies will be introduced to logs.

I'll experiment with a solution for the first scenario, which i hope would fix your original problem.