Also remove non-nullable and default options from migration. The column
didn't originally have these options so they shouldn't be added if the
migration is reverted.
By default, mails sent by deliver_later are added to the `mailers` job
queue. These mails weren't being sent because workers were only
configured to process the `default` queue.
* Make it so that you can click the stickied / locked / deleted icons or
the new / approved / pending / rejected labels to filter topics by
that status.
* Replace the `mod_only` search param with `is_private`.
Previously only actions that were marked member_only or above were
subject to IP ban restrictions. This meant that certain actions that
weren't marked member_only, like creating new accounts, could still be
done by IP banned users.
Now IP banned users can't do any non-GET actions, which means they're
not allowed to even login to their accounts.
* Move emails from users table to email_addresses table.
* Validate that addresses are formatted correctly and are unique across
users. Existing invalid emails are grandfathered in.
* Add is_verified flag (the address has been confirmed by the user).
* Add is_deliverable flag (an undeliverable address is an address that bounces).
* Normalize addresses to prevent registering multiple accounts with the
same email address (using tricks like Gmail's plus addressing).
Remove code for updating forum topics when an alias or implication is
approved or rejected. This code was only used when approving single
alias or implication requests. This is no longer used now that all
alias/implication requests are done through BURs.
Use pending / approved / rejected status labels in front of the topic
title instead of a BUR count column. This is to make the forum listing
easier to visually scan for resolved vs unresolved topics.
Labels are only added for topics in the Tags category. This is a hack to
avoid labels on megathreads that have had BURs mistakenly attached to them.
[APPROVED] and [REJECTED] labels are stripped from thread titles to make
the titles cleaner. This is a hack until these titles can be fixed.
The old password reset flow:
* User requests a password reset.
* Danbooru generates a password reset nonce.
* Danbooru emails user a password reset confirmation link.
* User follows link to password reset confirmation page.
* The link contains a nonce authenticating the user.
* User confirms password reset.
* Danbooru resets user's password to a random string.
* Danbooru emails user their new password in plaintext.
The new password reset flow:
* User requests a password reset.
* Danbooru emails user a password reset link.
* User follows link to password edit page.
* The link contains a signed_user_id param authenticating the user.
* User changes their own password.
* Fix users being redirected back to the change password page after
successfully changing their password.
* Move passwords controller out of /maintenance/ namespace.
* Add tests.
