Set the href for notifications emitted through WS the same as in API

[skateman]

The notification mark/delete would might work without this, but it's better to have the same full href for the items as it would come from the API. I am not sure about the window.location.origin, maybe there's a better way, so pinging some JS-people for review.

Depends on: ManageIQ/manageiq#17875

@miq-bot add_reviewer @martinpovolny
@miq-bot add_reviewer @Hyperkid123
@miq-bot add_reviewer @karelhala
@miq-bot add_label pending core, bug

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1618705

[miq-bot]

Checked commit skateman@2c71a54 with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
0 files checked, 0 offenses detected
Everything looks fine. 🍪

[skateman]

@miq-bot rm_label pending core

[martinpovolny]

I think it's ok. Ping @Hyperkid123, @karelhala or @himdel ?

[Hyperkid123]

@skateman @martinpovolny i think it should work, but i'm not sure about support in IE. I will check it on Monday as soon as possible.

[Hyperkid123]

Its working

[himdel]

LGTM, but curious why we would actually need this?

All the other API accesses use relative urls, and I consider that a feature :).

EDIT: never mind, this is data, not the url that gets used

[himdel]

One more thing, according to https://developer.mozilla.org/en-US/docs/Web/API/Window/location#Browser_compatibility , window.location.origin is not supported in IE10.

[skateman]

AFAIK we support IE11 only

[himdel]

gaprindashvili/no, so.. it would make sense 👍

[skateman]

@himdel do we support IE10 in the G-release? I thought we dropped it way earlier...

[himdel]

I don't know for sure, sorry :(

[skateman]

@epwinchell says it was around fine or before, so it's safe to backport.
@miq-bot add_label gaprindashvili/yes
@miq-bot rm_label gaprindashvili/no