| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\ \ \ \ \
| | | | | |
| | | | | | |
Fixed duplicating ActiveModel::Errors#details
|
| | | | | | |
|
|/ / / / / |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Minor style changes across the board. Changed an alias to an explicit
method declaration, since the alias will not be documented otherwise.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`ActiveModel::AttributesAssignment`
Allows to use it for any object as an includable module.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Add ActiveModel::Errors#codes
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
To be able to return type of validator, one can now call `details`
on Errors instance:
```ruby
class User < ActiveRecord::Base
validates :name, presence: true
end
```
```ruby
user = User.new; user.valid?; user.errors.details
=> {name: [{error: :blank}]}
```
|
|/ / / / / |
|
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When an attribute is assigned, we determine if it was already marked as
changed so we can determine if we need to clear the changes, or mark it
as changed. Since this only affects the `attributes_changed_by_setter`
hash, in-place changes are irrelevant to this process. Since calculating
in-place changes can be expensive, we can just skip it here.
I also added a test for the only edge case I could think of that would
be affected by this change.
|
|\ \ \ \
| | | | |
| | | | | |
allow '1' or true for acceptance validation.
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Add test for AM::Validation::Callbacks with :on
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`before_validation` and `after_validation` from
ActiveModel::Validation::Callbacks accept an optional `:on` parameter
that was not previously documented or tested. For instance given
before_validation :do_something, on: :create
then `object.valid?(:create)` will invoke `:do_something` while
`object.valid?` or `object.valid?(:anything_else)` will not.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
The method was introduced in https://github.com/rails/rails/commit/66d0a0153578ce760d822580c5b8c0b726042ac2#diff-8cec05860729a3851ceb756f4dd90370R49
for the "reset_changes is deprecated" test, but this test was successively
removed in https://github.com/rails/rails/commit/37175a24bd508e2983247ec5d011d57df836c743
|
|/ / /
| | |
| | |
| | | |
MassAssignmentSecurity was removed from ActiveModel f8c9a4d3e88181
|
| | |
| | |
| | |
| | | |
'_singularize' only ever gets called with one argument
|
| | |
| | |
| | |
| | | |
These requires were added only to change deprecation message
|
| | |
| | |
| | |
| | | |
`ActiveModel::Dirty#reset_changes`.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Introduce explicit way of halting callback chains by throwing :abort. Deprecate current implicit behavior of halting callback chains by returning `false` in apps ported to Rails 5.0. Completely remove that behavior in brand new Rails 5.0 apps.
Conflicts:
railties/CHANGELOG.md
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This stems from [a comment](rails#17227 (comment)) by @dhh.
In summary:
* New Rails 5.0 apps will not accept `return false` as a way to halt callback chains, and will not display a deprecation warning.
* Existing apps ported to Rails 5.0 will still accept `return false` as a way to halt callback chains, albeit with a deprecation warning.
For this purpose, this commit introduces a Rails configuration option:
```ruby
config.active_support.halt_callback_chains_on_return_false
```
For new Rails 5.0 apps, this option will be set to `false` by a new initializer
`config/initializers/callback_terminator.rb`:
```ruby
Rails.application.config.active_support.halt_callback_chains_on_return_false = false
```
For existing apps ported to Rails 5.0, the initializers above will not exist.
Even running `rake rails:update` will not create this initializer.
Since the default value of `halt_callback_chains_on_return_false` is set to
`true`, these apps will still accept `return true` as a way to halt callback
chains, displaying a deprecation warning.
Developers will be able to switch to the new behavior (and stop the warning)
by manually adding the line above to their `config/application.rb`.
A gist with the suggested release notes to add to Rails 5.0 after this
commit is available at https://gist.github.com/claudiob/614c59409fb7d11f2931
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before this commit, returning `false` in an ActiveModel `before_` callback
such as `before_create` would halt the callback chain.
After this commit, the behavior is deprecated: will still work until
the next release of Rails but will also display a deprecation warning.
The preferred way to halt a callback chain is to explicitly `throw(:abort)`.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before this commit, returning `false` in an ActiveModel validation
callback such as `before_validation` would halt the callback chain.
After this commit, the behavior is deprecated: will still work until
the next release of Rails but will also display a deprecation warning.
The preferred way to halt a callback chain is to explicitly `throw(:abort)`.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit changes arguments and default value of CallbackChain's :terminator
option.
After this commit, Chains of callbacks defined **without** an explicit
`:terminator` option will be halted as soon as a `before_` callback throws
`:abort`.
Chains of callbacks defined **with** a `:terminator` option will maintain their
existing behavior of halting as soon as a `before_` callback matches the
terminator's expectation. For instance, ActiveModel's callbacks will still
halt the chain when a `before_` callback returns `false`.
|
|\ \ \ \
| |/ / /
|/| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also prevents the word "Model" from linking to the documentation
of ActiveModel::Model because that's not intended.
[ci skip]
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Stems from [this comment](https://github.com/rails/rails/pull/18203#issuecomment-68138096) by @robin850
and by the blog post http://weblog.rubyonrails.org/2014/12/19/Rails-4-2-final
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Calling `changed_attributes` will ultimately check if every mutable
attribute has changed in place. Since this gets called whenever an
attribute is assigned, it's extremely slow. Instead, we can avoid this
calculation until we actually need it.
Fixes #18029
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The default value for the argument `message` in
`ActiveModel::Errors#add` has a new behavior
since ca99ab2481d44d67bc392d0ec1125ff1439e9f94.
Before
person.errors.add(:name, nil)
# => ["is invalid"]
After
person.errors.add(:name, nil)
# => [nil]
|
|/ / /
| | |
| | |
| | | |
- Changed test to verify complete message instead of verifying if message contains text.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This stems from https://github.com/rails/rails/pull/17227#discussion_r21641358
It's simply a clarification of the current behavior by which if an
`after_` or `around_` ActiveModel callback returns +false+, then the callback
chain **is not halted**.
The callback chain in ActiveModel is only halted when a `before_`
callback returns `false`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This stems from https://github.com/rails/rails/pull/17227#discussion_r21641358
It's simply a clarification of the current behavior by which if an
`after_validation` ActiveModel callback returns +false+, then further
`after_` callbacks **are not halted**.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm not sure what's the use case for this, but apparently it broke some apps.
Since it was not the intended result from #16210 I fixed it to not raise an
exception anymore. However, I didn't add documentation for it because I don't
know if this should be officially supported without knowing how it's meant to
be used.
In general, validations should be side-effect-free (other than adding to the
error message to `@errors`). Order-dependent validations seems like a bad idea.
Fixes #18002
|
| | |
| | |
| | |
| | |
| | |
| | | |
since 'attr_name_will_change!' is not an actual method it should
be clearer that you have to insert the attribute name as in line 104
[ci skip]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Active Record defines `attribute_method_suffix :?`. That suffix will
match any predicate method when the lookup occurs in Active Model. This
will make it incorrectly decide that `id_changed?` should not exist,
because it attempts to determine if the attribute `id_changed` is
present, rather than `id` with the `_changed?` suffix. Instead, we will
look for any correct match.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The detection of in-place changes caused a weird unexpected issue with
numericality validations. That validator (out of necessity) works on the
`_before_type_cast` version of the attribute, since on an `:integer`
type column, a non-numeric string would type cast to 0.
However, strings are mutable, and we changed strings to ensure that the
post type cast version of the attribute was a different instance than
the before type cast version (so the mutation detection can work
properly).
Even though strings are the only mutable type for which a numericality
validation makes sense, special casing strings would feel like a strange
change to make here. Instead, we can make the assumption that for all
mutable types, we should work on the post-type-cast version of the
attribute, since all cases which would return 0 for non-numeric strings
are immutable.
Fixes #17852
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[This article](http://weblog.rubyonrails.org/2014/8/20/Rails-4-2-beta1/#maintenance-consequences-and-rails-5-0) states that:
> Rails 5.0 is in most likelihood going to target Ruby 2.2.
Before the exact minimum version is fully decided, @arthurnn [suggests](https://github.com/rails/rails/pull/17830#issuecomment-64940383)
that **at least** version 2.1.0 **must** be required by the `gemspec` files.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We will support only Ruby >= 2.1.
But right now we don't accept pull requests with syntax changes to drop
support to Ruby 1.9.
|
| | |
| | |
| | |
| | |
| | | |
Commit d67b289 introduced a tiny regression in the docs for #from_json,
true needs to be included when the root node is present.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ActiveModel::Dirty#clear_attribute_changes method
In Rails 4.2 it is impossible to define a custom default value for a model's
attribute without making it appear as _changed?, especially when the model
is first initialized. Making this method publicly visible will allow such a behaviour,
without the need to use private APIs.
|
| | |
| | |
| | |
| | |
| | | |
This file was required inside 'test/validators/namespace/email_validator.rb'
that's already required here. Therefore I removed the redundant required.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch uniformizes warning messages. I used the most common style
already present in the code base:
* Capitalize the first word.
* End the message with a full stop.
* "Rails 5" instead of "Rails 5.0".
* Backticks for method names and inline code.
Also, converted a few long strings into the new heredoc convention.
|
| | |
| | |
| | |
| | | |
This will avoid naming clash with user defined methods
|
| | |
| | |
| | |
| | | |
Mirror Ruby's Hash#key?
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
justinweiss/update_validation_context_documentation
Docs: Add a note on custom validation contexts. [ci skip]
|