Bug:
Platinum users get this error when commenting:
No route matches {:action=>"show", :controller=>"posts", :id=>nil}
missing required keys: [:id]
Fix:
The issue was that `CurrentUser.role` was nil for Platinum users, which
caused `Comment.create(create_params, :as => CurrentUser.role)` to
silently ignore the create_params because the nil role wasn't in the
attr_accessible whitelist.
Despite this, things worked accidentally for other models because they
had `attr_accessible ..., :as => [:default]` in their whitelists where
the comment model didn't.
* Add 'post as moderator' option to comment form. This creates a so-called sticky comment.
* Downvotes have no effect on stickied comments; they're always visible, regardless of comment thresholds.
* Only mods may sticky comments.
* Mods may sticky comments by other users.
Fixes an issue with the ugoira player not working on Safebooru due to
this error:
Asset filtered out and will not be served: add
`Rails.application.config.assets.precompile += %w( ugoira_player.js)`
to `config/initializers/assets.rb` and restart your server
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.
Dead code as far as I can tell. According to `git log -p -G "X-Html-Id"`
was added in 2011 and never used. HTML id is passed to javascript in the
JSON response to `POST /notes.json` instead.
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.
`update_attribute` doesn't trigger `before_validation` callbacks, which
is where metatag processing happens. `update` or `update_attributes`
must be used instead.
AFAIK the test suite is the only place where `post.update_attribute(:tag_string => "stuff")`
is used, the actual code doesn't use it.
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.
Exercise a few bugs:
* rating:safe should obey on rating locks.
* source:blah should update the pixiv id.
* source:" foo bar baz " should trim leading/trailing whitespace.
The other tests are for metatags that work but didn't have tests.
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.
evazion
