This change both speeds up specs (less strings to allocate) and helps catch
cases where methods in Discourse are mutating inputs.
Overall we will be migrating everything to use #frozen_string_literal: true
it will take a while, but this is the first and safest move in this direction
This feature can be enabled by choosing a destination for the
`shared drafts category` site setting.
* Staff members can create shared drafts, choosing a destination
category for the topic when it is published.
* Shared Drafts can be viewed in their category, or above the
topic list for the destination category where it will end up.
* When the shared draft is ready, it can be published to the
appropriate category by clicking a button on the topic view.
* When published, Drafts change their timestamps to the current
time, and any edits to the original post are removed.
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.
- Change the icon on the button to a file when attachments are enabled
- Display the list of allowed extensions in the upload selector
- FIX : regexps for validating uploads weren't escaping the dots
The spec contained an order dependency which would cause the default
bool test to fail. You can confirm this by running the spec with the
option "--order rand" a couple times. This dependency was caused by
surprising behavior in SiteSetting::setting as shown below:
SiteSetting.setting(:bool_setting?, false)
SiteSetting.refresh!
SiteSetting.bool_setting? #=> false
SiteSetting.random_setting = true
SiteSetting.bool_setting? #=> true
SiteSetting.setting(:bool_setting?, false)
SiteSetting.refresh!
SiteSetting.bool_setting? #=> true!
The spec is merely desriptive, and I have labeled what I think could be
possible bugs.
