Better Moderation Tools

[Zren]

This topic was raised in #469. Since Moderators are currently depending on the data the rating bar provides, alternatives would need to be added before we can remove it.

Idealy something like this:

• [x] Users must enter a reason when flagging a script. Rename the action to "report" since "flag" usually means an on/off switch.
• [ ] Do not automatically hide flagged scripts. This is a tool to allow the community to moderate when the load becomes too large, but it can be abused very easily. Better to let users downvote a script to oblivion and show reports of why a script is bad.
• [ ] Removal should just be a boolean on/off instead of moving it to another document and retaining the old data as a subdocument. This requires most queries to filter by {removedAt: null} but allows moderators to view removed scripts in the same list as non removed scripts.
  • [ ] Requires adding 2-4 new fields to the Script model. Script.removedAt: {type: Date}, Script.removedBy: {type: ObjectId, ref: 'User'}. Maybe Script.removed: {type: Boolean} but it isn't really needed as we can query for removedAt.
• [ ] Removed scripts have the entire row branded with <tr class="danger">.
• [ ] Reported scripts have a <div class="alert alert-danger"> listing all the reported messages, along with a button to do common moderation tasks. This could be visible to moderator and above only, or visible by everyone.

Some of the things in the above section would be nice to do, but is a lot of work for something that would be a pain to get approved since it involves refactoring working code.

Not in screenshot:

• [ ] RSS feed.
• [ ] Emails when a script is reported (would need to be configurable). Hell it would require us to store emails in the User schema which we currently don't. This will probably have a big learning curve.

[Martii]

See also

• #261

Do not automatically hide flagged scripts....

Moderators and above should be able to do this. EDIT: or as it is mentioned in #134

This requires most queries to filter by {removedAt: null} but allows moderators to view removed scripts in the same list as non removed scripts.

That could be nice for moderators and up... but a very strong distinction as you said with the branding in the script lists for us. e.g. when somethings removed I usually don't go back and visit it.

This could be visible to moderator and above only, or visible by everyone.

Messages on why are useful to everyone however flame wars on who did what isn't... moderators should be able to view and admins who did what though for corrections with AuthAs. We currently have an issue with deleted users not having their votes/flags removed and I have no way of telling who did what.

would be a pain to get approved since it involves refactoring working code.

Considering #261 was created by me a while back... it won't be much of an issue. Just make sure they are discrete PRs and documented as fully as you can for understandability. We are all sometimes on different pages working on different issues and it's helpful to have a clear path. I like how you outlined it here with this issue much like Jerone has been doing.

Requires adding 2-4 new fields to the Script model.

• [x] Initial creation date would be nice too... along with Account creation but the latter is probably a different issue.

Since Moderators are currently depending on the data the rating bar provides, alternatives would need to be added before we can remove it.

Vertical centering with your mock up would still not look very appealing from #469 but I'm open very much to improving it. I remove a few scripts per week for violation of the TOS with obfuscation and it would be super nice to be able to moderate better.

[jerone]

It should state (in the title) that this is only about scripts moderation. Script issues and forum discussions is not (yet) discussed here and should probably discussed in another issue.

I haven't done any real moderation (yet) on OUJS so I have no useful input on this issue. The proposed enhancements all sound useful and probably lower the barrier for me to do some moderation.

Code-wise, I do wonder if there is a performance penalty in using { removedAt: null } or { removed: { $ne: true }} for database queries...

[Martii]

• Removal should just be a boolean on/off instead of moving it to another document and retaining the old data as a subdocument.

Now that I've had some quality time with MongoDB directly ... this is at :-1: due to the nature of memory storage and execution. We have a lot of scripts removed for a lot of valid reasons. While it would still be nice to "restore" something usually something that is removed is a permanent state and only certain Admin+ can undo that.

• Removed scripts have the entire row branded

Security issue... DDoS :-1: No thanks.