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.
Filter out the user's own uploads and favorites from their
recommendations.
Note that in most cases a user's top-N recommendations will be things
they've already favorited. If a user has 10,000 favorites, most of their
top 10,000 recommendations will be their own favorites, so we have to
generate a little more than 10,000 recommendations to be sure they won't
all be filtered out.
In other words, the more favorites a user has, the more recommendations
we have to generate. The upper bound is clamped to 50,000 for
performance reasons. If a user has more favorites than this we may not
be able to find any recommendations for them.
* Open recommendations to all users (not just gold).
* Show recommendations on all posts (not just posts after 2017).
* Allow users to browse recommendations for other users.
* Increase number of recommended posts returned.
* Change endpoints to /recommended_posts?user_id=1234 and
/recommended_posts?post_id=1234 and add json/xml support.
Don't return the `domains` field in /artists/{id}.{json,xml}. Fixes a
failure in /artists/{id}.xml:
https://danbooru.donmai.us/artists/156646.xml
<result success="false">
undefined method `domains' for #<ArtistUrl:0x00005566dd340af0> Did you mean? DomainName
</result>
`to_xml` passes down the `methods` param to all nested models, which
doesn't work.
