params.require(:person).permit(:projects_attributes) was returning
=> {"projects_attributes"=>{"0"=>{"name"=>"Project 1"}}}
When should return
=> {}
You should be doing ...
params.require(:person).permit(projects_attributes: :name)
to get just the projects attributes you want to allow
the documentation on #assert_template states that the :locals option is
only available in view test cases:
# In a view test case, you can also assert that specific locals are passed
# to partials:
I added a warning when it's passed in an inapropriate context to prevent
a NoMethodError.
Given Im rendering an template `/layout/hello.html.erb`, assert_template was
passing with any string that matches. This behavior allowed false passing like:
assert_template "layout"
assert_template "out/hello"
Now the passing possibilities are:
assert_template "layout/hello"
assert_template "hello"
fixing assert_template bug when template matches expected, but not ends with
Cherry Pick Merge: Fixes issue #3849 assert_template false positive
taking redundant test off
prevening incorrect assert_template when rendering with repeated names in path
updating CHANGELOG with bugfix: assert_template false passing
actionpack/test/template/spec_type_test.rb:32: warning: method redefined; discarding old test_spec_type_wont_match_non_space_characters
actionpack/test/controller/spec_type_test.rb:30: warning: previous definition of test_spec_type_wont_match_non_space_characters was here
It's further work on CSRF after 245941101b1ea00a9b1af613c20b0ee994a43946.
The :null_session CSRF protection method provide an empty session during
request processing but doesn't reset it completely (as :reset_session
does).
Many named routes have keys that are required to successfully resolve. If a key is left off like this:
<%= link_to 'user', user_path %>
This will produce an error like this:
No route matches {:action=>"show", :controller=>"users"}
Since we know that the :id is missing, we can add extra debugging information to the error message.
No route matches {:action=>"show", :controller=>"users"} missing required keys: [:id]
This will help new and seasoned developers look closer at their parameters. I've also subclassed the routing error to be clear that this error is a result of attempting to generate a url and not because the user is trying to visit a bad url.
While this may sound trivial this error message is misleading and confuses most developers. The important part isn't what's in the options its's what's missing. Adding this information to the error message will make debugging much more obvious.
This is the sister pull request of https://github.com/rails/journey/pull/44 which will be required to get they missing keys into the correct error message.
Example Development Error in Rails: http://cl.ly/image/3S0T0n1T3421
Methods provided by RecordIdentifier are not widely used in controllers
nowadays as they're view specific (this is probably a legacy left after
RJS rendering directly in controllers). However if people still need to
use it, it's trivial to include ActionView::RecordIdentifier by
themselves.
This is another step in moving Action View's dependencies in Action Pack
to Action View itself. Also, HtmlScanner seems to be better suited for
views rather than controllers.
Since it's more about DOM classes and ids it belongs to Action View
better. What's more, it's more convenient to make it part of Action View
to follow the rule that Action Pack can depend on Action View, but not
the other way round.
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
5ea6b0df9a
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
Rails includes a single character body to a head(:no_content) response to work around an old Safari bug where headers were ignored if no body sent.
This patch brings the behavior slightly closer to spec if :no_content/204 is explicity requested via a head only response.
Status comparison done on symbolic and numeric values
Not returning any content when responding with head and limited to a status code that explicitly states no content will be returned - 100..199, 204, 205, 304.
responses.
Processing controller actions in a separate thread allows us to work
around the rack api - we can allow the user to set status and headers,
then block until the first bytes are written. As soon as the first
bytes are written, the main thread can return the status, headers, and
(essentially) a queue for the body.
