I don't see anything in the Session props that would indicate how many pages, or which ones are open in a browser.
Is this even possible? Perhaps by storing the Page ID in a custom.prop and if a new tab is opened, somehow check to see if the current path is active, then compare the Page ID to... maybe the Page ID would have to be a Session prop then, so it's viewable by the page?
Don't be fooled by page ID; in the Designer it is the resource path, but in a Session it is a unique 8 character string. There is no good mechanism for determining what "URL" a session page is using.
Your only avenue might be to enforce a stricter check that only one tab is open, thereby enforcing that there could be no duplicate page with the same URL.
Well, I haven't proved this out yet, but we had an issue where the numbers entered by the user were set to zero in a popup, but the rest of the information was correct. When I took a look at the workstation, there were four tabs open to the same page. What I didn't do was check to see what item was selected, if any, on the other three pages. If someone had selected an item off of another page (and each time an item is selected a popup appears), then another item is selected on another page, the defaults (maybe?) from the first popup might have overridden some of the values on the last popup.
That's my theory so far. And what's more interesting is that this workstation is in kiosk mode, so I am not sure how someone managed to open another page anyway... unless, the workstation was signed out during an OS update and someone signed in using a different login... hmmm.
Can you try and clarify this ? It seems you're trying to prevent something from happening by restricting pages, when there might be a different design that would get rid of the issue.
By selecting an item, I refer to clicking a table row which calls a popup view, passing some params. If this were to happen multiple times in a session, but the Submit button is clicked only once when the user completes their interaction, that's where I'm thinking the data gets "corrupted" so to speak. It's not the actual data the user input, but perhaps data from another instance of the popup. ?
Unfortunately, you're the only one who can tell us this. There are a thousand different potential reasons you could be getting "corrupted" data and they all relate to how you've implemented the project.
The likely causes are storing your Popup information in Tags or Session properties up until the submission event. Again, you're the only one who can diagnose if these are indeed the cause.
Doesn't prevent things happening in another tab, which is I believe what he's scared of.
@mdemaris You'll need to design your inputs and data storage so that it's not an issue.
How does everything work for now ? Can you maybe share the view ?
Which field(s) are actually giving "corrupted" data on submission?
One quick trouble-shooting step would be to place a button within that Popup which does nothing more than print out the values of the custom properties. Try opening this Popup in multiple tabs and see if you're getting unexpected values. Don't forget to modify some fields in other tabs before opening the Popup again in a different tab.
Also, it looks like your Designer has some of the custom properties set to be persistent, which means that the Popup will open with those same values you see in the Designer. If you don't want those values used as the default every time the Popup is opened, then you need to set the properties to not be persistent (right-click each property, then un-select the Persistent checkbox). The relevant properties from you script seem to be non-persistent, so this is likely not your issue.
I don't see anywhere that you're setting values to be 0, so I am confused as to where the 0 values could be coming from. Are these Text Fields, or Numeric Entry Fields? I don't believe Numeric Entry Fields allow for empty string values, and will always replace it with 0. Perhaps this is your issue? As you're dealing with numeric values, this seems likely.
This might be something you'll need to contact Support about, as the explanation/solution here is likely going to require an in-depth examination of the structure of the View, and potentially a real-time replication.
At least one alternate approach might help you:
If you want to enforce that only one instance of this Popup should be open for a given session, you can take control of managing its state yourself. This would require you do NOT use the default closeIcon (which you're already doing) and you instead provide your own button within the View for closing the Popup.
Your code for opening the Popup should check against a session property which tracks when the Popup has been opened
if not self.session.custom.addl_details_popup_open:
self.session.custom.addl_details_popup_open = True
system.perspective.openPopup("itemSignoutId","Page/inv/itemSignout_PU", params={"p_locid":self.props.selection.data[0].LocID}, showCloseIcon = False, resizable = True, modal = True)
The buttons which would CLOSE the Popup should set the session prop to false BEFORE closing the Popup:
One thing I noticed, if I open another browser, without logging out of the first browser, the session ID's are the same, and it does prevent opening the popup, however after the popup is closed, I cannot reopen it in the second browser.
Well, I cannot reproduce this phenomenon, so it may be a moot point.
Regarding this, the zero is auto-populated in the Numeric Entry Field, as I set the value to be empty, as in I deleted anything in the value prop. So this:
is TRUE.
There are no value.onChange scripts, so I believe that when I click Submit, 0 is the value applied to the numeric field or at least applied to the variable that is assigned to that field in the Submit script (above):
I'm glad you mentioned this as well, as there are two props that should not be persistent, though it does not seem to affect the operation of the of popup because they are bound to a query and or the results of the query.
It doesn't matter how many browser windows you open of the same browser, they will all share the same sessionId. If you open an incognito/private browser window, or a different browser, they will each get their own sessionId.