Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Better Moderation Tools #485

Open
1 of 8 tasks
Zren opened this issue Dec 5, 2014 · 3 comments
Open
1 of 8 tasks

Better Moderation Tools #485

Zren opened this issue Dec 5, 2014 · 3 comments
Labels
CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. DB Pertains inclusively to the Database operations. enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. feature Something we don't already have implemented to the best of knowledge but would like to see. security Usually relates to something critical. team biz This is similar to a meta discussion. UI Pertains inclusively to the User Interface.
Milestone
#485

Comments

@Zren
Copy link
Contributor

Zren commented Dec 5, 2014 •
edited by Martii
Loading

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:

  • 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
Copy link
Member

Martii commented Dec 6, 2014

See also

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.

  • 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.

@Martii Martii added UI Pertains inclusively to the User Interface. CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. DB Pertains inclusively to the Database operations. enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. feature Something we don't already have implemented to the best of knowledge but would like to see. security Usually relates to something critical. labels Dec 6, 2014
@Martii Martii added this to the #485 milestone Dec 6, 2014
@jerone
Copy link
Contributor

jerone commented Dec 6, 2014

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 pushed a commit to Martii/OpenUserJS.org that referenced this issue Aug 4, 2015
Patch for searching remover and reason in graveyard
32a27af 
* Unable to find documentation on the wildcard at this time but appears that it doesn't work... closest match is an issue on *mongoose* at 3213 ... nothing I've tried works there with `{ type : Object, index : true }` or other type ... this probably isn't the final solution and another QSP would be useful to limit scope and perhaps another of exclusion of scope... but these are all encompassing searches for now.
* Those stray commas again
* Change casing on `WATCHPOINT` back to `NOTE: Watchpoint` for grep'ability

Applies to post fix OpenUserJS#696, patch for OpenUserJS#490, and solution needed in OpenUserJS#485
This was referenced Aug 4, 2015
Merged
Closed
@Martii Martii added the team biz This is similar to a meta discussion. label Oct 7, 2015
Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Oct 15, 2015
Show who flagged what in the UI
7cf7602 
* Base working concept
* Eventual showing of the reason in respective views... currently set to a horizontal ellipsis if absent... see additional notes below

Applies to OpenUserJS#643 and OpenUserJS#641

NOTES:
* Test with QSP `?flagged=true` for lists and Admin or better privileges on script homepage and user homepage with logged in and logged out... there are at least 6 routes *(4 with QSP and 2 without but all elevated to Admin+)* needed to test against
* If for some reason some user is flagged but there aren't any actual flags it will show up as no user and no reason e.g. Flagged column will be empty for those mustache opts
* Using series in some of the *async* related calls to hopefully ensure natural ordered flags
* **NOT COMPACTED** for clarity as well as for strict *async* usage
* One bug fix in a view with colspan
* One restoration in `.../modelParser.js`
* Some class changes in a view

TODO: *(mitigation)*
* Needs reason attached to flagging route ... separate issue to be created and milestoned near OpenUserJS#485 and OpenUserJS#262 and similarly done in OpenUserJS#513
@Martii
Copy link
Member

Martii commented Feb 6, 2019 •
edited
Loading

  • 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 👎 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 👎 No thanks.

Martii added a commit to Martii/OpenUserJS.org that referenced this issue Sep 4, 2020
@Martii
Add "Since" column to Users
99a50e3 
* Change some UI centering.
* If new columns for `created` and/or `updated` are wanted please open a new issue with relativity.
* Since queries can be CPU intensive continue to limit some of these in the UI.
* MongoDB 4.x has the ability to auto-create these per save/creation however finite control is usually needed rather than all the time/everywhere.

Applies to OpenUserJS#485 and closes OpenUserJS#349
@Martii Martii mentioned this issue Sep 4, 2020
Merged
Martii added a commit that referenced this issue Sep 4, 2020
@Martii
Add "Since" column to Users (#1749)
491699c 
* Change some UI centering.
* If new columns for `created` and/or `updated` are wanted please open a new issue with relativity.
* Since queries can be CPU intensive continue to limit some of these in the UI.
* MongoDB 4.x has the ability to auto-create these per save/creation however finite control is usually needed rather than all the time/everywhere.

Applies to #485 and closes #349

Auto-merge
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. DB Pertains inclusively to the Database operations. enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. feature Something we don't already have implemented to the best of knowledge but would like to see. security Usually relates to something critical. team biz This is similar to a meta discussion. UI Pertains inclusively to the User Interface.
Milestone
#485
Development

No branches or pull requests
3 participants
@jerone @Martii @Zren