Skip to content
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

Fixes #11767 - avoid cleaning of interface attributes #2713

Closed
wants to merge 1 commit into from

Conversation

ares
Copy link
Member

@ares ares commented Sep 14, 2015

This is alternative approach to fix #11767 which avoids removing params. It's covered by tests which I had to fix, they sent attributes that do not come from form. Also it's needed to use existing host during editing so NICs sent as nested attributes are correctly matched.

Before testing, please read 8405 and 9058 as well as 11767 and 11768 since they are all related and should be fixed by this patch.

@@ -546,7 +546,8 @@ def process_taxonomy
end

def template_used
host = Host.new(clean_interfaces_attributes.except(:host_parameters_attributes))
host = params[:id] ? Host.find(params[:id]) : Host.new
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the real host has an unfortunate side effect that calling attributes= below will immediate change relations such as Puppet classes. Try taking an existing host, load #edit, add a Puppet class to it and click Resolve, it'll get added in the DB.

(Setting WoC as the patch seems to hinge on this line, and it could cause a lot of problems.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not caused by attributes= but by puppetclass_ids=. In this case we don't need this (and other has_many associations) to resolve templates so we can ignore these. The view renders only the templates partial so form is not touched (unlike process_taxonomy action which renders the whole form). I added also config_group_ids which is part of params. To be more safe for associations added in future we could ignore all /.*_ids$/ keys, not sure if it's any better.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be more safe for associations added in future we could ignore all /.*_ids$/ keys, not sure if it's any better.

This might be safer in case plugins are involved - if the host form has been extended any to include nested attributes, then plugin authors aren't going to have much control over the .except() call in the line below. It might be safer for everybody to filter them out by default.

Would using .readonly help?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified to filter all *_ids paramteres and added extra comment about it.

Would using .readonly help?

No 😢, readonly seems to be effective only on the object itself, associations ignore it.

@domcleal
Copy link
Contributor

@ares could you rebase this please?

@ares
Copy link
Member Author

ares commented Sep 23, 2015

sure thing, rebased

@domcleal
Copy link
Contributor

Thanks. I've been going through the history and code and agree, this seems to resolve many of the related issues in a decent way.

Can I suggest adding a couple of expectations to those functional tests, which would fail if AR tried to make any changes to an associated object during what should be a no-op call?

ActiveRecord::Base.any_instance.expects(:destroy).never
ActiveRecord::Base.any_instance.expects(:save).never

These should be on all three tests for template_used and process_taxonomy.

@ares
Copy link
Member Author

ares commented Sep 25, 2015

Sounds as a good idea, added.

@@ -878,16 +878,20 @@ class Host::Valid < Host::Managed; end
end

test 'template_used returns templates with interfaces' do
ActiveRecord::Base.any_instance.expects(:destroy).never
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these will fail, they'll have to be lower than the host/NIC creation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well even if it wouldn't fail it's probably safer to stub just before xhr, thanks

@domcleal
Copy link
Contributor

Merged as 585329f, thanks @ares.

@domcleal domcleal closed this Sep 25, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants