/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.
