@Heliosurge This idea I found very interesting. From what I’ve read about the plugin there are some things that are already done.In my case, to solve my core problem, I would have to have something like:
| Script name | Plugin | Description |
|---|---|---|
| Locking Trust Levels | automation |
If a user posts too much, includes too many and/or inappropriate images, abuses the flag system, or similar an alternate to the above is locking the user to trust level 0. This will limit the number (and frequency) of topics and posts the user can create, as well as prevent them from including too many images/links and prevent the user from casting flags. Trust levels can be configured from the user’s Admin page. |
| Silenced the user | automation |
Silenced users are prevented from creating new topics, posts, flags, or PMs on the site. They are still able to complete other actions, like “liking” posts, reading topics, replying to PMs, etc. Additionally, they can communicate with moderators via PM, so you can continue to communicate with them to try and address the behavior. |
| Suspended the user | automation |
Suspended users are prevented from logging in, and thus from completing any actions on the forums. A suspension is the strongest possible recourse you have for a user and should be used sparingly. Like silencing, suspending a user is done from the user’s Admin page. Like silencing, suspensions are for a specific period of time. You may want to suspend the user for a short period of time first, and if the user returns and continues the behavior, increase the suspension time. |
| Trust level freeze | trigger-automation |
In case of muted or suspended users the Locking Trust Levels trigger is triggered. |
how the trust levels freeze trigger works
- Trust level freeze - trigger these events automatically:
- Silenced the user - Warning
- Suspended the user - strike 1
- Locking trust level - strike 2
final solution
- In short it would be 4 plugins. Only the last plugin calls the other plugins, as seen in the following topic: how the trust levels freeze trigger works.
- Despite the cases of users being muted or suspended, the examples I mentioned above were done like Spam, Account Security at Risk, Abusive Messages or Behavior, Reporting - when users request that their trust level be blocked. There would still be the case of users who were silenced or suspended on a personal basis, that is, self-report:
- “I request that the trust level be locked as I don’t want to be the leader of something”.
- “I’m traveling and I would like to block my trust level, I don’t know if they will be able to hack my account in this period”.
- “I think my account has been hacked, I would like my trust level to be frozen until the case is investigated by the Discourse community”.
- Note: This users who self-reported their account - they can request account suspension, account muting or even in the case I mentioned the blocked trust level.
- If the user presents any proof that they should not be suspended, silenced or have their trust level protected, the account is normal.
Notes
- I did it a few times and thanks for the feedback, JammyDodger ;D I read this document and I think it’s pretty cool: https://meta.discourse.org/t/discourse-moderation-guide
- Dan DeMontmorency - What do you think of this idea, is it a good idea? Is it possible to create something like this?
new ideas
- A viable alternative may be this, this could be done with suspend-a-user-via-the-api ,
silence-user-via-api, add-a-user-to-a-group-via-api, discourse-docs-api-org, auto-suspend-inactive-user, discourse_api_pull_121 - the only problem is that I still haven’t seen any information from the api about locking trust level. - We may have plugins that communicate with api for this: silence-user-via-api, auto-suspend-inactive-user, “locking trust level”, suspend-a-user-via-the-api.
- My idea would be to have the trust security plugin - this plugin communicates with the following apis: silence-user-via-api, auto-suspend-inactive-user, “locking trust level”, suspend-a-user-via-the-api.
- My initial suggestion that it would be really cool to have these endpoints:
${this.url}admin/users/${userId}/groups/report/spam${this.url}admin/users/${userId}/groups/report/lockingtrustlevel${this.url}admin/users/${userId}/groups/report/accountsecurityatrisk${this.url}admin/users/${userId}/groups/report/abusivemessagesorbehavior${this.url}admin/users/${userId}/groups/userwishthis/lockingtrustlevel${this.url}admin/users/${userId}/groups/userwishthis/accountsecurityatrisk${this.url}/admin/users/:user_id/report/spam${this.url}/admin/users/:user_id/report/lockingtrustlevel${this.url}/admin/users/:user_id/report/accountsecurityatrisk${this.url}/admin/users/:user_id/report/abusivemessagesorbehavior${this.url}/admin/users/:user_id/userwishthis/accountsecurityatrisk${this.url}/admin/users/:user_id/userwishthis/lockingtrustlevel
but something that already solves would be to do this poc - proof of concept
${this.url}/admin/users/:user_id/silence${this.url}/admin/users/:user_id/lockingtrustlevel${this.url}admin/users/${userId}/groups/silence${this.url}admin/users/${userId}/groups/lockingtrustlevel