Limiting User Sessions/Logins

Does anyone have (or has seen a post regarding) forcing user logout on other terminals if already logged in?
Joe

There was discussion regarding Auto Logout on Ticket Close, and/or on a renewable timer. Unfortunately, it does not cover your scenario, but maybe you can get some ideas here.

I assume you will need the Message Service running so that the Terminals can talk to eachother.

Then you want to watch for the User Login Event, and fire a Logout User Action on the original Terminal where the Ticket is sitting open.

That’s where the complexity comes in. You can only Close a Ticket if one of these conditions have been met:

  • an Entity has been assigned to the Ticket (Table, Customer, Employee)
  • a Ticket Tag has been applied to the Ticket

So on the User Login event for Terminal B, you would need to perform 3 Actions:

  • assign an Entity to the Ticket or apply a Ticket Tag
  • Close the Ticket
  • Logout the User on Terminal A

I was thinking of storing a program setting on User Login with Terminal #, Currentuser, and a status of In that resets when that user is logged out. Could easily check this on login and using message server the other terminal could watch for message received. If message received says Logout it would perform the logout. Could automate any other issues like needing a tag or entity on a ticket if its in middle of a ticket.

Doing this method you could bring up an ask question action to say something like You are currently logged in on {SETTING:Terminal #} continuing to log in on this terminal will log you off of the other terminal. Do you want to proceed with Yes or NO.

Sounds interesting enough and useful I may even attempt to build this. But my method is a little more advanced so you may want something more simple like what @QMcKay suggested

1 Like

I already have the username tag setup as part of your previous post so in theory at any point a logout should be possible.
I would say a pre-requisit of having this setup would be the preference over needing to setup some form of tagging in addition in the same process flow.

1 Like

You have two options for tagging a ticket so it can close. 1. Ticket Tags, 2. Entity assignment. Either option will let you close a ticket without payment.

I would love to try to build this. I just need to set up another Terminal, which would take some time…

This is a brilliant idea,
I’m no expert but would imagine that a program setting logging user sessions which prompts a message saying your already logged in would be allot simpler to forcing logouts on other terminals.
If this mappens before a ticket is created it would prevent what my consern is that with the ‘switch user’ setup a ticket can be started and the same user logged in on second terminal and another ticket started overswiting the program setting remembering the open ticket with the new one - causing the first unfinnished part ticket being lost in the ticket list and left open as it already has the username tag assigned. (if that makes sence)

I am starting it now actually. Will use my surface pro to test it.

3 Likes

Excellent! Can’t wait to see what you come up with.

I started with entity as the post on here sugested but another sugested tag which is much better in my mind from a installer point of view as manager could add a new user without the need to setup staff entity, the tag can be anything (in this case the username in a ‘unassigned’ tag line i setup used soley for switching user.
This required so further administration other that the tag name being setup, usernames are open/freetag.

1 Like

I was going to say similar to @Jesse that with the multi rdp patch you could use rdp for a second terminal (even on the same computer.

I hate to be the lazy one sat back giving suggestions with no practice applicable methodology and limited input but It is still early days in my sambapos experience and my perimeter/capabilities knowledge is still in its infantry

1 Like

which method/route are you planning to go down?

  • force logout on other terminals
  • mesage preventing login

I am doing the message with warning and option to logout or not. Also if logout is chosen it will check if ticket is open and it will assign a specific tag to track that ticket which can be opened again. So no loss of any transactions.

1 Like

LOL, knowing @Jesse, he will give the User a choice using an Ask Question Action as he mentioned.

I have noticed after reading several posts writen by him that he does have a preference for ‘ask question’.
To be fair I cant blame him, its a much more attractive method of info popup LOL
I have just setup (setting up) his fast payment button options with chane popup in ‘ask question’ boxes. HEHE

1 Like

Again, I hate to be the one offering sugestions and not doing the legwork of coding but what would be !!AWSOME!! is if you do force the logout on the other machine that is was able to do the tag etc before actually logging in meaning that the tagged ticket left open on the other terminal then opens straight away.

1 Like

So what your saying is if user Jon was logged in and had a ticket up on Terminal A. If he left it up and then logged into Terminal B and the prompt came up and he chose yes… it would Log him out of Terminal A and then immediately bring that open ticket back up on Terminal B?

That can be done and is rather easy. Good idea. I will test the possibility of both methods. Bringing ticket up and asking to bring ticket up :stuck_out_tongue:

I mean I can see a flow where he meant to close ticket on Terminal A but forgot too and he really did not need that ticket brought up on Terminal B just yet. Maybe he was ringing up a different customer.

This is a great idea because it would help business flow and offer a way to fix mistakes with automation.

EASY! LOL
If you say so, I would happily use either method, but thought Id give what input I could.

On a seperate subject, before I start another thread, I have been trying to find a post which related to a similar issue with tickets, IE if one user logged in and opened table 1 on machine a another user could also open that ticket on another terminal - as i understand if, whoever closes the ticket first is saved, and the other receives a message saying it has been changed and any changes by that user are not saved.
Personally I would say that was a big loophole which should be fixed in the core rather than with extra setups.

Joe

What your saying is two users can open same ticket up and edit it at same time and mess things up? You think we should prevent a ticket from being opened up at same time? We may be able to do this with some automation. I will look into that.

BTW @QMcKay you can emulate multiple terminals by allowing multipleinstances in the settings.txt file and you can open two instances of Samba and give each instance their own Terminal Name.