Auth / Lock Timeouts
We've been looking to rationalize the timeouts for external authentication as well as locking.
One thing we've brought up in a few channels (see Continued support for Extending Locks? ) was that an under-documented feature of LockManager.lock() before lockCache was that you could extend the lock window for a current lock. Assuming you had a really narrow window for lock timeouts, this might be a good thing.
We've done this by replacing desktop_restartTimeoutWarningTimer -- our new one works in much the same way, with some variations. We have seen success of this on Dev, though mixed results on QA with times of an hour. If we can get this working solidly, we could bring down the extension times to 20m, and thus mitigate the exposure of leaving items unlocked (due to failure to close).
There are some gaps in this implementation. We're counting on a desktop timer to track when server hits are made. So this needs to run when Ajax calls are made.
We've been looking to rationalize the timeouts for external authentication as well as locking.
One thing we've brought up in a few channels (see Continued support for Extending Locks? ) was that an under-documented feature of LockManager.lock() before lockCache was that you could extend the lock window for a current lock. Assuming you had a really narrow window for lock timeouts, this might be a good thing.
We've done this by replacing desktop_restartTimeoutWarningTimer -- our new one works in much the same way, with some variations. We have seen success of this on Dev, though mixed results on QA with times of an hour. If we can get this working solidly, we could bring down the extension times to 20m, and thus mitigate the exposure of leaving items unlocked (due to failure to close).
There are some gaps in this implementation. We're counting on a desktop timer to track when server hits are made. So this needs to run when Ajax calls are made.
This is where desktop_restartTimeoutWarningTimer is called, to reset the timer. We do see this called for Ajax requests. But we also see it running in some likely unforeseen places. For example, when using the standard event/action combo of Hover/Show smart tip, and the user does a mouseover here, the JS function stack will end up calling desktop_restartTimeoutWarningTimer. So this would effect our timeout warning for auth (and for locks).
Here's the generated HTML. It looks like showSmartTip could potentially call via Ajax, but in this case it reads it from somewhere in the DOM.
<span data-ctl='Text' data-hover='[["showSmartTip",[":event","","^~pyWorkPage.LeadForm.UserID~^"]]]' onmouseover = 'pega.c.cbe.processBehavior(event, "data-hover")' class='leftJustifyStyle' >
And the stacktrace -- from IE, I can't see how to copy the text, but I can copy the image here. As noted, we reassigned desktop_restartTimeoutWarningTimer to our own version here, where I put the breakpoint in.
The break happens when I hover over.
Added HTML & JS stacktrace.
[Updated by Jon Garfunkel on March 16th, to update the link to the related question/thread regarding lock extension]
Pegasystems Inc.
US
Hi Jon,
I see it's been a while without any response, I am wondering if maybe you provide a use case or restate the question in another way it might get a bump.
From a Pega perspective, I think there may be some confusion based on the fact there are already an SR and feedback item in regards to this issue.
Also, acknowledging this is the early days of the pilot, this is exactly the kind of discussion I would expect to get active responses from other active members that are not Pega employees. We are working to pull in more members such as this for the pilot.
BNY Mellon
US
Granted, I did post this on Friday afternoon... It's only Monday morning now!
I was meaning to update this with the JS stacktrace to help it.
It is a bit of an obscure problem, indeed. I didn't expect an answer right away. But I'll add, one benefit of a social/searchable system like this is that it's friendlier to "cold cases" -- it's at least now in the system to make it easier for someone to search for. In addition, there's a small chance somebody just can recognize this problem from what I described, and report that it's fixed in a future ML.
One other hindrance to filing this as an SR is that we've gone ahead and overridden the Pega function (which is legal in Javascript). We do have an application/environment where the OOTB desktop_restartTimeoutWarningTimer is used, so we could reproduce it, so I can see if it happens there.
Not to worry, I will post some more straightforward questions!
Pegasystems Inc.
US
Hi John,
If you have found part of scripting layer that is incorrectly calling desktop_restartTimeoutWarningTimer I would like to know about that. It should only call that function when there is any call to the server. For hover and smart prompt if there is a request to PRPC to get the content to display then the function needs get called. However, if we moved certain functionally like this to be completely client side and didn't remove the call to restart the timer then we need too.
I am not worried about you overriding the function. When it comes to using the pxSessionTimer we usually override that function anyway to call custom processing that meets specific client requirements for idle timeouts.
If you can get the Javascript trace that will be helpfull.
BNY Mellon
US
I updated the original question with the Javascript trace.
On the larger point, we do want to bring our improvisations on the timeout behavior in line with yours in the future. I had alluded to those in the SR's above, but this is where using Mesh to hash it out will be instructive -- and constructive, I hope -- for all parties.