dashboardUrl error using two query parameters

Hi - I need help again :frowning:
I was using the dasboardUrl helper to construct a dashboard URL with two query parameters, and it was working fine until the last update to the platform (but not sure if that’s the exact timing it stopped working).
The issue seems to be that the helper, or somewhere in the background, the URL is getting constructed but the ampersand in the URL is getting ‘escaped’. So, it should look like this (truncated the ids in this example):

But is posted into the browser like this:

Note the amp; in the second example.
Removing the amp; from the URL corrects the issue and renders the dashboard correctly.

I have attempted to to add the encodeURI helper, but it continues to add amp; in the URL.

Any insight into this issue?

I haven’t been able to reproduce this issue so far; can you post an example of how you are using the {{dashboardUrl}} helper to get that result? As in …

{{dashboardUrl '1234...1234' ctx=(obj deviceId='789...987' gateway-0='999...111')}}

I have reduced the handlebar template down to a very simple expression, removing all of the other formatting, hardcoding in the ID’s, etc. So here is the basic template, it is in a row template of a custom column on a dashboard device list block:

{{dashboardUrl ‘1234…1234’ ctx=(obj gateway-0=‘789…987’ deviceId-0=‘111…999’)}}

On the resulting dashboard here is what is rendered (this works if pasted into a browser address bar):

But this is what the underlying url link is (note the amp;). :

It seems to be correctly building the url, with properly escaped characters for the “(” and other restricted http characters, but it is also swapping in the & amp; for the parameter separator “&”. (having trouble writing the “& amp;” with no space in this text, as the forum editor thinks I want just an & !)

Thanks, I see what you mean now. That’s a problem we’ll have to get fixed. I think it ties back to an upgrade to our Markdown parser from a couple months ago. I will keep you posted on a fix.

@Stephen_Earthy we just released a fix for this issue; if you check the block again from a full browser refresh, you should see the link without the double-encoded ampersands.

Thanks again for bringing this to our attention.

Yes! Works as it should.
Thank you for your quick attention to this!!
Cheers, Stephen