It used to validate the post from the perspective of the user who
created the post. That did not work well when an admin attempted to
add a poll to a post created by a user who cannot create posts because
it said the user cannot create polls.
The problem was that it used post.user for the validation process
instead of post.acting_user.
* DEV: Remove spec that we no longer need.
As far as we know, the migration has been successful for a number of
years.
* FIX: Validate number of votes allowed per poll per user.
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.
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.
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
This reduces chances of errors where consumers of strings mutate inputs
and reduces memory usage of the app.
Test suite passes now, but there may be some stuff left, so we will run
a few sites on a branch prior to merging
* FEATURE: introduces minimum trust level for polls
This commit makes `poll_enabled` less misleading and introduces `poll_minimum_trust_level_to_create`. If poll are enabled they will always be cooked, and if you have the required trust level you can create polls. As a side effect, it also fixes a bug where rebaking a post created by staff member when `poll_enabled=false` would end up not cooking it.
It also adds more tests to ensure settings are respected.
* admins should be whitelisted
* checks for admin in post validation
* test for >= instead of == trust level
* Extract validation logic into a service object.
* Extract logic for updating polls custom fields into a service object.
* Use `strip_heredoc` instead.
* FIX: Polls do not update when configuration has been changed.
Bianca Nenciu
Vinoth Kannan
Alan Guo Xiang Tan
Jarek Radosz
Kane York
Dan Ungureanu
Mark VanLandingham
Sam Saffron
Guo Xiang Tan
Régis Hanol
Gerhard Schlager
Joffrey JAFFEUX