Make e.g. hatsune_miku_(cosplay) automatically add hatsune_miku and cosplay.
Perform autotagging after aliasing so that *_(cosplay) aliases (e.g.
hestia_(dungeon)_(cosplay) -> hestia_(danmachi)_(cosplay)) can take
effect first.
Previously only the BUR's approver was set when a BUR was approved. Set
the approver for each alias/implication in the BUR as well.
Additionally:
* Refactor `approve!` to take a user instead of just a user id.
* Be mass-assignment permissions aware when setting approver_id.
* Attribute the "tag alias has conflicting wiki pages" message to the
alias approver, not to the first admin.
* Merge the conflict message and alias approval message into one forum post.
* Fix an error with NewRelic gem not installed in test environment.
Move normalize_tags (which processes metatags) from before_save to
before_validation. This is so that it runs as early as possible, before
strip_source / parse_pixiv_ids / updater_can_change_rating, so these
callbacks can handle source/rating changes from metatags.
Fixes a couple bugs:
* Ratings locks were ignored when using rating:s metatag (regression in 0006b76)
* Pixiv ids weren't updated when using source:blah metatag.
Note: this means that `post.update_attribute(:tag_string => "art:bkub)`
is now wrong. This is because update_attribute runs callbacks but not
validations, so it doesn't process metatags from the tag string.
`update` or `update_attributes` must be used instead.
Reorder callbacks into the same order Rails runs them in:
* before_validation
* validate
* before_save
* before_create
* after_create
* after_save
* after_commit
This doesn't change the behavior of anything, it simply rearranges
callbacks so their running order is less confusing.
Currently rating locks are only obeyed when using the rating: metatag.
They aren't obeyed when:
* Changing the rating via the API.
* Changing the rating via 'Rate Safe' in the mode menu (uses the API).
* Reverting to previous versions.
Also, the current behavior is to ignore the rating: metatag if the post
is locked. This patch instead makes the update fail completely (note that
this could affect trying to mass revert posts that may be rating locked).
Note: the check for `!is_rating_locked_changed?` is so that
PUT /posts/1.json?post[rating]=s&post[is_rating_locked]=true
works (ie., locking and changing the rating at the same time is okay).
Creates a mod action any time an alias or implication is changed. This
includes creations, edits to pending aliases/implications, deletions,
and approvals. Also it logs each status change from pending -> queued
-> processing -> approved.
Call are changed from `update_column` to `update` so that the
create_mod_action callback will run at every point in the lifecycle.
There was a regression in 6d6d00b; `before_filter :voter_only` was a
no-op in the post vote controller because it merely returned false,
which does not halt the request. The fix is to arrange for a voter_only
method to be defined that properly redirects to the access denied page.
* Validates that status is active/pending/deleted/etc. Not strictly
necessary, the controller prevents users from setting the status, but
it doesn't hurt.
* Validates that forum_topic_id is a valid topic if it's present.
* Validates that approver_id and creator_id are valid users (not
strictly necessary either, users can't set these values).
