• Sign In
  1. Messages

Populating returnUrl within the url metadata

LabKey Support Forum (Inactive)

View Message

view list print
Populating returnUrl within the url metadata Will Holtz  2016-03-10 14:44
Status: Closed
 
There are a fair number of places within Labkey where return URLs are passed via a returnUrl parameter within a URL. I'd like to use one of these URLs in a table metadata <url> field, but I don't see a good way to populate the returnUrl value. One option is to apply the metadata to an LABKEY.QueryWebPart via the config.metadata parameter. This seems a bit clunky to me. Is there any substitution that I can use for the current URL that would work in a resources/schemas/SCHEMANAME.xml file? I'm thinking of something along the lines of the ${contextPath}, ${containerPath} substitutions.

thanks!
-Will
 
 
Jon (LabKey DevOps) responded:  2016-03-17 18:52
Hi Will,

I was poking around the code, but it looks like we currently only have what we've documented here (which you're aware of):

https://www.labkey.org/home/Documentation/wiki-page.view?name=urlEncoding#sub

Can you give us a detailed example of what you'd like to see, so we can put this on the board for potentially a future feature?

Regards,

Jon
 
Will Holtz responded:  2016-03-17 21:30
Hello Jon,

Thanks for looking into this. I'd like to have a ${currentUrl} substitution that is replaced with the full URL of the displayed page, including URL parameters. Such that in a resources/schemas/SCHEMANAME.xml file I can write <url>http://www.example.com/labkey/query/home/foobar/detailsQueryRow.view?returnUrl=${currentUrl:uricomponent}</url>. For this example use case, a relative URL substitution would be sufficient, but I can imagine cases where the destination URL is external to Labkey and, therefore, an absolute URL is needed.

thanks,
-Will
 
Jon (LabKey DevOps) responded:  2016-03-18 07:48
Hi Will,

Thanks for the great example! I've submitted the feature request as the following bug ticket for tracking: https://www.labkey.org/issues/home/Developer/issues/details.view?issueId=25963

Regards,

Jon