New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the column_for_attribute deprecation warning for the last time #3930
Conversation
item.column_for_attribute(data) && | ||
item.column_for_attribute(data).type == :boolean | ||
if item.class.respond_to? :columns_hash | ||
column = item.class.columns_hash[data.to_s] and column.type == :boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line is too long. [81/80]
Use &&
instead of and
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line is too long. [81/80]
@timoschilling I'd prefer the maximum to be 90 or 100 characters. Do you have a strong opinion either way?
Use
&&
instead ofand
.
Heh, static code analysis can only understand so much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seanlinsley There was already a discussion about that in #3841. I think the 120 chars from #3841 are to much, but 90-100 could be ok. In the past I have seen 80 chars as a "soft limit", in cases where a code rewrite is ugly then a long line, I have preferred the long line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seanlinsley does the test covers the difference between &&
and and
? Not that some will change it and the test don't show it.
@seanlinsley , I think in case when item is decorated |
@seanlinsley your commit run's as a ActiveAdmin repo commit (continuous-integration/travis-ci/push) and as a PR commit (continuous-integration/travis-ci/pr). That's happens only if a ActiveAdmin contributor creates a PR from a ActiveAdmin branch. |
@Fivell that might be true, in which case we need more tests! |
@seanlinsley, I can add cucumber feature failing/or not here (https://github.com/activeadmin/activeadmin/blob/master/features/index/index_as_table.feature) if you need it |
@Fivell Are you still up for adding that failing test? |
@Fivell maybe you can continue the work on this PR? |
we couldn’t use `type_for_column` since: - it’s not intended as a public method and - it would return a null object if the column had the default value (nil) for example: ``` expected: "No" got: "" (compared using ==) (RSpec::Expectations::ExpectationNotMetError) ./features/step_definitions/table_steps.rb:96:in `assert_cells_match' ./features/step_definitions/table_steps.rb:79:in `block (2 levels) in assert_tables_match' ./features/step_definitions/table_steps.rb:75:in `each_index' ./features/step_definitions/table_steps.rb:75:in `block in assert_tables_match' ./features/step_definitions/table_steps.rb:74:in `each_index' ./features/step_definitions/table_steps.rb:74:in `assert_tables_match' ./features/step_definitions/table_steps.rb:115:in `/^I should see the "([^"]*)" table:$/' features/index/index_as_table.feature:252:in `Then I should see the "index_table_posts" table:' Failing Scenarios: cucumber features/index/index_as_table.feature:244 # Scenario: Sorting ```
fedccff
to
714b092
Compare
I'm working adding that test now.
It seems like we should make it so |
forced to fix them. This is one deprecation: >DEPRECATION WARNING: Using ActiveRecord's `find` on a CollectionDecorator is deprecated. Call `find` on a model, and then decorate the result. (called from block in add_default_batch_action at lib/active_admin/batch_actions/resource_extension.rb:73) (StandardError) This issue was introduced by #3775, which started decorating collections for batch actions. The Draper ticket that resulted in the deprecation is: drapergem/draper#509. The simple solution would be to no longer decorate the batch action collections, which is what this commit does.
Okay, this is ready for review. |
@seanlinsley , how do you think isn't it confusing when you're declaring decorator, you still have some places where it is decorated and some places where it isn't. However I have no idea too how to fix this stupid deprecation warning as well. |
It seems like the only way we could continue to decorate the collection is by doing the filtering for the user, which would be a breaking change. batch_action :archive do |collection|
collection.each{ |record| record.update archived: true }
end We might want to do that for AA 2.0, but for now I don't think we can support decoration. |
@seanlinsley , maybe we can introduce new specific method |
I don't think it makes sense to provide both A nice way to provide the new DSL without needing to deprecate anything would be to still pass the IDs as a block argument, but provide batch_action :archive do |ids|
ids == [1,2,3]
collection.is_a? Draper::CollectionDecorator # with filtering applied Is there a reason we would use |
@seanlinsley , sorry not clear for me how it helps |
What's the status of this PR? Does it solve the deprecation warning? Thanks. |
For other seeking for a solution until this is merged. I imported this in my code using a monkey patch, ugly but effective module ActiveAdmin
# Module used to define patches using Module#prepend
module Patches
# Original module
module Views
# Monkeypatch for https://github.com/activeadmin/activeadmin/pull/3930
module TableFor
protected
def is_boolean?(data, item)
if item.class.respond_to? :columns_hash
(column = item.class.columns_hash[data.to_s]) and column.type == :boolean
end
end
end
end
end
end
ActiveAdmin::Views::TableFor.prepend ActiveAdmin::Patches::Views::TableFor |
#3838
Turns out we couldn’t use
type_for_column
since:for example: