I am upgrading old rails 2 app to rails 4. There are some code written in the model for creating like
create(activated: true, sita_code: MULTIPROPERTY.downcase,
access_list: MULTIPROPERTY.downcase)
I know we add permit parameters on controllers but I am getting this issue on model. How can I solve this
If you are working with Rails < 4.2, you might need to declare all the attributes under the corresponding model. So for about answer will be
attr_accessible :activated, :sita_code, :access_list
Related
I’m upgrading an app from Rails 4.2 to Rails 6. One of the models has this
class Document < ActiveRecord::Base
…
skip_callback :save, :before, :store_document!, if: :skip_processing?
When upgrading to 6, the “:store_document!” throws an error “”, which was not thrown in the older Rails version. “store_document” is not a method I have defined anywhere, so I’m assuming this is some kind of Rails shorthand for something. My question is what does the “store_xxx!” Do and how can I reproduce that in Rails 6?
this is the store accessor in Active Record
the usage of which is described here
Looks like the arguments for it changed in Rails 6 to
store_accessor(store_attribute, *keys, prefix: nil, suffix: nil)
so my bet is you have a
store :document
statement somewhere that needs to be updated to the proper syntax.
I have a rails engine which encapsulates a piece of my application's funtionality. I have a bunch of models in the engine, which have various belongs_to associations defined. As of rails 5 these associations are supposed to be required by default, unless optional: true is specified in the definition.
I’m still able to create instances of the models without any validation errors. I haven’t specified optional: true on any of the associations, nor is the config optionconfig.active_record.belongs_to_required_by_default set anywhere. Besides, it was removed in rails 6 anyway.
I can't think of any reason the model instances would not fail validation. I would expect any instances of any model with an undefined belongs_to association would be invalid and raise an error. Why would these records pass validation?
I found my problem, thanks to #MatthiasWinkelmann for the tip. It turns out my engine was not calling load_defaults at all. I needed to add the following to spec/dummy/config/application.rb:
module Dummy
class Application < Rails::Application
config.load_defaults Rails::VERSION::STRING.to_f
... etc ....
end
end
here is an article containing more explanation:
An upgraded Rails gem does not upgrade your Rails configuration
I probably would have done better to mention in my question that I'm in the process of upgrading my application from Rails 4.2 to 6.1. The change was introduced in Rails 5.
I'm working on upgrading a Ruby 2.2.2 (Rails 4.1) app to Ruby 2.5.7 (Rails 5.2) and for a couple of models I'm getting some errors
From searching around, it sounds like there are some generic activerecord validation rules / messages? The messages are:
Status is invalid
User is invalid`
I am a novice at best with Ruby - so any suggestions on the best way to work through this error are appreciated!
In Rails 5, whenever a belongs_to association is defined, it is required to have the associated record present by default. That means, compared to Rails 4, each belongs_to :foo association basically adds internally a validate :foo, presence: true to the code too.
You have two choices:
Follow the new Ruby on Rails conventions and fix your tests by adding all required associated objects to the models.
Switch back to the old behavior for these kinds of associations by adding , optional: true to each belongs_to :foo line in your code.
There is actually the third option to switch off this behavior in the whole application, by adding a line like this to your application.rb
Rails.application.config.active_record.belongs_to_required_by_default = true
But that means your application will not follow Ruby on Rails conventions and defaults anymore and IMHO this ofter leads to problems with a later update.
Therefore my advice is: Fix your tests now and only make those associations optional that are really optional from the user's point of view – this might take a bit longer but causes certainly less trouble in the future.
I am upgrading from Rails 3.2 to 4.2 and wanted to follow Ryan Bates' advice of getting things working as quickly as possible before doing any major refactoring.
To that end, I installed the protected_attributes gem because I was under the impression that with this gem installed I wouldn't need to implement the strong params approach in my controllers immediately and could continue using attr_accessible in the models until I have time to refactor.
I'm not getting any errors about attr_accessible itself, but when I try to create a user in development I get Unpermitted parameters: first_name, last_name, phone despite having all of those as arguments in the User model's attr_accessible method.
Can someone point out what I'm doing wrong here?
That's not the correct approach. Instead of porting a legacy, deprecated feature from 3.2 to 4.2, what you really want to do instead is the opposite: install strong_parameters gem in Rails 3.2 and make sure to replace the attr_accessible before the upgrade.
Rails 4.x is not really designed to use protected attributes anymore, therefore you will encounter a lot of issues trying to reintroduce it.
To use strong params you will have to update your controller's code (which is what I recommend to do, since it won't cost too much work).
In general the implementation of using strong_parameters is as follows:
def create
#model = Model.create(model_params)
if #model.persisted?
# logic
else
#logic
end
end
private
def model_params
params.require(:model).permit(:model_attrbite1, :model_attribute2)
end
I'm updating an old rails 2 app to rails 4. In the view there is a form field defined like this:
school[existing_address_attributes][666][city]
The model is updated as normal in the controller:
#school.update_attributes(params[:school])
The form works, and submits and saves properly, but I can't tell where existing_address_attributes is defined.
This seems to work similarly to nested attributes. Is this native to rails? Is it some gem? What am I missing?
This is most probably defined by accepts_nested_attributes_for. Check the Rails 2 documentation.