Wrong options_for_assocation_conditions behavior

[GoogleCodeExporter]

What steps will reproduce the problem?
1. We have models: Batch, Invoice and Item
2. Batch has_many Invoices and Items
3. Items and Invoices separately belongs to Batch (both Items and Invoices have 
batch_id column)
4. In ItemsHelper we put 

options_for_association_conditions(assoc)
  if assoc.name == :batch
    puts @record
  end
end

What is the expected output? What do you see instead?

@record should be listed only when I am working with Item record. However 
somehow options_for_association_conditions of ItemsHelper are called also when 
I am working with Invoice record.

I believe this should not be the right behavior.

Original issue reported on code.google.com by shara...@gmail.com on 13 Jul 2010 at 9:54

[GoogleCodeExporter]

Also when I call columns[:product].update = [:batch] inside ItemsController, 
everytime I change Product value inside Items form, Batch column updates also 
inside Invoices form - parent

Original comment by shara...@gmail.com on 13 Jul 2010 at 10:09

[GoogleCodeExporter]

Add explaining screenshot to better understand `update` field problem.

Original comment by shara...@gmail.com on 13 Jul 2010 at 2:25

Attachments:

• Screenshot-1.png

[GoogleCodeExporter]

Changed parent model assocation to `batch_no` instead of `batch`. Now I get an 
JS error: TypeError: $("record_batch_") is null

Original comment by shara...@gmail.com on 13 Jul 2010 at 5:37

[GoogleCodeExporter]

After some debugging and brain exertion, I came with solution for this problem.

Just needed to change one single variable (In 
"lib/active_scaffold/helpers/form_column_helpers.rb" 
javascript_for_update_column)
FROM:
url_params[:scope] = params[:scope] || scope
TO: 
url_params[:scope] = scope || scope

params[:scope] seems to be empty most of the time in this method.

And here is as_overrides.rb for people who encounters same problem:

module ActiveScaffold
  module Helpers
    module FormColumnHelpers
      def javascript_for_update_column(column, scope, options)
        if column.update_column
          form_action = :create
          form_action = :update if params[:action] == 'edit'
          url_params = {:action => 'render_field', :id => params[:id], :column => column.name, :update_column => column.update_column}
          url_params[:eid] = params[:eid] if params[:eid]
          url_params[:controller] = controller.class.active_scaffold_controller_for(@record.class).controller_path if scope
          url_params[:scope] = scope if scope 
          #url_params[:scope] = params[:scope] if scope # Was this, but params[:scope] seem to be always empty in this method
          ajax_options = {:method => :get, 
                          :url => url_for(url_params), :with => column.send_form_on_update_column ? "Form.serialize(this.form)" : "'value=' + this.value",
                          :after => "$('#{loading_indicator_id(:action => :render_field, :id => params[:id])}').style.visibility = 'visible'; Form.disable('#{element_form_id(:action => form_action)}');",
                          :complete => "$('#{loading_indicator_id(:action => :render_field, :id => params[:id])}').style.visibility = 'hidden'; Form.enable('#{element_form_id(:action => form_action)}');"}
          options[:onchange] = "#{remote_function(ajax_options)};#{options[:onchange]}"
        end
        options
      end
    end
  end
end

Original comment by shara...@gmail.com on 17 Jul 2010 at 8:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

params[:scope] should be filled when render_field action is requested, don't 
you get params[:scope] in your render_action request?

About your conditions for association issue, in a form for batch with items and 
invoices subforms, only methods from BatchesHelper will be used, unless you 
have helper :all in your application controller. You can test 
"@record.is_a?(Item) && assoc.name == :batch"

Another time submit one issue for each problem.

Original comment by sergio.c...@gmail.com on 19 Jul 2010 at 7:07

[GoogleCodeExporter]

Nope, I do not get params[:scope] (maybe it is blacklisted param in AS?). I 
spent great deal of time trying to find in AS where things get wrong.

Situation with helpers is clear for me at the moment. However, maybe it would 
be better to call helper override methods also using class names, because if 
you have few separate models working in one window and these models have fields 
which have same names and you write a form or condition override method, then 
it applies to both fields, and this leads to pain and you have to rename 
columns. (Experienced this exact situation)

Sorry for mixing things up. 

Original comment by shara...@gmail.com on 20 Jul 2010 at 7:07

[GoogleCodeExporter]

I will improve naming of helper overrides if it's possible without breaking 
backwards compatibility.

A recent fix introduced a bug with render_field and fields with scope, 
params[:scope] shouldn't be used. I was confused because the line is 
url_options[:scope] = params[:scope] if scope, not url_options[:scope] = 
params[:scope] || scope. We need much more tests to avoid these issues.

It's fixed now

Original comment by sergio.c...@gmail.com on 21 Jul 2010 at 8:15

• Changed state: Fixed