Server/waitress auto logout tweaking

OK for the role of server people, I have it set to ‘log out user’ after they submit a ticket.
This way another server can log in and put in their items. This helps keep track of sales.
We wanted it this way to mimic the older system.

However as a server if I go back into a table to Add Ticket, I am immediately logged out.

What tweaks or constraints do I need to ask to fix that?


How do you mean go back into a table? After logging back in you mean?
I use the logout action rather than terminal autologout option for a few reasons but I think you are best to use a split flow using an execute automation command set to background=true to the loutout automation command rule in order to ensure ALL and ANY other automation is allowed to complete before actually logging out.
There was a issue a while back with using autologout like you have is there were other automation on same event which cause a * user loging (userless login as samba got forced/tricked into logging back in as part of the automation. I beleive this was fixed to prefent this happening however I still use a background automation command ‘flow break’ to ensure everything gets closed and updated as it should before actually logging out.

Logged in as an admin it doesnt do this to me. So its possibly its a role that I need to tick.

First of all this is how it is currently working.
Server enters pin, presented with table screens. Picks a table enters food and drink items. Taps on close, auto logout occurs, tickets go to bar and kitchen. Server walks off tends to other duties.

That table has a late guest arrives and that guess wants a separate ticket at that table. No problem, server goes back to pos, enters pin, logs in, taps on the table and this is what SHOULD HAPPEN. Click on ADD TICKET, enter new items, send to kitcken, auto logout.

HOWEVER what is happening is, as soon as the server taps on Add Ticket, boom she is logged out. If you log back in, its at the screen ready to add items to the ticket as intended.

See what I mean now?

Ok, you have select entity as default creation (default) - im used to POS as creation method making entity selection optional for a ‘cash transaction’.
Anyway, your issue is that when you open the table it opens the existing ticket. Add ticket will close that ticket and start a new one. The key bit being it closes the first/existing ticket in order to create a new one.
You have a few methods but how fool proof they will be depends on your other configs/flows.
Adding a constraint to the ticket closing rule for say, {TICKET STATE:Status} equals New Orders would make it only autologout on close if the ticket is in new orders state, ie an unedited ticket just opened should be in a submitted/unpaid state.

1 Like

Actually set it to TICKET STATE:Status not equals Unpaid. Because close happens after states are changed.

1 Like

I am not sure what to do just yet. I just noticed that this was doing this to me today when I was testing with the new server ids.
New restaurant, new staff, all green at this and I want it to be as simple as possible for them with less to remember.

I could set it up that way you suggested and on new orders it would auto log out, but on add ticket they would have to be sure and log out and I could strongly encourage that they log out before walking away.

Ok that did indeed fix that problem
{TICKET STATE:Status} Not Equals Unpaid

Fantastic. I am almost in love with this software. Thanks

Well poot, spoke too soon as usual.
Logged in as another user, entered a few beers, expected it to auto logout on close, didnt.

I wanted it to close, then pretend some more people came in to same table, and I wanted to add a ticket. Then I would EXPECT to have to log out.

Can you elaborate exact flow and what status is shown at top of ticket?

But thinking about it, since it’s ticket closed and states have already been updated every ticket close should be unpaid or bill requested…

My system I tap into the close command, using the background option to allow usual stuff to happen before logging out.

1 Like

Your right. Hmm let’s think this through.

I am not sure how to be any more clearer in my examples.

Family goes out to each, one big ticket, lots of items, easy to keep opening ticket and add items at later times through out this meal. But in the middle of the meal, there is a friend that is eating solo tonight and they invite him over. He needs a separate ticket. Why not click add ticket on that same table?

I want servers to be auto logged out on payments and close.

I really want auto logout to only happen on the Close button and of course on payment received.

However when a server goes back to a table and touches ADD TICKET the server is immediately logged out. This is because of my TC_Logout User addition.
If the server logs back in, the new ticket is up ready for menu items to be added and she can, and then tap close and it will log out. The immediately kicked out part is not good. Not what I want.

Pretty sure this was the reason I didnt just use ticket close as not many factors useable for constraints at ticket closed point.

Is what I want to do not achievable ?

My setup as I said has a ‘backgroud’ command on the close command button.
As for payment I have a payment processed rule with constraints for remaining balance=0 which then triggers that same command.

Was going to show my payment flow resulting in logout but it will confuse matters as have loads of other automation in the flow for showing change message or not and checking entities and covers counts for other bits on my system

Tell me more about that DelayedLogoutCommand.
Sounds like I need that.

I thought I had a similar payment processed rule for remaining balance, but its just set to cash sale, it logs out after that some how.

Actually, just scratch all this. I just enabled auto logout on each station and that did it perfectly…
Why have I been trying to reinvent the wheel?

Autologout is a fixed option for terminal and fires for all users. Its an easy option but less flexible. If it works for you then use it.
I went the route you were working on as meant I could constraint it to numerios factors including terminal, user role and obviously exact senarios I wanted.

Feel free to delete this post if you find it to be a waste of space and useful.