Add a sidebar to the modqueue page that shows the following information:
* Number of pending and flagged posts.
* Number of posts disapproved for poor quality or breaking rules.
* Top uploaders in the queue.
* Top artist, copyright, and character tags in the queue.
* Include appeals and flags.
* Avoid an existence query for pools.
* Avoid a query checking if the user has previously approved the post.
This is a rare condition and it will be prevented anyway if the user
tries to reapprove the post.
* Change the `disapproval:<reason>` metatag to `disapproved:<reason>`.
* Change `disapproved:<reason>` to show all posts disapproved for a
given reason, not just those disapproved by the current user.
* Allow searching for your own disapprovals with `disapproved:<my_name>`.
* Drop the `disapproved:<any|none>` metatags. `disapproved:any` is
equivalent to `disapproved:<my_name>` and `disapproved:none` is
equivalent to `-disapproved:<my_name>`.
These changes are so that you can search e.g. disapproved:poor_quality
to find all posts disapproved for poor quality.
Send weekly warning dmails to approvers in danger of losing their
approver permissions. Don't send warnings if we're more than three weeks
away from demotion so that approvers aren't warned prematurely.
Set the sender name and IP addresses explicitly in the controller rather
than implicitly in the model.
Fixes cases where automated dmails from DanbooruBot had their IP
addresses set to the person who triggered the dmail, even though they
didn't actually send the dmail themselves.
Refactor to use a recursive CTE to calculate implied tags in SQL, rather
than storing them in a descendant_names field. This avoids the
complexity of keeping the stored field up to date. It's also more
flexible, since it allows us to find both descendant tags (tags that
imply a given tag) as well as ancestor tags (tags that are implied by a
given tag).
* Allow approvers to approve a post by tagging it with status:active.
* Allow approvers to ban a post by tagging it with status:banned.
* Allow approvers to unban a post by tagging it with -status:banned.
Remove the creator_id field from artists, notes, and pools. The
creator_id wasn't otherwise used and was inconsistent with the
artist/note/pool history in some cases, especially for old artists.
Remove the post update count estimate from BUR show pages. This was
complex, slow, and usually inaccurate since it assumed that requests in
a BUR had no overlap with each other, which usually wasn't the case.
Refactor to use accepts_nested_attributes_for instead of the notes
attribute to facilitate editing wikis on the artist edit page.
This fixes the notes attribute unintentionally showing up in the API.
This also changes it so that renaming an artist entry doesn't
automatically rename the corresponding wiki page. This had bad behavior
when there was a conflict between wiki pages (the wikis would be
silently merged, which usually isn't what you want). It also didn't warn
about wiki links being broken by renames.
* Automatically generate a mod report when a comment, forum post, or
dmail is detected as spam.
* Automatically ban users that receive too many automatic spam reports
within a short window of time.
* Automatically mark spam dmails as deleted.
* Change ban threshold from 10 spam reports in 24 hours to 10 reports in 1 hour.
* Change ban length from 3 days to forever.
* Add ability to mark dmails as unread.
* Fix users.unread_dmail_count to not count deleted dmails.
* Fix show action so that API calls don't mark dmails as read.
* Don't show the unread dmail notice on the /dmails page itself.
* Stop using users.has_mail flag.
Fix bulk update requests generating invalid [bur:<id>] links in forum
posts. The id was missing because the BUR created the forum topic in a
before_create hook, which created the post before the BUR was saved so
the BUR didn't have an id yet. Fix regression caused by b4ce2d83.
Avoid doing one SQL query per topic when checking for new topics on the
forum index.
This also changes it so that forum topics aren't always marked as new
for anonymous users.
* Rarely used (only used ~15 times in total, not used at all since 2015-2016).
* Merging topics didn't properly bump the new topic.
* Merging topics didn't log a modaction when the old topic was deleted.
* Merging topics broke the old topic. Moving all the posts from one topic
to another leaves the old topic with zero posts. This normally can't
happen and it causes exceptions when you try to view the empty topic.
* It was technically possible to merge a topic with itself. This would
break the response_count.
* It was technically possible for a mod to merge a topic into an
admin-only topic.
Few people used dmail filters (~900 users in 5 years) and even fewer
used them correctly. Most people used them to try to block dmail spam,
but usually they either blocked too much (by adding common words that
are present in nearly all dmails, causing all mails to them to be
filtered) or too little (blocking specific email addresses or urls,
which usually are never seen again after the spammer is banned).
Nowadays the spam detection system does a better job of filtering spam.
The belongs_to_creator macro was used to initialize the creator_id field
to the CurrentUser. This made tests complicated because it meant you had
to create and set the current user every time you wanted to create an
object, when lead to the current user being set over and over again. It
also meant you had to constantly be aware of what the CurrentUser was in
many different contexts, which was often confusing. Setting creators
explicitly simplifies everything greatly.
* Rename 'privacy mode' to 'private favorites'.
* Make the private favorites setting only hide favorites, not favgroups
and not the user's uploads on their profile page.
* Make the favgroup is_public flag default to true instead of false and
fix existing favgroups to be public if the user didn't have privacy mode
enabled before.
* List _all_ public favgroups on the /favorite_groups index, not just
favgroups belonging to the current user.
* Add a /users/<id>/favorite_groups endpoint.
Remove restrictions against flagging too many posts by the same
uploader. This had problems with preventing legitimate flags in some
cases, particularly with old legacy content. This will be policed
manually instead.
This was an alternate frontpage that contained a list of previews of the
most popular tags. This page was never linked from anywhere and it was
unknown by most users.
Eliminate the Danbooru.config.hostnames option. It was only used for
rewriting links in notes. Just using the main hostname is good enough,
there aren't any notes still using any of Danbooru's alternate domain
names.
* Don't link non-artist tags to artist pages, even when the tag has an
artist entry. These artist entries are usually old deleted entries
that happen to have the same name as a gentag, or leftover entries
that need to be deleted.
* URL escape the artist name in /artists/show_or_new?name={name}
This was a search page that let you search for tags, aliases, and
implications at the same time. It never got much use and it's been
broken for a while now (the search form passed the wrong param to the
controller).
Add test for #4243. Also fix warning from bootsnap:
iseq.rb:18: warning: nested repeat operator '+' and '?' was replaced with '*' in regular expression: /(?<!\A)生誕祭(?:\d+)?\z/
