We have a requirement here that if a user changes mid-process he should first be sent to a screen where he needs to acknowledge some safety related information. Is there any way I could possible accomplish such behavior given the current toolset?
Best I could come up with until now was either
a validation check on the base template “on step enter” trigger,
by defining a validation in a timed trigger - by default this would be only after 30sec, or
via a custom widget which does what the timed trigger does but in shorter cycles, e.g. 1 sec…
Neither workaround is exactly ideal because even with a 1 sec cycle time, the user could theoretically still trigger an action in the app.
Depending on where that is occurring there is a small chance that the user validation will occur too late and hence the app will jump to the information step at the worst possible time from which it cannot recover after the user has confirmed the security notices.
I am essentially looking for an “on user changed” or “on user login” event…
…
This is all seen in the context of a shift change mid-process.
You could maintain a table of the currently logged in user. Use “create or update” using the station name in the table ID and add a User column to the table.
When someone logs in (on App entry) or on exit, write to the table with the user.
When the next operator logs in, load the record for that station, and check if the App Info Current User is the same as the table record.
I already thought I had missed something and it was maybe just a naming thing, but no… the “on app entry” trigger will only fire when an app is initially loaded for the first time at a station. Just tried it again to be sure.
If the user changes mid-way, that trigger is not fired again. Hence, there is no way to detect a change other than storing the user name when the app is first initialized, and then in regular intervals checking against this stored “LASt KNOWN USER” whether some change has occured mid-process.
We have gone the Custom Interval Widget route for now with a trigger event that is firing every 500ms and only if a certain variable is set. That way we can control when the user change monitoring is enforced and when not.
So far we have not noticed any significant performance penalty. This is certainly not ideal, but at least in reduced the likelihood that the user has a chance to rush ahead.
Having a native trigger would alleviate that polling.
I should probably add, that it looks like the Tulip Platform has some trigger throttling going on… so despite the widget firing every 500ms it seems the corresponding triggers only get executed every 1sec which seems to be the lowest possible interval… I hope this can still be relaxed… 1 sec is enough for an operator to find its way to the next step which could potentially cause havoc if not properly accounted for.
Execution time of the check performed with each trigger execution is reported as being somewhere between 2-8ms…
@sebme – what are you running on the trigger that’s being fired by the custom widget? If it takes > 500ms to respond, that might be why the timing feels off?
I think you can also use Custom Widgets to fire a trigger whenever the user changes, instead of having to poll. Here’s a quick demo of the exported CW and how it would be hooked up in the app editor. Just set the prop to be the current user & you can get a notification whenever that changes
