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.
* GET /bans.json
* GET /bans/1.json
* GET /ip_bans.json
* POST /ip_bans.json
* DELETE /ip_bans.json
* GET /mod_actions.json
* GET /posts/1/events.json
* POST /saved_searches.json
* DELETE /saved_searches/1.json
* GET /super_voters.json
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).
