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
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?).
Cater for polls that can have multiple votes per user.
This fixes an older UserMerge and migration which was intended to
de-duplicate poll votes but did not account for "multiple" type polls.
When merging users, polls may error out if the source and target users have both voted on the same poll before. 😢
There is no constraint on the `poll_votes` table either to support this. Ideally a composite primary key can be used `(poll_id, user_id)`, but alas there is no support yet, which is probably why it wasn't created in the first place.
This fix ensures that merging is successful by only keeping the target poll votes if duplicates exist.
This fix also runs a migration on older poll votes where failed merges would have caused a single user to have voted twice on a single poll. e.g. this weird edge case
- Move the old '`define_include_method`' arg to a `respect_plugin_enabled` kwarg
- Introduce an `include_condition` kwarg which can be passed a lambda with inclusion logic. Lambda will be run via `instance_exec` in the context of the serializer instance
This is backwards compatible - old-style invocations will trigger a deprecation message
- Move the old '`define_include_method`' arg to a `respect_plugin_enabled` kwarg
- Introduce an `include_condition` kwarg which can be passed a lambda with inclusion logic. Lambda will be run via `instance_exec` in the context of the serializer instance
This is backwards compatible - old-style invocations will trigger a deprecation message
Update chat and poll plugins to new pattern
This is a much better description of its function. It performs idempotent normalization of a URL. If consumers truly need to `encode` a URL (including double-encoding of existing encoded entities), they can use the existing `.encode` method.
`poll` plugin was publishing on `/polls/[topic_id]` every time a non-first post was created. I can't imagine this being needed. It regressed 3 years ago in https://github.com/discourse/discourse/pull/6359
They can use the remove vote button or select the same option again for
single choice polls.
This commit refactor the plugin to properly organize code and make it
easier to follow.
The endpoint the existence of the poll and if the current user can see it. It
will facilitate using a poll programmatically, especially if we'd like to create an external poll through a theme component.
The warning was:
DEPRECATION WARNING: Calling `<<` to an ActiveModel::Errors message array in order to add an error is deprecated. Please call `ActiveModel::Errors#add` instead. (called from block (3 levels) in activate! at discourse/plugins/poll/plugin.rb:519)
Some plugins hook into Post after save to set custom fields and save again.
For example: https://github.com/discourse/discourse-category-experts/blob/main/lib/category_experts/post_handler.rb#L27
Problem is that in case like that `raw_changed?` is false but all callback are triggered. `extracted_polls` is class atribute therefore that should be reset with each attempt.
That was causing an error:
```
#<ActiveRecord::RecordNotUnique: PG::UniqueViolation: ERROR: duplicate key value violates unique constraint
"index_polls_on_post_id_and_name" DETAIL: Key (post_id, name)=(8967, poll) already exists.
```
Adds an optional title attribute to polls. The rationale for this addition is that polls themselves didn't contain context/question and relied on post body to explain them. That context wasn't always obvious (e.g. when there are multiple polls in a single post) or available (e.g. when you display the poll breakdown - you see the answers, but not the question)
As a side note, here's a word on how the poll plugin works:
> We have a markdown poll renderer, which we use in the builder UI and the composer preview, but… when you submit a post, raw markdown is cooked into html (twice), then we extract data from the generated html and save it to the database. When it's render time, we first display the cooked html poll, and then extract some data from that html, get the data from the post's JSON (and identify that poll using the extracted html stuff) to then render the poll using widgets and the JSON data.
The poll breakdown modal replaces the grouped pie charts feature.
Includes:
* MODAL: Untangle `onSelectPanel`
Previously modal-tab component would call on click the onSelectPanel callback with itself (modal-tab) as `this` which severely limited its usefulness. Now showModal binds the callback to its controller.
"The PR includes a fix/change to d-modal (b7f6ec6) that hasn't been extracted to a separate PR because it's not currently possible to test a change like this in abstract, i.e. with dynamically created controllers/components in tests. The percentage/count toggle test for the poll breakdown feature is essentially a test for that d-modal modification."
This required properly plumbing the guardian into the serializer.
Notably, the default state in the client was not changed - if you haven't voted in
the poll, you need to click the button to view the results instead of the results
being immediately visible on page load.
Implements https://meta.discourse.org/t/-/138108
Zeitwerk simplifies working with dependencies in dev and makes it easier reloading class chains.
We no longer need to use Rails "require_dependency" anywhere and instead can just use standard
Ruby patterns to require files.
This is a far reaching change and we expect some followups here.
Includes support for flags, reviewable users and queued posts, with REST API
backwards compatibility.
Co-Authored-By: romanrizzi <romanalejandro@gmail.com>
Co-Authored-By: jjaffeux <j.jaffeux@gmail.com>
