I’ve heard from multiple customers who were puzzled by how the system user was quietly taking action on certain posts and users. What’s usually happening here is that our friendly anti-spam measures are simply taking out the
But to anyone unbeknownst to this, automated deletions look scary because there’s really nothing to indicate that this is intended behaviour. We can do a better job of clueing the user in to what’s happening by briefly explaining why@system took action by putting a reason into the Context column.
Definitely agree, while looking at system actions, can someone look into why sometimes block user action doesn’t reference a user, plus it has no context.
Er what? System never deletes users. These users self-deleted, most likely. Users can delete their own accounts when it is less than a few days old and 1 post or less.
I agree that block could include some comments as to why the block.
Except our logs show context for deleted users… I didn’t find any without context. The last example seems to be the user self-deleting themselves (just proved it is with my test environment).
Those are not actual users – they are people who signed up and never validated their email. So they don’t really exist yet. Like if obama@whitehouse.gov signed up.
Yeah, that is very tomato/tomatoe, but the log indicates a delete user by system in those cases. I’ve yet to see a log that needs context around delete user and system though.
delete post on the other hand… that occasionally has no context (the context is nice because it tells you the topic it is associated to, show doesn’t tell you the topic id/url so finding it requires manual work), and block user occasionally doesn’t reference the user it blocked.
We did not have any “human” staff member block these users. These were all users who were caught in the approval queue for one reason or another. To say blocked_by_staff would imply to me that a staff member clicked the block button…
Things found at queued-posts are only there because they were entered/submitted within 3 seconds (default setting); meaning they copied and pasted the content (most likely).
Akismet (if you have that plugin), items are because they failed the Akismet screening.
When I reject a silenced post in the approval queue, shouldn’t this also be logged?
I suppose the reason why it’s currently not being done is that technically, the user has been silenced by the system user and I am merely not unsilencing him/her. But I think from a human perspective, this confirmation is a significant act that should be logged.
Not sure if it’s necessary to create a new type of action for this (confirm_silence_user) or whether it suffices to just re-log the silencing act but this time under my user name.
