if im correct my request will allready have a fix in next update [quote=“emre, post:16, topic:5493”]
added Login User action and Pin Code Entered rule.
PS: Pin Code Entered rule will trigger when an invalid pin code is entered on login screen. For valid user pin codes it won’t trigger.
That will work for 5.1.61
but in case it isn’t my request basicly is that we would have a action that allows us to change the currentuser this would make it possible to use user as waiters instead of using entities as waiters which works great thanks to all the work of kendash and @emre but even with all their great work i still miss a key feature which would be resolved with “change currentuser action”.
like in my case i need my waiters to be able to enter tables screen with a swipe of there rfid badge and be able to select any table except those all ready in use by other waiters on top of that i(admin) need to be able to change the tables currentuser cause sometimes my clients change table which are in the area of other waiters, with entities much is possible but not the deny other waiter option like user have. but with user at this point its not possible to change the user once table is allready in use.
so what i envision the “change currentuser action” would be like is in the action you have a “new user” field where you type in one of your users, lets say john in this case. then you have a button that when pressed triggers the “change currentuser action” so that currentuser becomes john
hopefully i didn’t ask for something impossible or stupid with this but if any of you guys could create this action that would be awesome
We have the existing
Logout User action and the new
Login User action coming in the next version 5.1.61
However, it sounds like you want to change the Ticket User (using an Admin or Manager user account). There currently is no Action to do this. If there was, I would expect it to be part of the
Change Ticket Properties action. It is theoretically possible to do this now using SQL in JScript to update the Database directly.
so does this mean with the new Login User action it wont be possible to change the tickets user by lets say making a button that has the action login user with a predefined user attached to it?
No, the new action will not help with this request.
In assuming the new login action will help with a user based switch user setup?
For example an open ticket with ticket tag or entity assigned we could automate it so that if a second user swipes their card etc it will log out (already possible now) but add the login user action to the logout rule so that the user that just swioed their card to initiate the log out process is then logged in (using their login pin stored on the card to filter into the login action to log them in)?
hmm sad to hear that but what i can make out of your previous reply the function i want is possible right?
if so could you help me a bit in how to create such a function
What’s your reasoning behind changing the user of a ticket? If you explain it would be easier to digest posible solution to what your looking to achieve.
so basicly i need to be able to deny waiters to enter tickets that arent theirs (allready possible with user roles) and to change the user of a table when the customer changes to a table that is in a section of a other waiter(this waiter needs to become the user of the ticket)
Ive never utilised the function to prevent other users accessing a ticket but looking at table structure only reference to user I can see is ‘LastModifiedUserName’.
If this is the field relevant to preventing other users editing the ticket we can if nothing else probably work out a script to change the tickets ‘user’.
How do you define a user to a section? Pretty sure have seen what your doing done with section entity screens where a user has the entity screen relevent only to their section and the manager/hostess can see all tables and move between sections from here screen.
Isn’t three already a setting to deny that in user permissions for roles?
Yes, and he is using it but he wants to change the user for the ticket.