EDIT: I realized the comments about there not being a difference with :save already covered were correct, and was able to work through some errors. However, it still appears the regex validation is failing for :password.
I'm a little confused, and think the problem might be related to there being only :password_digest in the table itself, while we use password and password_confirmation as attributes in the model. But I'm also guessing Rails has this all worked out and takes care of everything with the has_secure_password function.
validates_format_of :password, :with => /\A[a-zA-Z]\z/, :on => :create, :update fails with the string password.
Obviously, this doesn't make sense and matches fine in the console (using =~ or .match(). Also notice if I set allow_nil: true for :password other tests involving the user start failing (which doesn't make sense, as the password should never be nil anyways).
I don't see any use case where you need on create and update together if on: :save is already there.
For more model callbacks please refer this.
According to rails docs
The default behavior for all the built-in validation helpers is to be run on save (both when you're creating a new record and when you're updating it). If you want to change it, you can use on: :create to run the validation only when a new record is created or on: :update to run the validation only when a record is updated.
So, you should not use :on option in your validation
Related
I have a form field in ROR 4 app called as 'measure'. It is not a database column, but its values will help model create child entries of its own via acts_as_tree : https://github.com/rails/acts_as_tree
I have to throw a validation when 'measure' is invalid. So I have created a virtual attribute known as measure and check for its validations only on a certain condition.
model someModel
attr_accessor :measure
validates_presence_of :measure, :if => condition?
Problem is when I am saving the code, I am thrown a validation which is fine. I am also thrown the same validation when I am trying to update the record in some other method of the model. The only way to surpass that is by writing this code:
# I do not want to do this, is there a better way?
self.measure = "someRandomvalue"
self.save
I am making this as virtual attribute only for throwing validations. Is there a better way of throwing validations? The form has other validations, I do not want the error for this validations to be shown differently just because it is not an attribute.
I want it to validated only when active record is saved via create and update action of the controller and not when it is being updated by some random method of model.
I have seen other developers in my team doing similar thing and was always curious about one thing - "What are you trying to achieve doing things the way you are doing?". You see, I am not sure if validators should be used for values that will not be serialized.
Anyways, you may try using format validator instead of presence, which worked in my team's case:
# Rails 3/4
validates :measure, format: { with: /^.+$/, allow_nil: true }
# Rails 2
validates_format_of :measure, :with => /^.+$/, :allow_nil => true
You may also try using allow_blank instead of allow_nil.
I would rather create a custom validator along the lines of validates_accessor_of for values that I know will never be serialized.
HTH
I'm migrating an app from rails 2.3 to rails 3. I'm planning on moving to heroku, so I'm also moving to postgres.
I have a model which has lots of fields - about 30. I want to validate the completion of all of these fields, except 2. In my rails 2 app I had:
validates_presence_of (self.column_names - ["id", "email_not_name"]), :on => :update
This worked, and in fact works in Rails3 as well. The problem comes when I try to run the migrations for the new database - I get the "PGError: ERROR: relation “table_name” does not exist" error described here. Not sure why this doesn't occur with SQLite3, but it doesn't really matter.
If I remove the validation, the migrations run fine - the problem is that none of the self.column_names actually exist yet. Similarly, if I change the migration to
validates_presence_of :field1, :field2, :on => :update
the migration will run without problems. Clearly, I could just list all 30 fields, but this strikes me as clumsy and not very maintainable. What I really want is:
validates :all, :except=>:email_not_name, :presence=>true, :on => :update
but unfortunately that doesn't actually exist! Is there a way that I can do this without resorting to this? (either rails2 or rails3 style)
Answer:
Ok, so for anyone who comes across this, here's how to do this. The solution is to create a custom error handler, called with:
validate :check_all_questions_completed, :on => :update
The error handler itself is:
def check_all_questions_completed
Person.column_names.each do |col|
if (Person.column_names - ["id", "email_not_name"]).include?(col) && send(col).nil?
errors.add(col)
end
aend
end
If anyone can tidy up my code, please do (the model concerned is Person)
i have a user model with a password attribute, which gets saved as password_digest.
What i want to do is have the edit user page and the edit password page separated, so that
the admin doesn't need to input the password everytime he needs to change something else. For this i have made an extra action / view.
My problem is that when i update the user info, i get password validation errors even though
i have no password field in the form. Which leads me to the conclusion that partial_updates isn't working with the password attribute (as i have already tested in the console that it is enabled, and it is)
Is this me doing something wrong, or should i approach this differently?
Similar to the railscasts approach mentioned by #normalocity, but without the need to set a pseudo-attribute in the controller, we do this (which is essentially taken from restful_authentication):
attr_accessor :password
validates :password,
:length => { :minimum => 8 },
:confirmation => true,
:presence => true,
:if => :password_required?
def password_required?
password_digest.blank? || !password.blank?
end
Basically, we assume that if the password_digest hasn't been set yet (for a new record), or if the password pseudo-attribute has been set, then that means the password is being changed and the validations have to be run. So we don't need to set a updating_password pseudo-attribute like they do in the railscasts episode.
You need to validate the password only if it's being changed. If it's not being changed, then the validation for the password field should be skipped.
Railscasts.com episode #41 shows you how to do this.
I'm trying to update single attribute of a user model from a admin controller (not users controller).
While doing this I tried update_attribute() but it was changing the users password also.
I think the password is changing because I have before_save method on user model which hashes the password.
update_attributes() is not working because it is checking the validations for password which is presence=>true
Is there any way to achieve this?
You can set a condition on your validations by using the :if option. In my code, it looks something like this:
validates :password,
:length => { :minimum => 8 },
:confirmation => true,
:presence => true,
:if => :password_required?
def password_required?
crypted_password.blank? || password.present?
end
So basically, it's only if the crypted_password in the database is not set (meaning a new record is being created) or if a new password is being provided that the validations are run.
Try update_column(name, value), it might work.
You can update single attribute of user like this
#user is that user whose attribute you want to update
e.g user_name
#user.update_attributes(:user_name => "federe")
Try it and it will only update one attribute..
ActiveRecord has an 'update-column' method that skips both validations and callbacks:
http://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-update_column
However, I'd suggest that could be dangerous - you have that :before_save filter for a reason. If you place an :except method on the filter to circumvent in specific cases, it not only becomes reusable but you keep behaviour consistent and avoid having a method buried in a controller that's bypassing your Model's validation/callback stack.
I'm personally not overly keen on seeing methods like update_column anywhere except as protected methods inside Models.
Try :
To bypass callback and validations use :
User.update_all({:field_name => value},{:id => 1})
Just wanted to let you know :
In Rails, update_attribute method bypasses model validations, while update_attributes and update_attributes! will fail (return false or raise an exception, respectively) if a record you are trying to save is not valid.
The difference between two is update_attribute use save(false) where as update_attributes uses save or you can say save(true) .
I've got a User model with three fields, :email, :display_name and :handle. Handle is created behind the scenes from the :display_name.
I'm using the following validations:
validates :display_name, :presence => :true, :uniqueness => { :message => "Sorry, another user has already chosen that name."}, :on => :update
validates :email, :presence => :true, :uniqueness => { :message => "An account with that email already exists." }
I use the handle as the to_param in the model. If the user fails the validation by submitting a :display_name that already exists, then tries to change it and resubmit the form, Rails seems to use the new handle as the validation for the email -- in other words, it assumes that the email doesn't belong to the current user and validation on the email then fails. At this point, Rails assumes that the changed display name/handle is the one to use for the look up and the update action can't complete at all, because it can't find the user based on the new handle.
Here's the update method:
def update
#user = User.find_by_handle(params[:id])
#handle = params[:user][:display_name]
#user.handle = #handle.parameterize
...
end
This problem doesn't happen when the validation first fails on a duplicate email, so I'm assuming it's something about the way I've written the update method -- maybe I should try setting the handle in the model?
maybe I should try setting the handle in the model?
^ This.
The controller isn't the place to do something like this. If it's model logic that's happening behind the scenes, beyond the user's control, why put it in controller code?
Do it instead in a before_save filter, which is guaranteed to run only after the chosen display name is determined to be available and the record is deemed valid. In this way the handle won't be changed on the cached record until it is actually committed to the db, eliminating the problem of the incorrectly generated URL.
before_save :generate_handle
...
def generate_handle
self.handle = display_name.parameterize
end