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=`.
Bug: when an approver moves the favorites of a post, each favorite is
removed from the child post and added to the parent post. For gold+
users, this triggers an upvote, but these upvotes were performed by the
approver rather than the favoriter.
/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.
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.
Sends automated dmails from `Danbooru.config.system_user`, rather than
whichever user is performing the action happens to be (usually User.admins.first).
Also adds a notice in the view that the dmail was automated.
/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.