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 #35762 - No host error after editing host's interfaces #9564

Merged
merged 1 commit into from
Feb 22, 2023
Merged

Fixes #35762 - No host error after editing host's interfaces #9564

merged 1 commit into from
Feb 22, 2023

Conversation

kmalyjur
Copy link
Contributor

@kmalyjur kmalyjur commented Dec 19, 2022

When editing the interfaces of an unmanaged host, this error occurred:
Screenshot from 2022-12-19 11-36-46

The issue was caused by the unmanaged host's primary interface name being shortname+domain; meanwhile, the same name of a managed host is just shortname.
Screenshot from 2022-12-19 12-16-24

This fix follows up the 3bc478f.

@theforeman-bot
Copy link
Member

Can one of the admins verify this patch?

2 similar comments
@theforeman-bot
Copy link
Member

Can one of the admins verify this patch?

@theforeman-bot
Copy link
Member

Can one of the admins verify this patch?

@theforeman-bot
Copy link
Member

Issues: #35762

@theforeman-bot theforeman-bot added Waiting on contributor Not yet reviewed Legacy JS PRs making changes in the legacy Javascript stack labels Dec 19, 2022
@MariaAga MariaAga self-assigned this Jan 3, 2023
Copy link
Member

@ofedoren ofedoren left a comment

Choose a reason for hiding this comment

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

Thanks, @kmalyjur!

I think the proper solution with these short/full names could be achieved after #9613 is merged and we agree on some united logic about the names for managed/unmanaged hosts.

But as for now, (a) simple workaround(s) will do. One suggestion inline makes the change smaller, but seems to fix the issue as well. It freaks me out I didn't notice it previously. Suggest to do more testing :/

UPD: Could you squash/remove commits related to rebasing? It breaks one of the checks for the bot.

@@ -247,7 +247,7 @@ def reports_show

def name_field(host)
return if host.name.blank?
host.managed? ? host.shortname : host.name
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need to touch this. Simple host_name_el.data('managed') === false removal will do.

Copy link
Contributor Author

@kmalyjur kmalyjur Feb 13, 2023

Choose a reason for hiding this comment

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

Thank you for your review!

You are right - this removal was not necessary. However, I want to let you know I made the change so that when editing the host, the name of the managed and unmanaged host is just the shortname - now it is shortname + domain when the host is unmanaged. But also, I am not sure in which form it should be, and it might be resolved after #9613 that you mentioned.

@@ -391,9 +391,7 @@ $(document).on('change', '.virtual', function() {
function construct_host_name() {
var host_name_el = $('#host_name')
var host_name = host_name_el.val();
if (host_name_el.data('appendDomainNameForHosts') === false ||
host_name_el.data('managed') === false
Copy link
Member

Choose a reason for hiding this comment

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

@MariaAga
Copy link
Member

@ofedoren is this pr waiting for some pr or changes?

@ofedoren
Copy link
Member

@MariaAga, this wait for me :) Currently re-checking this out.

Copy link
Member

@ofedoren ofedoren left a comment

Choose a reason for hiding this comment

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

Actually, I've retested this and the patch seems to fix the issue. Couldn't find any issue this patch could introduce, so let's get this in.

Thank you for bearing with me, @kmalyjur, merging.

@ofedoren ofedoren added Needs re-review Needs cherrypick This should be cherrypicked to the stable branches or branches labels Feb 22, 2023
@ofedoren
Copy link
Member

I'll re-run the tests just in case...

ok to test

@ofedoren ofedoren merged commit f13142e into theforeman:develop Feb 22, 2023
@ekohl
Copy link
Member

ekohl commented Feb 22, 2023

Late to the party, but there's actually a much more reliable fix: you can get the Location header from the response. The "new" host detail page should be the default, so there's no need to figure it out yourself.

I suppose the only edge case is when users opted out of the new detail page, but I doubt we need to cater to that.

Another solution is to use the ID instead of the FQDN since it's stable.

@kmalyjur
Copy link
Contributor Author

Hi @ekohl, thank you for your review. However, I don't get the part with the Location.
About using the ID - that's a great idea, but I think it would be good to create a new issue regarding that. I'm not sure how deep this fix would go.

@ofedoren ofedoren mentioned this pull request Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Legacy JS PRs making changes in the legacy Javascript stack Needs cherrypick This should be cherrypicked to the stable branches or branches Needs re-review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants