Add options to disable comments, the forum, and autocomplete. This is
for personal boorus and potentially for safe mode. Note that disabling
the forum may cause difficulties with creating and approving BURs.
Disabling comments and the forum merely hides them from most areas,
rather than completely removing them.
Disable the ability to upgrade to Platinum. The Platinum level still
exists, but users can no longer upgrade to it. Sales of Platinum are
being disabled in preparation of increasing the tag limit for Gold
users.
* Show the ban length instead of the ban expiration date in ban notices.
* Fix the ban notice to not say "Your account has been temporarily
banned" when it's a permanent ban.
Rework the rate limit implementation to make it more flexible:
* Allow setting different rate limits for different actions. Before we
had a single rate limit for all write actions. Now different
controller endpoints can have different limits.
* Allow actions to be rate limited by user ID, by IP address, or both.
Before actions were only limited by user ID, which meant non-logged-in
actions like creating new accounts or attempting to login couldn't be rate
limited. Also, because actions were limited by user ID only, you could
use multiple accounts with the same IP to get around limits.
Other changes:
* Remove the API Limit field from user profile pages.
* Remove the `remaining_api_limit` field from the `/profile.json` endpoint.
* Rename the `X-Api-Limit` header to `X-Rate-Limit` and change it from a
number to a JSON object containing all the rate limit info
(including the refill rate, the burst factor, the cost of the call,
and the current limits).
* Fix a potential race condition where, if you flooded requests fast
enough, you could exceed the rate limit. This was because we checked
and updated the rate limit in two separate steps, which was racy;
simultaneous requests could pass the check before the update happened.
The new code uses some tricky SQL to check and update multiple limits
in a single statement.
Add a new color palette and rework all site colors (both light mode and dark mode) to
use the new palette.
This ensures that colors are used consistently, from a carefully designed color palette,
instead of being chosen at random.
Before, colors in light mode were chosen on an ad-hoc basis, which resulted in a lot of
random colors and inconsistent design.
The new palette has 7 hues: red, orange, yellow, green, blue, azure (a lighter blue), and
purple. There's also a greyscale. Each hue has 10 shades of brightness, which (including
grey) gives us 80 total colors.
Colors are named like this:
var(--red-0); /* very light red */
var(--red-2); /* light red */
var(--red-5); /* medium red */
var(--red-7); /* dark red */
var(--red-9); /* very dark red */
var(--green-7); /* dark green */
var(--blue-5); /* medium blue */
var(--purple-3); /* light purple */
/* etc */
The color palette is designed to meet the following criteria:
* To have close equivalents to the main colors used in the old color scheme,
especially tag colors, so that changes to major colors are minimized.
* To produce a set of colors that can be used as as main text colors, as background
colors, and as accent colors, both in light mode and dark mode.
* To ensure that colors at the same brightness level have the same perceived brightness.
Green-4, blue-4, red-4, purple-4, etc should all have the same brightness and contrast
ratios. This way colors look balanced. This is actually a difficult problem, because human
color perception is non-linear, so you can't just scale brightness values linearly.
There's a color palette test page at https://danbooru.donmai/static/colors
Notable changes to colors in light mode:
* Username colors are the same as tag colors.
* Copyright tags are a deeper purple.
* Builders are a deeper purple (fixes#4626).
* Moderators are green.
* Gold users are orange.
* Parent borders are a darker green.
* Child borders are a darker orange.
* Unsaved notes have a thicker red border.
* Selected notes have a thicker blue (not green) border.
Refactor CSS to use standard Tailwind-style utility classes instead of
ad-hoc rules. This eliminates a lot of single-purpose rules for specific
UI elements and standardizes margins to be more consistent throughout
the site.
Utility classes are defined manually on an as-needed basis instead of
importing Tailwind as a whole. Naming conventions mostly follow
Tailwind's conventions, otherwise they follow Bootstrap.
* https://tailwindcss.com/docs/
* https://getbootstrap.com/docs/5.0/utilities/spacing/
* Add an explanation of what an API key is and how to use it.
* Make it possible for the site owner to view all API keys.
* Remove the requirement to re-enter your password before you can view
your API key (to be reworked).
* Move the API key controller from maintenance/user/api_keys_controller.rb
to a top level controller.
Factor out FontAwesome icons into a set of helpers. This is so that it's
easier to keep track of which icons we're using and easier to change
icons globally.
* Add a frequently asked questions section.
* Add nicer looking upgrade buttons.
* Format the page nicer.
* Prevent users from attempting invalid upgrades on users that are
already Platinum or above.
* Let Mods and Admins see the email addresses of users below their level.
* Let users see their own email address on their profile.
* Let users verify or edit their email address from their profile.
This is to make catching sockpuppets easier, and to make it easier for
users to fix their email.
* Let moderators see name changes for deleted users on the user name
change requests index and show pages. Before they could see name changes
for deleted users on user profiles, but not on the user name changes index.
* Let members see previous names on profile pages. Before they could see
previous names on the user name changes index, but not on profile pages
(ref: #4382).
- Use the current comparison type for post versions instead
- Also add the note versions as a report
- No other versions are meaningful as reports since it is expected
for them to be modified by other users, or they don't have version
numbers as is the case with artist commentaries
Add a new IP address search page at /ip_addresses. Replaces the old
search page at /moderator/ip_addrs.
On user profile pages, show the user's last known IP to mods. Also add
search links for finding other IPs or accounts associated with the user.
IP address search uses a big UNION ALL statement to merge IP addresses
across various tables into a single view. This makes searching easier,
but is known to timeout in certain cases.
Fixes#4207 (the new IP search page supports searching by subnet).
* Fix inconsistencies in how wiki pages were linked.
* Link directly to the wiki instead of to a title search that is expected
to redirect to the wiki.
* Add post/comment/forum vote counts to user profiles.
* Show uploaders on post votes index and allow searching by uploader.
* Show forum posters on forum votes index and allow searching by poster.
* Add unvote link to forum votes index.
* Only show unvote links to current user.
* Let gold users use upvote:self, downvote:self metatags to search for
their own votes.
* Don't let mods use upvote:<user>, downvote:<user> metatags to see
votes by other users. Only let admins see other users' votes.
* Add vote count to profile page.
* Always display 'Saved searches' link in subnav bar, even if the user
hasn't created any saved searches yet.
* Eliminate use of `has_saved_searches` bitpref on users.
Fineprint text was variously styled with `.info`, `.tn`, `.hint`, or
`.cost-footnote` css classes. Standardize on `.fineprint` instead. Use
`.hint` only for form hints and `.tn` only for <tn> tags in translation
notes.
Incidentally changes the font size of form hints to 0.8em (was 0.7em)
and the color of fineprint to #888 (was #AAA or #666).
Ensure dtext is always wrapped in a `<div class="prose">` or
`<span class="prose">` (for inline dtext) container so that dtext css is
properly applied.
* Allow mousing over the upload limit on profile pages to show the full
formula for the upload limit calculation. In particular, show how the
upload limit multiplier is derived from the deletion confidence.
* Refactor to avoid duplicating upload limit calculations in the
presenter, as much as possible.
