Bug: when moving favorites, the parent is given an upvote for each gold+
favoriter, but the magnitude of these upvotes was based on the
CurrentUser, rather than the upvoter. This meant that upvotes for
supervoter favorites weren't given correctly.
To fix this, `magnitude` is changed to use the voting `user` instead of
CurrentUser.
New problem: when setting the score, `score=` calls `magnitude`, but
`user` isn't initialized yet. So we also refactor so that
1. `initialize_attributes` initializes `user` before setting `score`
2. the vote direction is given by `vote`, so it's separate from `score`
3. updating the score on the post happens in a callback instead of
directly in `score=`.
/posts/:id/events incorrectly lists appeals as always being resolved.
This is because events UNION together appeals and flags, which doesn't
quite work because for appeals is_resolved is a method, not an
attribute. is_resolved was hardcoded to true so it'd work in the UNION.
This changes PostEvent to be a wrapper object around PostFlag /
PostAppeal, instead of a UNION. PostEvent delegates everything to the
inner flag/appeals object, so that is_resolved works correctly.
Also, this incidentally fixes a problem with /posts/:id/event.xml not
serializing correctly.
Bug introduced in 1400f64; that commit changed dmails so that
creator_ip_addr defaulted to CurrentUser.ip_addr like this:
after_initialize :initialize_attributes, if: :new_record?
def initialize_attributes
self.from_id ||= CurrentUser.id
self.creator_ip_addr ||= CurrentUser.ip_addr
end
...but creator_ip_addr already defaulted to 127.0.0.1 from the database,
so the ||= assignment didn't work. Remove the database default so we
always default to CurrentUser.ip_addr.
The template looks like this:
Subject:
#{creator_name} mentioned you in a comment on post ##{post_id}
Body:
@#{creator_name} mentioned you in a \"comment\":/posts/#{post_id}#comment-#{id} on post ##{post_id}:
[quote]
#{DText.excerpt(body, "@"+user_name)}
[/quote]
There's not much sense in saving copies of everything DanbooruBot sends
in DanbooruBot's inbox. They probably won't be checked so it just bloats
the dmails table.
/dmails is restricted to viewing dmails for CurrentUser only (due to
Dmail.visible in the index action). Remove owner_id from subnavbar links
in /dmails, and don't support it in /dmails?search[owner_id], since it
doesn't actually do anything.
Also removes related dead methods and fixes tests that didn't test owner_id properly.
