askvortsov / flarum-auto-moderator
Powerful automation engine.
Installs: 11 432
Dependents: 2
Suggesters: 1
Security: 0
Stars: 10
Watchers: 3
Forks: 4
Open Issues: 5
Type:flarum-extension
Requires
- flarum/core: ^1.0.0
Requires (Dev)
- askvortsov/flarum-moderator-warnings: *@dev
- flarum/likes: *@dev
- flarum/suspend: *@dev
- flarum/testing: *@dev
- fof/best-answer: *@dev
This package is auto-updated.
Last update: 2024-05-01 19:18:02 UTC
README
A Flarum extension.
Core Concept
The idea is simple: When X, if Y, do Z.
Let's define some key terms:
- Trigger: A set of events (usually just one) that can trigger an automation. For example, "Posted", "LoggedIn", "Post liked".
- Metric: A numerical quantity. For example, post count or number of likes received.
- Requirement: An abstract boolean condition. For example, not being suspended, having an email that matches some regex, etc.
- Action: Some side effect / mutation to perform. This could include anything from adding/removing a group to sending an email to suspending a user.
Code-wise, these are represented by "Drivers", implementing one of TriggerDriverInterface
, MetricDriverInterface
, etc.
Requirement and Action drivers take a list of "settings", which they specify validation rules for. This means you can build a UserEmailMatchesRegex : RequirementDriverInterface
, or a AddUserToGroup : ActionDriverInterface
, and then create multiple instances of the drivers with any regex or group ID.
All these are tied together by Rules. Rules are stored as [A DATABASE TABLE OR A SETTING, IDK], and specify:
- A trigger for when the rule should run
- A list of metrics "instances". Each instance includes:
- which metric driver is used
- a numerical range (could also be a one-sided min or max range). If the value computed by the metric driver falls in this range, the metric is satisfied. E.g. "between 10 and 100" likes received
- a "negation" Boolean. If true, the metric will be satisfied if the value computed by the metric driver falls outside of the range
- A list of requirement "instances". Each instance includes:
- which requirement driver is being used.
- A value for the requirement driver's config. It will be plugged into the requirement driver to compute whether the requirement is satisfied. E.g. a users email needs to end with "flarum.org"
- A "negation" Boolean. As with metrics, this allows inverting the requirement driver's output
- a list of actions instances. Each includes:
- which action driver is used
- a "settings" value, that will be plugged into an action driver to run the action (e.g. which group to remove a user from)
Trigger drivers specify a list of "subject models", e.g. the author and post in a post created event. These determine which metrics, requirements, and actions are available when defining a rule for some trigger, since "running" a metric, requirement, or action always requires some subject (e.g. which user are we calculating num likes received for, which post are we auto-flagging, etc)
Whenever any event that has rules attached via triggers runs, we "evaluate" all valid rules, and if all the rule's metrics and requirements are satisfied, the rule's actions will run.
A rule is invalid if (1) it has requirements or actions where settings don't pass validation, (2) any of it's components depend on an extension that isn't currently enabled, or (3) any of it's components reference drivers that don't currently exist.
This makes for an extremely powerful extension. Since extensions can add their own metrics, requirements, and actions, this extension can automate away a lot of moderation. Beyond the examples listed below, some things that could be possible are:
- Automating assignment of achievements / badges
- Sending emails/notifications to users when they reach thresholds (or just when they register)
- Establishing a system of "trust levels" like Discourse
- Onboard/offboard users to/from external systems when they receive/lose certain group membership
- auto-flagging posts that fail some test
Testability
Because this system is so generic, we can separate testing the framework for (validating, evaluating, running) rules, from each of the drivers.
Testing drivers is super easy, which makes it cheap and easy to add any drivers we want. See this extension's test suite for examples.
TODO:
- Implement the frontend for creating, viewing, and editing rules. Maybe there could be a feature to import a
Rule
as JSON, so that rules could be easily shared between forums?- We could allow registering form components / config for the settings of certain drivers, so that e.g. "AddUserToGroup" actions could be configured with a real group selector, not just a number field.
- I've already implemented a metric range selector component.
- Add a ton more drivers.
- Actions e.g. send emails, flag posts, create warmings
- metrics e.g. posts read, time spent, days visited, days since account creation
- requirements e.g. "user has bio", "post matches regex", etc
- more tests for rule evaluation and validation
- add support for "dated" metrics, e.g. "num discussions created in the past X days"
- cache / store calculated metric values for use by other extensions
- making metric values available to action implementations
Already Implemented
- interfaces for the various drivers
- a bunch of instances of each driver
- tests for each instance
- an extender for adding new drivers
- A
Rule
class, including the core validation and evaluation logic for rules- And some tests for this, although more would be nice!
Metrics vs Requirements
Any metric driver could be implemented as a requirement driver, since requirements are more powerful. But if your requirements are about numerical conditions, metric drivers are better because:
- it's easy to specify a range of numbers that is valid
- the output of the metric driver contains the actual value, and so could be used for other features, e.g. calculating a "reputation" score per-user
EVERYTHING BELOW THIS LINE IS OUTDATED
Examples
Example 1: Group Management
Criteria: Users that receive 50 or more likes and have started at least 10 discussions should placed in the "Active" group.
Here, the metrics are "received 50 or more likes" and "have started at least 10 discussions". Unsurprisingly, they come with the triggers (PostWasLiked
, PostWasUnliked
) and (Discussion\Started
) respectively.
The actions are:
- When the criteria is met, add the user to the "Active" group
- When the criteria is lost, remove the user from the "Active" group
Example 2: Suspension
Criteria: If a user gets 15 warnings or more and is not an admin, suspend them.
Here, the metrics are "gets 15 warnings or more" and the requirements are "is not an admin". The triggers would be a new warning for the metric. The requirement has no triggers.
The actions are:
- When the criteria is met, suspend them
- When the criteria is lost, unsuspend them
Example 3: Auto Activation
Criteria: If a user's email matches a regex, activate their email.
The requirement is "a user's email matches a regex". The triggers are saving a user.
The actions are:
- When the criteria is met, auto activate the user's email
- When the criteria are not met, don't
Example 4: Default Group
Criteria: Add a user to a group
There are no metrics or requirements, so this will be applied to all users on login.
The actions are:
- Add all users to a group on login
Screenshots
Extensibility
This extension is extremely flexible. It can be considered a framework for automoderation actions.
Extensions can use the Askvortsov\AutoModerator\Extend\AutoModerator
extender to add:
- Action drivers
- Metric drivers
- Requirement drivers
You should look at the source code of the default drivers for examples. They're fairly exhaustive of what's offered.
If your extension adds action or requirement drivers that consume settings, you have 2 options:
- Provide translation keys for the settings you need in the driver's
availableSettings
method. This is very easy, but also very restrictive. You can only use strings, and can't add any restrictions or UI. - You can declare a settings form component for your driver. See
js/src/admin/components/SuspendSelector
for an example. The component should take a settings stream asthis.attrs.settings
. The contents of the stream should be an object that maps setting keys to values. The component is responsible for updating the stream on input. You can register a form component by adding its class toapp.autoModeratorForms[DRIVER CATEGORY][TYPE]
, whereDRIVER CATEGORY
is"action"
or"requirement"
, andTYPE
is the type string you registered your driver with inextend.php
. Seejs/src/admin/index.js
for the underlying data structure and examples.
Contributions
Contributions and PRs are welcome! Any PRs adding new drivers should come with unit tests (like with all existing drivers).
Compatibility
Compatible starting with Flarum 1.0.
Installation
composer require askvortsov/flarum-automod:*
Updating
composer update askvortsov/flarum-automod