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.
Changed internals so trust levels are referred to with
TrustLevel[1], TrustLevel[2] etc.
This gives us much better flexibility naming trust levels, these names
are meant to be controlled by various communities.
- Replace implicit return code-system in Email::Receiver with proper exception system
- Update tests to check for exceptions instead
- Test the PollMailbox for expected failures
- Add proper email-handling of problematic emails
"
- Adds the advanced option to accept email from non-users per category email-address
- Adds tests covering the new feature
- Adds UI to configure this feature in the frontend
- allow the configuration of an inbox-email-address per category
- post emails to that email into that category instead of global
- Adds UI for configuration
- Adds Documentation for configuration
- Adds Tests for new feature
With the new email_in admin configuration setting, emails to the email_in_address fetched via POP will now be processed and posted as new topics to the forum.
With the email_in_min_trust you can control the trust level the user needs to have at least to be able to post an email as a new topic.
Also contains tests for the email-in feature and minor clean ups
