System admin actions should include reason

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 :garbage:

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.

We’d go from this:

To this:

(Ignore the example reasons; I’m not 100% clear on what ultimately sets off a Delete action)

If keeping a record of the various anti-spam reasons sounds too cumbersome, even just putting “Reason: Spam” would be a big step forward.


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.

(user removed from screenshot in first column so I could post it)

and another example:

Also for delete post, it would be nice if it followed the context the other delete posts have (the URL to the post)


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.


That is mostly true.

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 signed up.

1 Like

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.

@sam does the fast new user typist block enter something reasonable in the logs when it triggers? Can you confirm this please?

Not really, I guess the way you can tell it triggered is that it was queued, I guess we could query the post queued table for a “log” of sorts.

Just scrolled through the Stonehearth logs to see what System actions don’t have context and need it. I could only find one example:

In this case, it appears that the user deleted themselves (next log), but the context isn’t particularly clear:

While scrolling through, I also noticed that the context for block user is misleading, arguably incorrect:

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…


Can we improve this log message @sam to include more detail?

I think so, we could give a special bit of text here. added to my list unless someone beats me to it.

1 Like

Added more information for auto blocking per:


Hi Guys, good afternoon!

I wanted to know if there is any chance that the admins can see the reasons why a topic / interaction, falls into “spam”.

We usually select this from the menu and we can give OK or not. But we never have the clear reasons.

That information appears on Flags ( but doesn´t appear on “Requires Aprobation” (

Thank you por any help!

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.

The post rejections are now logged via