We shouldn't add vote fields for personal messages since users can't vote there. If we include then it's creating an N+1 issue in the `private-messages-all` endpoint.
Changing category settings would not always unhide the like button
because the model would not be updated on the client side until a full
page refresh.
Was able to reproduce a bug where votes were not properly moved when merging two topics together. We were only checking duplicate votes if either both votes were either active or archived, and not a mix of the two. As a result, there were cases where the plugin was trying to move votes that already existed on an open topic, causing the merge to partially fail with a duplicate index error.
What this commit does is as follows:
- Cleaned up the logic so it's more readable. Previously it was duplicative and difficult to read.
- We're now checking if a user has a vote on Topic A (active or archived) and Topic B (active or archived) that we're properly deleting the origin vote and keeping the destination vote instead of trying to merge in a duplicate. (This caused the original bug described above).
- Per the specs on meta, topic merges move all votes to the destination topic, and if this causes a user to go over the limit, they'll have to wait until enough votes are released.
- If the destination topic is closed, the votes will be archived; if the destination topic is open, those votes will be active. This is regardless of origin vote state.
Also, the Gemfile was missing a source declaration to allow installation of gems/dependencies, so I've added that.
The fix is pretty simple
result = result.select("*, ... AS current_user_voted")
become
result = result.select("topics.*, ... AS current_user_voted")
I also merged all 3 'TopicQuery.results_filter_callbacks' into one and did
some slight refactoring on the 'add_to_serializer'.
We are trying to avoid custom tables. Changes:
CategoryCustomField -> DiscourseVoting::CategorySetting # contains infromation if voting is enabled for category
UserCustomField -> DiscourseVoting::Vote # user's votes
TopicCustomField -> DiscourseVoting::VoteCounter # cache count for topics
Currently, if you got that plugin installed and change code in development in Discourse, you will see an error like:
`undefined method `can_vote?'`
A reason for that was incorrectly defined `reloadable_patch` block. That block defines everything which should be reloaded by ActiveSupport::Reloader if code is changed.
because that was not included in that block
```
class ::Category
def self.can_vote?(category_id)
end
end
```
method `can_vote?` was not anymore available.
Merging two votes with topics will edit the moderator post describing
the move operation, to include information about how many votes were
moved and why some votes were not (because user already voted for the
destination topic).
Per: bd5fa173 in Discourse there is no longer need re-register serializers
in all descendants. This change was backported so this change to discourse
voting is safe.
`after_find` is a very risky callback cause it can impact how read perf
works. In this case it was loading a custom field on category which
triggered an N+1 on a fresh load of a site.
This amends it so we do the repair before save