Basic Switch User by Swipe/Numberpad Entered Event

This is the very basic ground work for a switch user triggered by pin entry within POS to logout current user and log that user in.
This is first step only so would result in new orders being submitted and not work if there is no entity or close-able ticket tag set.
I plan to improve combining with my previous switch user/hold ticket setup triggered by a button.
Here is a screen recording of it in action, again very basic, no orders added etc.
Excuse the unregistered trial, switched to a fresh database for a clean working environment.

Note: this is on my testing laptop so using mouse to show pin entered etc but if using RFID or MSR for login you wouldnt need the onscreen numberpad in POS and would obviously be allot quicker without entering pin number by number.

1 Like

So starting with actions we will need;

  • Logout User
  • Execute Automation Command
  • Login User

I have used fairly generic actions using [:xxxx] to make all fields available within the rule.

Logout User Action

Execute Automation Command Action

Login User Action

We then need 2 rules;

  • NumberPad Entered Event Rule
  • Automation Command Executed Event Rule

NumberPad Entered Event Rule

The {REPORT SQL DETAILS:SELECT Name FROM Users WHERE PinCode = '[:NumberpadValue]':F.Count} report expression queries database to check if the numberpad entered value matches any user pins.
If it returns a username - ie numberpad value matches a user pin the rule fires. Closes ticket and Logs Out User
The Execute automation command action triggers in the background allowing the close and logout to happen before triggering the login action in the next rule. The numberpad value entered which we know matches a user pin is passed in the command value.

Automation Command Executed Event Rule

This second rule is triggered by the execute automation command above after other automation has completed. Then logs in the user with the pin swiped/entered using the command value (numberpadvalue) passed from the previous rule.

1 Like

Reserved for updates 1

Reserved for updates 2

Might amend my setup and use this :grinning:

1 Like

Just added a screen recording. See first post.
This coupled with;

Would be awesome, with ticket holding setup only issue preventing switch would be required ticket tags on an order without autoselect or selected but required tags not selected but generally the second senario would be unlikly as there would typically be someone at the till at this point, where ringing in rinks then pouring etc would be held. That hold setup i created additional state flow and allowed void (renamed to cancelled) for orders which had been held and not submitted and obviously also holding back kitchen print etc.
Also the ‘you have tickets on hold’ prompt on that setup works really well at hotel.

Yea I amended an used that setup with open ticket prompt in my switch user :grinning:

Looks to work and logout and in much quicker than mine as I had to use a delayed auto command of a second or two before logging back in, yours now looks to log back in immediately

This option is perfect for a quick service busy bar with no kitchen printer and complex order tagging with only the addition of the hold tag and ‘you have open tickets’ prompt since the more complex part is the flow split to hold of kitchen print etc.

Yea really simple for me as no kitchen printer or anything

Background = True isnt new and is exactly for this purpose, it waits for other tasks to complete before triggering so rather than just a delay its waiting for the other things to finish, is good for general uses and if more complex automation which might be effected by other things is ideal. Use it allot in my PMS integration as have posts to PMS API which might not always come back in a similar amount of time.

1 Like

Yea I’m gunna refine mine using what you’ve posted above

Switches really quick now, but ive tried linking it to your held orders and prompting to open previous closed ticket but i need to add a 2 second delay in the login auto command otherwise when being logged out the new user doesnt get logged in

also getting pos number pad not working if user has more than 1 held ticket, it doesnt appear when you start typing and also the ticket tag of current user assigning to ticket when closed seems to end up as the same person eventually rather than keeping the original person that was on that ticket before being auto logged out

Double check rule and action sorting maybe, there would undoubtibly be other background commands in the switch user setup, guessing it’s doing one before the other.
Not sure how multiple background execute command actions would be resolved since they are both execute actions.

Struggling to picture your seccond comment…

Might need to pass the pin through into the hold/switch rule and then put the login action in that rule with a constraint of the value being passed?
So if the hold automation is back group it happens then triggers the login background after words

actually its when the open ticket prompt comes up to say you have x number of tickets open do you want to recall one, if i say no the prompt closes and screen goes to pos screen. if you try typing numbers they dont appear

Ok, so it’s the prompt that’s interfering yer?
As above might need to get creative and either pass the pin over or bypass the prompt.

dunno its strange as if i repeatedly click my mouse on the screen eventually it starts displaying what im typing

think i may simplify and just have the original ticket that was closed reopen, instead of the prompt

1 Like

Did you have to put ‘[:NumberpadValue]’ - in quotes?
It works as pictures above but now ive switched databases it wanted quotes to work…