Renaming discourse_voting to topic_voting since there are two forms of voting in Discourse - posts and topics.
This PR also moves a OnceOff into a post migration. The post migration will be executed, but should ideally be a no-op. This allows us to not have to maintain the OnceOff as it had to be modified before with a previous migration. I considered removing this file altogether, but I don't think there is anything negative from just converting it into a migration, and it might be useful in the unlikely scenario that a forum from the past has never ran the OnceOff before.
Previously, we were deleting the `enable_topic_voting` custom field param
and doing the staff logging in this plugin. This has a problem though, it
was being done in the model's create/destroy hooks and was missing the
acting user (so the logs would report the change as `system`).
This PR keeps the custom field param and relies on core to do the staff
action logging. This change also results in the custom field being set
in the DB when it is enabled even though we don't use it in the serializer.
Passing the respect_plugin_enabled argument to #add_to_serializer as a positional argument is deprecated. It is now expected to be a keyword argument. This PR adds the keyword.
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
Régis Hanol
Natalie Tay
Loïc Guitaut
Renato Atilio
Penar Musaraj
Martin Brennan
Ted Johansson
David Taylor
Bianca Nenciu
Natalie Tay
Vinoth Kannan
Roman Rizzi
Dan Ungureanu
Alan Guo Xiang Tan
Justin DiRose
Krzysztof Kotlarek
Mark VanLandingham
Sam Saffron
Joffrey JAFFEUX
Tomas Varaneckas
Guo Xiang Tan
Vinoth Kannan