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 forum subscriptions (only around 100), and even fewer
people were subscribed to active threads. Most subscriptions were for
old threads that will never be bumped again. The implementation also had
a few problems:
* Unsubscribe links in emails didn't work (they unset the user's
receive_email_notifications flag, but forum subscriptions didn't
respect this flag).
* Some users had invalid email addresses, which caused notifications to
bounce. There was no mechanism for preventing bounces.
* The implementation wasn't scalable. It involved a daily linear scan
over _all_ forum subscriptions looking for any topics that had been updated.
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.
- Limited to Builders+
-- Moderator+ can also use as they may be too busy ATM
- Only on users, comments, and forum posts
- Multiple reports can be generated per instance
- Primarily posts to a moderator-only topic for viewability
- Secondarily has a table for searchability
-- Viewable only by moderators
* 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.
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.
* Convert notices from helpers to partials.
* Eliminate PostSets::PostRelationship class in favor of post_sets/posts template.
* Eliminate COUNT(*) queries when calculating the number of child posts.
* Eliminate redundant parent load and parent exists queries.
Remove uses of the is_active flag. Keep column in database (for now).
The only purpose of this flag was to filter out pools from the pool list
in the Add to Pool dialog. This hasn't had much use since autocomplete
was added. Most pools didn't set the flag correctly anyway.
Remove the targeted down voting report. This report hasn't been working
for a while. The /post_votes page is a better way to investigate
downvoting activity anyway.
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).
- In some cases deleted items weren't visible from the index view
- There also shouldn't be any reason why they can't be shown when searched for specifically
-- This also matches the behavior on comments
* Warn when renaming a wiki that still has links from other wikis.
* When renaming a wiki that still has posts, just show a warning instead
of returning an error and making the user confirm the rename.
Remove the login reminder page. The meaning of "login reminder" wasn't
clear (it's for recovering a forgotten username) and the functionality
was redundant. The password reset page can already be used to recover
forgotten usernames.
There was also a privacy leak, since the login reminder page could be
used to find out whether a given email is in use on Danbooru.
* Replace /session/new with /login and /session/sign_out with /logout.
* Rename 'sign in' to 'login'.
This changes are to make urls cleaner and terminology more consistent.
* Fix the post-upgrade message showing the gift message instead of the
normal upgrade message.
* Link back to Danbooru so people don't stay on Safebooru and get
confused when they can't see hidden posts.
