Fix bad url in notification email


When someone makes a request, the url to the request in the confirmation email is broken. I assume there’s a template or something to edit to fix this? (see text of email below) I can’t find anything when I search the docs. Can someone point me in the right direction? (I also think I’ll need to edit the link in the approver’s email.)


Current email with broken url:


Please review your Instance Request and wait for approval from an Administrator.

To view this Request go to : https://manage_iq_node-02/miq_request/show/130

Thank you
Cloud Support Team

I fixed this by making change to the notification space

Changed vm_href def code in

def vm_href
uri = URI(vm.show_url) = “
@vm_href ||= uri.to_s

Hi @michaelbutak, this sounds like a bug in the automation code. Can you please open a bug issue in ?

@Fryguy, I’d be glad to open a bug issue. What specifically in my question do you think is a bug? That it’s giving this non-https, non-load-balanced url?

@IMD do you know if one needs to cycle the ManageIQ process after updating the datastore model? I have edited the body field in the System/Notification/Email/ CloudMiqProvisionRequestRequesterPending instance and now it simply doesn’t send an email at all when I submit a request.

I changed:

a href=${/#miq_request.show_url}>${/#miq_request.show_url}</a>


a href="">click here</a>.

Perhaps there’s something syntactically unacceptable about that change? Where would I find an error message?

I also tried restoring the original content in the body field, but it still doesn’t send an email. I also tried removing my copy of the /System/Notification namespace and it’s classes and instances altogether, but it still doesn’t send an email when I submit a request. Then I tried re-copying the class and instance afresh from the locked domain. Still no email. This makes me wonder if one must cycle the application process for changes to take effect?

@michaelbutak I was under the impression that the existing link went to a non-existent route in the application. However, if it is an issue with the domain portion of the app that’s something different. I thought there was a setting in the application where you can set the externally facing hostname, so that URL generation works properly (it might be under the gear icon right on the first Settings screen).

@tinaafitz Do you know why @michaelbutak’s changes aren’t working however?

1 Like

@Fryguy sorry to confuse. Yeah my wording was pretty unclear in my initial post when I said the url was “broken”. I should have said, it takes the user to a specific node instead of the load-balanced domain name. Since it’s not https, it throws security errors, which to an approver would look like something is really messed up.

Thanks for the tip about changing the externally facing hostname. I’ll investigate that!

@IMD and @Fryguy, in case you are interested, I found out that there is a custom automation module in our edited domain written by some contractors (who set up our MIQ appliance initially and instituted some custom logic for us) that now drives the email content. I still have to figure out why removing my custom version of the out-of-the-box System/Notification/Email code doesn’t cause the tool to revert to the previous behavior (i.e., why it has stopped sending emails altogether), but at least I know the right location in which to make the fix.