I don’t understand what you mean by fully fledged. My auto logout timer works 100% of the time and flawlessly. What advantage would we have?
Can you automatically close an ask question?
That’s different and would require different feature.
Doesn’t yours also rely on screen changes etc, so if you were to spend too long on entity screen creating new entity it wouldn’t log the typing etc?
The ask questions, messages and ?prompts was main one for me at the moment.
Dont know what to call that other than inactivity timer?
Also when I said fully fledged I meant that I was expecting the ask question etc would require new feature and that maybe that feature could be broadened to also serve as the trigger/timer for general inactivity not just completing ask questions etc.
Pretty sure I’ve worked out what was causing the occasional missed ticket on my PMS integration.
Thought it was change message but think its more likely the ticket tag prompt for covers…
[?Prompt] would be another one which would be handy to have a timeout for. Obviously not suitable in all situations but all my covers [?Prompts] have a default/preset value based on orders count of state course=main.
Obviously try to tell everyone to make sure then OK or change and set covers count but we all know staff dont always do exactly as asked 
I liked the idea of adding timeout to ask question screen as it is a certain step in flow and we can determine next step in case of inactivity. So I added two parameters to ask question action for setting timeout in seconds and command name that works when it timeouts.
I’m still uncertain about automatically submitting tickets due to inactivity. Ask question can be used for improving some cases but tickets should be submitted by tapping red close button.
3 Likes
Awesome
What about [?Prompt].
Can we work something in on that? I use it for covers tag and the default value is set based on course=main count, would be nice to set some form of timeout of the prompt function…
Am pretty sure this was what was keeping the ticket open if left on screen long enough to get missed by my pms sales scripting…
You’ll append (10)C at the end of config string to cancel prompt after 10 seconds.
1 Like
Sweet, so something like;
[?Table Covers;;[=TN(‘{TICKET ORDER QUANTITY TOTAL EXP:(OS.Kitchen Course=Mains)}’)];ON;(10)C]
Guessing C is cancel so would (10)O do OK after 10 seconds?
I think that will be custom keyboard setup so it should end with ON;;(10)C
Technically yes but… I can’t imagine a use case that fits.
Well cancel if I am thinking straight would remove the tag (well set as null).
Dont want that, and given the default value is propagated using [=TN(‘{TICKET ORDER QUANTITY TOTAL EXP:(OS.Kitchen Course=Mains)}’)], if it isnt changed it will timeout with the default value?
Does that make sense?
My plan wasnt just to close the ticket but to trigger the switch user/hold ticket flow with it so if ticket is left open it will;
Close - If no new orders
Hold - If there are new orders
Yes when there is a default value it makes sense. Also keep in mind this is not a real inactivity timer as moving mouse or typing stuff won’t pause timer.
1 Like
So what will happen if there are orders but stays on order tag selection or there is a half typed note, or… ?
Ok, thanks, was planning to set to like 60 secconds anyway.
My main aim was just to prevent the prompt being left up keeping the ticket open and making it get skipped from the PMS sales sync script which is based on close time - at least pretty sure this is the cause as increasing the script delay (time run to end range of ticket close search) has reduced the amount of times this has happened. Its wither this for the payment processed change amount message.
Depends on how you are able to implement.
I was hoping for a real inactivity where typing/mouse movement resets.
Also as above I was intending to set say 3-4 minutes, the main aim would be to prevent users logging on and just leaving it logged on mainly.
He mentioned it in a .60 beta update yesterday i believe.
1 Like