[Bug-2419] Perspective URL Params do not update page on subsequent changes

Ignition
1

Updated our gateway to v8.1.5 the other day and since then passing parameters through a view URL seems to be broken. It was working prior to the update.

Anyone else seeing this issue?

Edit: Further testing indicates that the view loads from the URL correctly on the first load, but if the URL is changed to reflect a new param, this is not loaded.

2

We’re aware of this and have an internal ticket to address the issue.

3

Thanks, do you know which release will include a fix at this stage?

4

No, there is not ETA at this time.

5

This issue has been resolved and will be fixed in the 8.1.6 release.

2 Likes
6

I thought it was, but now we’re running 8.1.7 Nightly Build and having the same issue.

@Carl.Gould, did it reappear somewhere along the way in 8.1.7??

7

@Carl.Gould, @cmallonee, will this issue be looked at again when rolling 8.1.6 back?

8

Hmm, I don’t see any indication this actually made it into the 8.1.6 release.

Nevermind, hadn’t fetched upstream recently enough. Looks like it’s in 8.1.6 after all, and should be in some nightly release, so possibly a regression if anything.

9

I just performed a quick check of this behavior on the latest nightly and confirmed it is working as expected with a basic scenario.

10

So, is the new 8.1.7 LTS the same as the 8.1.7 Nightly Build? I see both on the download page. I’m assuming they are, and that the next nightly build will be 8.1.8…??

11

The “8.1.7 LTS Nightly” appears to be identical to the “8.1.7 LTS Stable” download as of this very second. Sometime today I expect we will update our internal systems to begin producing an 8.1.8 nightly.

1 Like
12

@cmallonee, the scenario I have is that the parameter being passed is then used in a Named Query to populate a 'Form'. Now, since the 8.1.6 regression, the only way I can make it work is to put

	import time
	time.sleep(1)

before the code (not desirable). If I don't, the resulting dataset from the named query has a getRowCount() of 0.

It seems like the view takes a moment to recognize the parameter that is passed.

Any ideas?

13

I guess it sort of depends on how this Named Query is being used.
This form that is being populated: is it populated via binding? Change script? Startup script?

If you’re using a binding, I would expect that binding to re-evaluate when the new value is supplied. If you’re using a change script, then this new value should also result in that code being executed again.
I could see how a startup script might not have the passed-in param because it might not have resolved yet.

1 Like
14

Yes, it’s a startup script.

15

Unfortunately I don’t think a script at that location will work for what you’re trying to do because the params may not have resolved. If you read the docstring for the PageStartup Event, concentrate on the page portion:

def onPageStartup(page):
	"""
	This event is fired when a new page is opened in a tab or window in a
	browser context.

	Arguments:
		page: A reference to the newly created page. Note that the other page
		      props will NOT return a valid value on page startup. The props that will
		      return a valid value are: 
			pageId (str): Identifier associated with the target page
			path (str): Represents the Page URL of the page. Example: / or /myPage
	"""
16

Ah, ok. That sheds some light on it.

Thanks @cmallonee! I’ll look at doing it a different way then, possibly a change script.

1 Like
17

Did this bug manage to creep back in?

I’m on 8.1.16 and the behaviour has regressed and is behaving exactly as was described in this post.

Was definitely working a few versions ago

18

I just checked our automated testing for that area and I do not see any failures. Could you provide some replication steps? Perhaps the automation follows a different route? The automation looks correct to me as it follows these steps to test this area:

  1. Use URL navigation to navigate to a page with three params delivered via the URL (system.perspective.navigate(url="GatewayIP:port/data/perspective/client/ProjectName/page/paramOne/paramTwo/paramThree", pageId=targetPageId)).
  2. Verify params arrived and were consumed as expected by observing three Labels display the three values.
  3. Use URL navigation for the same page, but with different param values in the URL (system.perspective.navigate(url="GatewayIP:port/data/perspective/client/ProjectName/page/paramTwo/paramThree/paramOne", pageId=targetPageId)).
  4. Verify params have been replaced with the new values by observing that the Labels now display the new values.
19

It might be related to how we’re using the parameter, in a startup script. Maybe it’s an unrelated change where the view doesn’t start up anymore on such a navigation.

I’ll try it in a change script rather and use a label to confirm tomorrow.

20

Works as you described.

I think the view no longer starts up when it only receives different parameters, hence me thinking it is a bug.

All is good.