Admin Feature: Show which users have flagged something #643
Comments
sizzlemctwizzle
added
enhancement
sizzlemctwizzle
added
feature
|
Continuation of discussion #640 (relevant: #641). I choose to reply here as it is more relevant. May I suggest force them to provide a flag feedback comment and with a warning on abuse. Abuse can result in the removal of flagging ability or on extreme cases, removal of user (though I think it is very harsh option). If people must provide a reason, it will cause less abuse and less flagging. Also waiting until script has positive flag count is risking it, and relying on admin to catch those that fall through the crack is way too much considering the amount of scripts. So an open forum that allows users to monitor open flagged feedback. When the flag thread is open are able to access it and even provide input. If the scripts flag thread is open, and a new user tries to flag the script he will be pointed to the open thread and will be asked to add his issue at the end. If it is an flagged erroneously or is resolved, the admin deflags the thread and the post is then hidden from non-admin. If another flag is raised after that, a new flag thread is created for the script. |
|
As I've stated to you directly before TimidScript we don't need a flame war. Flagging will eventually have a reason once #262 gets the |
|
I agree with @Martii. Issues exist for discussion on how to resolve problems with a script (and request features and whatnot). Flags are to report malicious activity, which really needs no discussion on the part of ordinary users. You will be asked to give a reason while flagging once that feature is finally implemented.
Honestly the case of a very popular script suddenly turning malicious is a rare edge case. Admins using #641 would catch these exceptions with ease. |
|
Isolating this to just the admins is nice... but there was a comment somewhere about letting individual flaggers see what they have flagged in case they change their mind e.g. my thoughts are showing the list/link on each user accounts homepage to the owners and also make it available to admins+... a separate listing of each script is what is being mentioned here but I think the root'ing should be on each user (homepage) first. |
* 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
* Standardize on `flagList` since `flagged` is already in use * Some compaction of the code ... backed out a few changes in prior commit... added a master asynchronous function to the flag library * One bug fix with `modelParser` to acccomodate prior commit reversion **NOTES**: * This should be functionally equivalent to the last commit feature wise and a lot easier to maintain. An example of this is the dynamic field name change in this commit... easily changeable in case someone doesn't like that name but should be okay for now. Applies to OpenUserJS#643 and indirectly OpenUserJS#641
* Created `flag.js` controller as per sizzle and moved the export there * Created `vote.js` controller base * Move/remove last commit stuff out that was added in. * Renamed `setFlaggedListInModel` to `setFlaggedListToModel` ... this still could use some advice on exact name that is wanted for the identifier. * NOTE'd a possible extra dir traversal that shouldn't be needed as compared to below requires... this is beyond this PR and will retest/cleanup in another unrelated commit so just noting it Applies to OpenUserJS#643
* Using this to be more consistent with other contributors and upon the advice of Lord Sizzle! :) Applies to OpenUserJS#643
* As described earlier placeholder so anyone knows where to start to put things without a search NOTE: Specific to OpenUserJS#770 (comment) Applies indirectly to OpenUserJS#643
* This is somewhat flexible when needed but will assist in directing contributions. This is mostly the current pattern. * During a cleanup phase will probably match this general code styling in the other controllers Applies indirectly to OpenUserJS#643
|
So now that the Admins and up can view this on production... any final UI styling changes before closing? (make sure you clear your cache for the CSS change if you left your browser open already to production) Reasons will be added after #641 is determined... so please go visit there too. |
|
Just a misc note for current Moderators... on the script home page to tell if a script is critically flagged look at the rating bar and if it's all red with no grey then it's critically flagged... and of course it will show up in the Moderator tools. |
|
Only thing I can possibly think of at this time is to add the current "role" to the User button tooltip but that's not as important so closing as fixed... #641 will enable a more finite list when completed but this structure. Opening new issue for "reason". |
|
Whoops have one view bug of not maintaining the library QSP... fixing momentarily. |
* Add the QSP if checking on flagged libraries Re closes OpenUserJS#643
Post fix for #643 with library views Auto-merge
* User script lists by default still show both Userscripts and Libraries as designed * The overall flow of the project has been to separate Userscripts from Libraries unless on a Users home page... putting this a little clearer will help other understand... also won't hurt our SEO rating and will help clarify when people try to upload a library script instead of Userscript. * Groups only handle Userscripts so denote that in the tooltip * This is breaking from USO tradition but I think it's time to give that some rest Needed for maintaining the logic of QSP's *(some hidden)* with OpenUserJS#643 and loosely OpenUserJS#547 and post OpenUserJS#383, OpenUserJS#372, OpenUserJS#254 and probably more
* Turns `library` into a tri-state, but only on User Script List pages * Missed a few labels too in OpenUserJS#777 * Commented it as much as I can for clarity for those not familiar with multi-state QSP's * Kept the view duplicated for clarity... does make twice the management task but this should be low-maintenance e.g. won't change much Post OpenUserJS#643
* Symmetry with filters Applies to OpenUserJS#643
* Internal code should be okay with `Script`... notice thats not plural Applies to OpenUserJS#643
* One missed label from OpenUserJS#643 in Mod Tools. * More open and closed flag changes for symmetry **NOTES**: * Still to go... reset the absolute DB values for things already flagged/unflagged Applies to OpenUserJS#641
* This will probably be needed for ordered and decrementing mass removals down the line... and uncovered a few logic issues * Add some TODOs ... since this is a work in progress guestimating what should be done... final may be slightly different * Some STYLEGUIDE.md conformance * Add an error handler in `getFlaggedListForContent`... this will tell us if a flag has been found but no user in the non-long-term... Post OpenUserJS#643 fix in Moderation eyeball **NOTES** * Tested mostly on dev and some on local pro Applies to OpenUserJS#126, OpenUserJS#93 and trounces madly upon OpenUserJS#262 (comment) ... sawwy but tiz a boog.
Related to #642. Admins need a way to see who flagged something to remove users that flag things for no conceivable reason.
The text was updated successfully, but these errors were encountered: