The old flag limits were:
* 1 flag per day for regular members.
* 10 flags per day for Gold users.
* Unlimited flags for approvers.
The new flag limits are:
* 10 flags in the modqueue at once for regular users.
* Unlimited flags for approvers.
* Unlimited flags for users with a high enough flag success rate. If you
have at least 30 flags in the last 3 months, and you have at least a
70% flag success rate, then you get unlimited flags.
10 flags at once means you can have up to 10 flagged posts in the
modqueue at the same time. Because flags stay in the modqueue for 3
days, this means you can flag on average 10 posts every 3 days, or just
over 3 posts per day.
The old limit was one appeal per day. The new limit is based on your
upload limit. Each appeal costs 3 upload slots. If you have 15 upload
slots, then you can appeal up to 5 posts at once, but you won't be able
to appeal or upload more until your appeals are approved or rejected. If
you have unlimited uploads, then you have unlimited appeals.
Replace references to the `is_resolved` field with the `status` field.
Post flags were marked as resolved when a post was approved (but not
when the post was deleted because it went unapproved). The status field
supercedes the resolved field.
Allow searching enum fields by string, by id, or by array of
comma-separated values. The category field in modactions is an example
of an enum field that can be searched this way.
Fix not having any space between the Submit / Cancel buttons and the
bottom of the dialog box. For some reason this only happens in
production, not development.
Possible fix for this exception that happens in production for unclear
reasons:
NoMethodError: undefined method `is_admin?' for nil:NilClass
…oru/releases/20200805193154/app/policies/tag_policy.rb: 3:in `can_change_category?'
…www/danbooru/releases/20200805193154/app/models/tag.rb: 216:in `find_or_create_by_name'
…www/danbooru/releases/20200805193154/app/models/tag.rb: 193:in `block in create_for_list'
…www/danbooru/releases/20200805193154/app/models/tag.rb: 193:in `map'
…www/danbooru/releases/20200805193154/app/models/tag.rb: 193:in `create_for_list'
…ww/danbooru/releases/20200805193154/app/models/post.rb: 463:in `normalize_tags'
Fix exception when viewing post #23077 (a .zip that is not a ugoira).
Caused by including large_image_width in the image's data-* attributes.
The image_width was nil, which caused a comparison to fail.
* Include appealed posts in the modqueue.
* Add `status` field to appeals. Appeals start out as `pending`, then
become `rejected` if the post isn't approved within three days. If the
post is approved, the appeal's status becomes `succeeded`.
* Add `status` field to flags. Flags start out as `pending` then become
`rejected` if the post is approved within three days. If the post
isn't approved, the flag's status becomes `succeeded`.
* Leave behind a "Unapproved in three days" dummy flag when an appeal
goes unapproved, just like when a pending post is unapproved.
* Only allow deleted posts to be appealed. Don't allow flagged posts to be appealed.
* Add `status:appealed` metatag. `status:appealed` is separate from `status:pending`.
* Include appealed posts in `status:modqueue`. Search `status:modqueue order:modqueue`
to view the modqueue as a normal search.
* Retroactively set old flags and appeals as succeeded or rejected. This
may not be correct for posts that were appealed or flagged multiple
times. This is difficult to set correctly because we don't have
approval records for old posts, so we can't tell the actual outcome of
old flags and appeals.
* Deprecate the `is_resolved` field on post flags. A resolved flag is a
flag that isn't pending.
* Known bug: appealed posts have a black border instead of a blue
border. Checking whether a post has been appealed would require either
an extra query on the posts/index page, or an is_appealed flag on
posts, neither of which are very desirable.
* Known bug: you can't use `status:appealed` in blacklists, for the same
reason as above.
Don't automatically move favorites to the parent when expunging a post.
This can be done manually if necessary. Posts shouldn't have their
favorites moved unless they're duplicates, which expunged posts usually
aren't.
Bug: Tag#update_post_category_counts effectively called
`update_all("tag_count_general" => 123, :tag_count => 456)`, which led
to an argument error due to the :tag_count symbol being treated as a
keyword argument.
Fix: Don't mess around with `update_all`, just regenerate the tag counts
then `save!` the post. We have to do this in an after_save callback
because we need the updated category to be in the database for `set_tag_counts`
to work. Delete `fix_post_counts` because it was unused.
This is most likely a regression caused by the upgrade of the
newrelic_rpm gem to 6.12. This can only be reproduced in production when
using Newrelic and it didn't happen before the upgrade. Presumably
Newrelic is splatting the arguments when it calls `update_all`, which
causes symbol keys to be treated as keywords.
* Remove unused `ban` and `without_mod_action` options.
* Don't try to set the `is_banned` flag during deletion.
* Don't create modactions for automatic "unapproved in 3 days"
deletions, only to delete them after the fact.
Rework post deletion from using a separate page to using a dialog box,
like flagging.
* Add `DELETE /posts/:id` endpoint.
* Remove `POST /moderator/post/posts/:id/delete` endpoint.
Rewrite the tag counter widget (the one above the tag edit box) to use
React. This is a trial run for using React elsewhere.
We actually use Preact instead of React because it's lighter weight.
We use Mobx for state management because it's cleaner than React's
setState or useState.
This incidentally fixes a couple bugs:
* The tag counter wasn't updated when deleting tags with backspace
* The tag counter wasn't updated when pasting in new tags.
* Show a banner if the user is restricted because they signed up from a
proxy or VPN.
* Add an option to resend the confirmation email if your account has an
unverified email address.
Bug: if you moused over another note while dragging a note, it would
trigger a note body popup. This would also happen when drawing out a new
note.
Also fix the drag box for new notes being drawn behind other notes.
Bug: loading and saving a note without moving it could change the note's
position. Moving a note with the keyboard could also cause unintended
changes to the note's size or position. This was because of floating
point errors when converting from percentage coordinates (floats) to pixel
coordinates (integers).
Fix: store note coordinates as pixel coordinates instead of as
percentage coordinates. Percentages are only used to position notes for
display.
Also fix it so you can resize rotated notes with the keyboard. This was
disabled before.
* Raise notes when hovering over them. This is so that when dragging
embedded notes, they're not hidden behind other notes. Also so that if
two notes are overlapping, you can hover over one to raise it over the
other.
* Replace .hovering class with :hover selector.
Bug: if you used they keyboard to move or resize a note, then the note
body would stay visible, which could get in the way when moving in the
down direction.
