Configuration of web link-to URL protocol/host#4744
Configuration of web link-to URL protocol/host#4744joshmoore merged 7 commits intoome:metadata52from
Conversation
| @@ -105,6 +105,8 @@ | |||
| $("#link_info_popup").show(); | |||
| {% if webclient_path %} | |||
There was a problem hiding this comment.
is it not enough to just delete that if?
There was a problem hiding this comment.
I've tested that briefly in ome/omero-mapr@7d911df
and it work http://10.0.51.133/web/mapannotations/gene/?show=map.value-tea1
There was a problem hiding this comment.
I kept it at first in case anyone wanted the old behaviour. If you're happy (as far as I know the Javascript below should work) I'll remove it.
There was a problem hiding this comment.
if you want to maintain the old logic then you need to keep request.build_absolute_uri(reverse('webindex')) rather then JS created link twice. The code below has no sense to me.
There was a problem hiding this comment.
From the previous discussion my impression was that we want to remove usage of build_absolute_uri
There was a problem hiding this comment.
@will-moore what was the logic behind https://github.com/openmicroscopy/openmicroscopy/blob/metadata52/components/tools/OmeroWeb/omeroweb/webclient/templates/webclient/annotations/metadata_general.html#L106 vs https://github.com/openmicroscopy/openmicroscopy/blob/metadata52/components/tools/OmeroWeb/omeroweb/webclient/templates/webclient/annotations/metadata_general.html#L109 At the moment we have both in place and we are wondering when else is used?
There was a problem hiding this comment.
From the previous discussion my impression was that we want to remove usage of build_absolute_uri
I agree, I was just a bit hesitant to do the full cleanup because I don't understand why the else is there. I'll remove it if no-one can see a reason for it.
This removes the need for another config property
|
@aleksandra-tarkowska Updated |
|
thx, but I think you also need to fix batch annotations. Why we need new property in a viewer then? |
|
The last commit changes batch-annotate to use client-side JS. The additional property |
This more accurately reflects how it's currently used (twitter and opengraph integration)
|
I've removed the |
|
looks good to me |
|
Merging for metadata52. I assume before hitting the mainline this will need a discussion re: the unification that's mentioned in the description as well as documentation on what all values may need to be set and kept in sync. (If this is the one end-all-be-all property, then likely a shorter name would be appropriate) |
|
Partially |
5 participants
What this PR does
The web metadata panel
Link to this <object>contains a server side URL created from the HTTPHostheader. This causes problems with server-side caching.locationobject, so that the/pathwill be cached but theprotocol://hostwill be handled by the client browseromero.web.ui.omero.web.ui.external_link_baseurl(this must include the protocol).Testing this PR
Link to this <object>in the web RH metadata panel. The URL should use whatever the browser has in the location bar, and in additional examination of the returned html such ashttp://host/webclient/metadata_details/image/ID/should showvar lnk = location.protocol + "//" + location.host + "/webclient/";instead of a URL.omero.web.ui.omero.web.ui.external_link_baseurl: If twitter or opengraph is enabled the html for the full image viewer should contain URLs with this value instead of the Host header.Related reading
Link to cards, tickets, other PRs:
Note
The only other place I'm aware of that let's you copy a link is in the full image viewer where it is already generated by client-side javascript: https://github.com/manics/openmicroscopy/blob/metadata52-linkto/components/tools/OmeroWeb/omeroweb/webgateway/templates/webgateway/viewport/omero_image.html#L665
This is unchanged, but maybe it should be unified?
Note: Description updated 2016-07-07