In particular, this applies:
- new `discourse/no-implicit-this` template-lint rule
- `init`/`willDestroy` ordering enforcement
- `lines-between-class-members`
Currently (for Ranked Choice only) a javascript exception is raised on very first vote, preventing the results from being rendered requiring a browser refresh (which doesn't error).
Resolves: TypeError: this.args.rankedChoiceOutcome.round_activity is undefined with simple addition of optional chaining operator.
Constants should always be only assigned once. The logical OR assignment
of a constant is a relic of the past before we used zeitwerk for
autoloading and had bugs where a file could be loaded twice resulting in
constant redefinition warnings.
This commit introduces a way to fetch the "serialized voters" for
multiple polls.
* Use a single query to fetch voters for all types of polls
* Refactor to introduce all_serialized_voters
* Cache serialized voters
`track_sql_queries` only returned queries that were executed by
ActiveRecord. All queries executed through DB.exec, DB.query and others
were not returned.
These fields are often used when serializing topics which may contain
multiple polls. On average, serializing a poll took 2+N queries where N
is the number of options. This change reduces the number of queries to
3, one for each field (Poll#voters_count, PollOption#voters_count and
Poll#has_voted?).
- Uses `helper.renderGlimmer` with GJS to render the `<Poll` component without any widgets
- Moves some logic into component, so that only `@post`, `@poll` and `@titleHTML` need to be passed into the component (no more 'attrs')
- Updates `modifyClass` calls to modern syntax
- Replaces observer in `Post` model with a native setter & tracked property
- Replaced Poll EmberObject instances with TrackedObject
- Updated component tests with new arguments
- Updated some tests to qunit-dom
- Fixed up core `repliesBelow` and `repliesAbove` logic to create post models properly. Previously it was passing 'transformed' versions of posts into the model, which doesn't make sense.
See: https://meta.discourse.org/t/cant-edit-topic-with-poll-bug-occurs/320845?u=merefield
When the Poll is set to "results ON_CLOSE", vote numbers for each option are only streamed to the browser when the vote is Closed. It is therefore not possible to render the Results.
The current issue is that when you refresh the page, for those that have voted the default view is results. For this type of poll this should NOT happen. The Results view in this mode should not be possible to see until closure, even for the Author.
Because the votes are not yet serialised when this kind of poll remains open, an attempt to display results causes a JavaScript exception and in any case does not make logical sense.
So the fix here is making sure the default view, for Polls that have results on close, is the voting view until the Poll is Closed.
I've added a test to cover this scenario.
Additionally, this requires a refresh of the page when the poll admin actions a Close to ensure the results are serialized in.
Initially, the poll results display a maximum of 25 voters per option. If the number of voters exceeds this limit, a button allows users to load additional pages of voters.
When this button is clicked, a method is called to retrieve the additional voter information. However, there was a bug where the local tracked object was not properly updated for ranked choice voters. This is due to the existence of two attributes per option: one indicating whether new data is currently loading, and the other containing the list of voters.
Instead of updating the entire option key with the voters list, the fix requires updating the voters attribute only.
This is a small but critical change. The pull request also includes a new test that significantly increases coverage, addressing this issue and beyond.
