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
resource.record nil in a field block (association) #2544
Comments
Hello @jetienne is that happening on index? |
@Paul-Bob I just updated the issue |
Can you please confirm if |
We fixed a bug where I think if you do field :state, as: :badge, options: {
info: 'sent',
success: 'accepted',
danger: 'refused'
}, name: '', visible: lambda {
puts ["resource.record->", resource.record].inspect
resource.record.state.in?(%w[accepted refused])
}
|
@Paul-Bob record fails also, being nil |
@jetienne can you confirm the |
@Paul-Bob If i have 2 proposals in my deal, this is the log
|
And on field :state, as: :badge, options: {
info: 'sent',
success: 'accepted',
danger: 'refused'
}, name: '', visible: lambda {
puts ["resource.record->", resource&.record].inspect
# resource.record.state.in?(%w[accepted refused])
true
} I'm trying to replicate it on my side but if you can check this one on same conditions would be helpful |
|
@Paul-Bob It seems that for 2 items, it's being called 3 items, the first one on a nil proposal (in my case) |
Yes, first call is to render header. On header Avo fetches fields from the resource in order to know the columns to print. Then the block gets evaluated again for each row (record in particular). Notice that 2nd and 3rd logs are the calls for each row. The first one (header) since is a index render, the resource has no record. Previous, on versions lower than Hope it makes sense, let me know if something still unclear |
Why would you call it for the header? The header is not a resource, it's purely decorative. |
Moreover, it means that from 3.4.2, we need to review ALL the field visible blocks like field :pending_email, as: :text, protocol: :mailto,
name: 'Pending Email Verification', visible: -> { resource.record.user.present? && resource.record.user.unconfirmed_email.present? } do
record.user.unconfirmed_email if record.user.present?
end when it was smoothly managed before. |
If fields visibility is not checked for header a filed like this would be rendered anyway on the header field :name, as: :text, visible: -> { !view.index? } The ability to hide columns on index is necessary
This is consequence of a bug fix, not ideal I know
Was not breaking but if the visible block of the last record of t he table was returning |
Thanks for the clarifications, can we be noticed on the release notes when there are such breaking changes? |
Yes @jetienne of course. We add all the known breaking changes to update section, just updated with this one, didn't realize it before. Thank you for reporting it! |
Describe the bug
Upgrade from 3.4.1 to 3.4.2 broke the following code, the resource record is always nil.
The exception is
undefined method
state' for nil`.By just replacing 3.4.1 to 3.4.2 in the same environment (just reloading the page) it fails.
Our models are
Deal
has_manyProposal
and it fails on a deals#show with has_many :proposals having the field state.We had to revert our production because of this bug.
System configuration
Avo version:
3.4.2
Rails version:
7.1.3.2
Ruby version:
3.3.0
License type:
Are you using Avo monkey patches, overriding views or view components?
Impact
Urgency
(we cannot upgrade until it's fixed).
The text was updated successfully, but these errors were encountered: