mirror of
https://gh.wpcy.net/https://github.com/discourse/discourse.git
synced 2026-05-09 04:41:30 +08:00
c5a6754e29
In a post-voting topic, the vote count on posts and answers did not update after a vote was cast — a full page refresh was required to see the new value. Comments were unaffected. The root cause is that `post_voting_vote_count` is missing from the plugin's `api.addTrackedPostProperties(...)` call. The local vote path writes directly to `post.post_voting_vote_count`, which bypasses Ember's notification layer and only dirties a tracking tag when the property has been installed via `defineTrackedProperty`. Without it, the template's read of `@post.post_voting_vote_count` never picked up the change. Existing acceptance coverage went through `publishToMessageBus` → `post.setProperties(...)`, which *does* notify and so masked the bug. While in there: - Fix a typo in `PostVotingVoteControls#count` — it read `this.args.post_voting_vote_count` instead of `this.args.post.post_voting_vote_count`. The component only receives `@post` and `@showLogin`, so the original was always `undefined`. Cosmetic today (the getter is only read in the zero-vote branch where the value is always 0), but incorrect. - Extract the optimistic-update / rollback logic from `vote` and `removeVote` into a shared `#submitVote` helper. This also fixes a latent rollback bug: when the user switched direction (up → down or down → up) and the server rejected the vote, `vote` restored `post_voting_user_voted_direction` to `null` instead of the original direction, leaving the UI inconsistent. Adds an acceptance test for the local-click path, which was not previously covered. Ref - t/182181 |
||
|---|---|---|
| .. | ||
| javascripts/discourse | ||
| stylesheets/common | ||
