Posted under Bugs & Features
So not just status:flagged, but posts where status:flagged has ever been true, whether the post is currently status:active, status:deleted, status:banned or status:flagged.
This would allow a user to query all of the posts with flags that have ever been raised against themselves or against another user, e.g. beenflagged:BrokenEagle98 would return all of the posts that had ever been flagged from my uploads.
Thoughts, including alternate names for the metatag?
Don't know about making it public. I know I just asked you to do this for me but I don't know if every user should be able to know which of my posts have ever been flagged. But on the other side, there is also user:Provence status:deleted (stupid water tap upload :>). So I have no real preference here to make it public.
I figured it could be a tool for users and also moderators.
For users:
For moderators:
I'm sure there are other uses, but those are just a few I could think of off the top of my head.
Also, like it's been pointed out, user:BrokenEagle98 status:deleted is already public as is the flag events of any post (Flags & Appeals link under History on every post page), although it did require a script to join those disparate sources of data into a single list.
Well, it would make things certainly easier to track down for moderators if one user is suspecting an attack of a flagger against them. And it might also be useful to determine easier which posts are more borderline if the user is missing the flagged post while it has a red border. So they see, even if re-approved, that those posts are borderline and should be a "warning". So i'd be nice to see these posts in a list.
I've been working on this a little, but I'm not sure if the query will perform well enough on the live site or if it will time out. I'm working on importing a copy of the database to my devbooru so I can better test it.
There is some slight trickiness here too, because "ever been flagged" includes not just manually flagged posts, but also posts that were automatically flagged after going unapproved in three days. So a hypothetical user:evazion status:deleted flagged:true wouldn't be able to tell you which posts were deleted due to manual flags vs. unapproved in the mod queue. Likewise, user:evazion status:active flagged:true wouldn't tell you what was manually flagged then reapproved vs. what was deleted in the queue then undeleted.
Really... even though the post flags controller and model has the addon search[category]=normal to limit the flags that were manually applied...?
Example:
http://danbooru.donmai.us/post_flags?search[category]=normal
At least, that's what I used with my script so that I wouldn't have to sort through the automatic "unapproved" flags...
fossilnix said:
If the point is to find borderline uploads, then maybe including those that went 3 days without anyone wanting to approve them, and had to be undeleted, is a good thing.
Hmmm... you raise a valid point. I hadn't considered a search for posts that were undeleted as part of the equation.
Maybe in addition to a beenflagged metatag, there could also be a beendeleted metatag...?
BrokenEagle98 said:
Really... even though the post flags controller and model has the addon search[category]=normal to limit the flags that were manually applied...?
search[category]=normal doesn't exactly filter out automatic flags. It filters out flags with the reasons "Unapproved in three days", "Unapproved in three days after returning to the moderation queue", and "Artist requested removal". That's not entirely correct, since technically a regular user could flag a post with one of those reasons. I'm not sure if anyone has ever done so though.
More importantly, it misses out on certain old flags with the reason "Unapproved in three days after returning to the moderation queue (previous reason: <whatever>)".
Anyway, made some progress on this. Currently on http://devbooru.evazion.ml:3000/:
Usually you'll want to use status:deleted or -status:deleted in combination with the above tags.
Updated by evazion
Might want to fix the link in your above post...
It should be http://devbooru.evazion.ml:3000/ and not http://devbooru.evazion.ml:3000/:
Some initial feedback...
From the post flags page, when searching the normal category, it shows duplicates for posts where they went unapproved after 3 days. I'm guessing this was the intended behavior...?
Updated by BrokenEagle98
No, that's a bug. There's also a bug with duplicates inside tag searches I haven't fixed yet (see http://devbooru.evazion.ml:3000/posts?tags=user:葉月+flag:any+status:any).
Some more feedback...
1. From the posts page, when searching using the flag metatag, duplicates of the same post will be returned for posts with more than one flag (the same bug you noted above, but this was written before I refreshed the page and saw your post).
Example:
http://devbooru.evazion.ml:3000/posts?tags=flag%3Anormal+id%3A630935+status%3Aany
2. From the posts page, when searching using the flagreason metatag, string bounding with quotation marks "" does not work, making it only possible to search for single word flags.
3. Although it wasn't mentioned above, the behavior gets odd when no other flag metatags are used with order:flagged. All posts that were never flagged appear at the beginning in a weird order (not random though, since page refreshes return the same order). Vice-versa for order:flagged_asc.
4. Since all flags were done by "albert" in the conversion, I created a flag using account BrokenEagle 98 on the following post...
http://devbooru.evazion.ml:3000/posts/1149280
When searching using flagger:BrokenEagle98, it did not bring up that post, and instead acted as I had entered nothing into the tag search filed, i.e. /posts.
I had to log in as a moderator (Log) to test the flagger metatag, at which time it did work.
5. Are there plans to add appealer and appeal metatags...? It might be helpful to post approvers that want to see all of the existing posts with appeals from the post screen... ex: appeal:any status:deleted
BrokenEagle98 said:
2. From the posts page, when searching using the flagreason metatag, string bounding with quotation marks "" does not work, making it only possible to search for single word flags.
Yeah, I was planning on adding that, just haven't done it yet.
I was also thinking about regex searches, maybe with flagreason:/regex/. Postgres has a regex match operator, so I think it would be possible to do. Not sure about the performance and security implications of allowing this though.
3. Although it wasn't mentioned above, the behavior gets odd when no other flag metatags are used with order:flagged. All posts that were never flagged appear at the beginning in a weird order (not random though, since page refreshes return the same order). Vice-versa for order:flagged_asc.
order:flagged by itself doesn't exclude unflagged posts. Previously it listed them first in unsorted order. Now it sorts them last, so it should be slightly better, although I guess they should be excluded altogether.
When searching using flagger:BrokenEagle98, it did not bring up that post, and instead acted as I had entered nothing into the tag search filed, i.e. /posts.
Should be fixed now, thanks.
5. Are there plans to add appealer and appeal metatags...? It might be helpful to post approvers that want to see all of the existing posts with appeals from the post screen... ex: appeal:any status:deleted
Yeah, I plan on adding that. Just dealing with the flag metatags first since the code for the appeal metatags will be almost the same.
BrokenEagle98 said:
When searching using flagger:BrokenEagle98, it did not bring up that post, and instead acted as I had entered nothing into the tag search filed, i.e. /posts.
evazion said:
Should be fixed now, thanks.
Thanks. Tested it and it works.
Although, I checked from a different non-moderator account, and it had the same behavior as before, i.e. showing all posts instead of no posts. If that behavior is unavoidable, it should probably be documented once everything gets fully implemented.
Metatags aren't very consistent in that regard. Some silently ignore invalid input and show all posts instead: user:qgjqrgj, approver:qgjqrgjj, commenter:qgjqrgj, status:qgjqrgj, rating:gqjqrgj. But then others return nothing: fav:qgjqrgj, pool:qgjqrgj. Probably need to standardize on one behavior or another.
