The bug was mentioned here: https://meta.discourse.org/t/poll-name/136436
I added specs to cover existing behaviour and refactored can_see_results method.
Guard condition should apply only if the poll result setting is set to `staff_only`.
In other cases, user can see results when the poll result setting is set to `always` or user voted or poll is closed.
They were relying on a pristine message bus, however current implementation
still uses redis, stuff can get held up and we can end up publishing
distributed cache messages in the middle invalidating the tests
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
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>
oga gem is automatically required by the aws gem
the oga gem retains about 1mb of memory, aws now uses nokogiri
This also removes the html normalize from the pretty text specs that was
a fair bit buggy as the polls test shows.
* 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
This adds the markdown.it engine to Discourse.
https://github.com/markdown-it/markdown-it
As the migration is going to take a while the new engine is default
disabled. To enable it you must change the hidden site setting:
enable_experimental_markdown_it.
This commit is a squash of many other commits, it also includes some
improvements to autospec (ability to run plugins), and a dev dependency
on the og gem for html normalization.
* 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.
Since rspec-rails 3, the default installation creates two helper files:
* `spec_helper.rb`
* `rails_helper.rb`
`spec_helper.rb` is intended as a way of running specs that do not
require Rails, whereas `rails_helper.rb` loads Rails (as Discourse's
current `spec_helper.rb` does).
For more information:
https://www.relishapp.com/rspec/rspec-rails/docs/upgrade#default-helper-files
In this commit, I've simply replaced all instances of `spec_helper` with
`rails_helper`, and renamed the original `spec_helper.rb`.
This brings the Discourse project closer to the standard usage of RSpec
in a Rails app.
At present, every spec relies on loading Rails, but there are likely
many that don't need to. In a future pull request, I hope to introduce a
separate, minimal `spec_helper.rb` which can be used in tests which
don't rely on Rails.
- add User.staff scope
- inject MessageBus into Ember views (so it can be used by the poll plugin)
- REFACTOR: use more accurate is_first_post? method instead of post_number == 1
- FEATURE: add support for JSON-typed custom fields
- FEATURE: allow plugins to add validation
- FEATURE: add post_custom_fields to PostSerializer
- FEATURE: allow plugins to whitelist post_custom_fields
- FIX: don't bump when post did not save successfully
- FEATURE: polls are supported in any post
- FEATURE: allow for multiple polls in the same post
- FEATURE: multiple choice polls
- FEATURE: rating polls
- FEATURE: new dialect allowing users to preview polls in the composer