Automation Advice - Catching Content.BeforeUpdate after Abuse Appeal rules not-abusive

Question

Looking for some advice on creating a custom automation that catches certain unwanted characters/phrases and sets the user as moderated. Currently, I'm writing it using Content.BeforeCreate and Content.BeforeUpdate (to catch sneaky users who edit their posts in the edit window) scoped to content that is reviewable (Blog posts, forum threads and replies, comments, etc..). 
 It works on catching the content without any issue and setting the user's moderated status so that their post enters moderation (and any future post) for review. However, it is also catching the same content post-approval (I assume in the BeforeUpdate portion of the same trigger) and putting the same user back into moderation but allowing the content to be posted as approved. 
 I'm looking for suggestions on the best place to catch the after approval instance to swerve the rest of the content processing including affecting the same user. It seems a bit silly to add the afterapproval trigger so that the same automation always runs on every approval (even on content that wasn't caught by this automation) but if that's the best place, I can go that route (I think).

Former Member · Answer

Have you investigated the "Forbidden Word Counts" automated abuse plugin included with Community? (Administration > Moderation > Abuse Automation > Forbidden Word Counts) This may cover a lot of the functionality you're looking for here. 
 Otherwise, you can look at adding additional checks in the BeforeUpdate logic, for instance to check if the content is being changed from not approved to approved, and prevent putting the user back in moderation in that case.

Former Member · Answer

The common design pattern when checking for changes to an entity is to handle the BeforeUpdate event, and in that event retrieve the item from the API using its id, etc. Then you can compare the values provided in the BeforeUpdate event arguments (the "new" values that have yet to be applied) to the values from the API (the "old" values). For instance, you could compare the IsEnabled flag to see if the content is changing from not enabled to enabled. 
 A few notes: 
 
 I'm not sure how you are using the term, but ReviewableContent refers to a specific Review Workflow process implemented only on specific content types, which is a different use case than abuse checking. 
 I'd still recommend you take a look at the example IAbuseDetector plugin type , as this plugin type (and its controller) exposes methods for interacting directly with the Moderation Queue. You can handle events in this plugin like in an automation.