Specifically I was referring to an Action constraint. The reason for using an action constraint is because you would be inserting this automation into a currently working rule that loads Employee entity etc. You would not want to constrain the entire rule just the part that displays ticket. So the action constraint simply checks if program setting has a value or not.
1 Like
Action constraints are even more powerful in being able to breakdown a rule and make little parts different based on factors 
Constraints is defiantly something worth investing some time in getting to grips with, once you do a whole broader range of more complex flows become possible 
Pretty sure that was the tutorial I went from with my first switch user config
1 Like
Keep in mind there may be other routes to achieve this. I am simply just brainstorming based on the fact that your using a system I derived so I understand how it works.
1 Like
my brain hurts, I’m gonna grab a coffee
1 Like
It could actually be simple 2 actions and 2 rules…
1 Like
Im thinking Update Program Setting?
Like above tutorial, but instead of {user name} Use {Entity Types:Employees} ?
Matt
Its the format of action constraints that throw me and i never know of what i use is valid or not, ill need to copy the format from another one
The key point to remember with Action Constraints is this:
All Action Constraints are evaluated at the same time when the Rule fires. They are not evaluated in sequence.
That is, Action Constraints are evaluated “in parallel”, so Actions whos Constraints are True are “short-listed” for execution, while Actions whos Constraints are False are “thrown out”.
This means you cannot set a value in one Action and then try to Constrain the following Action based on the value set by the previous Action. For example, you cannot do this:
Failing to understand the above concept is what throws people for a loop because they do not understand why it is not operating “properly”.
In the above example in fact, if the Program Setting is set to Is Local = True then the value is stored in memory instead of in the database. And in many cases, in-memory Program Settings are “cleared” upon User Login (which is the Event of this Rule), so you can assume with a fair amount of certainty that the value of EmployeeName is in fact BLANK. That means the second Action will be “thrown out” upon entry to the Rule and will never fire, even though the previous Action sets a non-blank value for EmployeeName.
3 Likes
Yes so program setting needs to be set in a different flow.
2 Likes
Will, have a go when I’m back home now.
busy time for me after school, thanks for your help till now though guys. Ill keep you updated on my fails.
Matt
Exactly. We need to break the flow up into separate Rules …
In the 1st Rule (left) …
The second Action is an Execute Automation Command Action which triggers another Event/Rule (right). In this Action we are firing an Automation Command having the name “Print Statement” (AMCname). We are also passing a value of the contents of {SETTING:EmployeeName} as the Command Value (AMCvalue).
In the 2nd Rule (right) …
The first Rule Constraint checks the name of the Automation Command and if it does not match “Print Statement”, then the Rule does not fire.
The 2nd and 3rd Rule Constraints are essentially doing the same thing - they check to see if a value is present in [:CommandValue] (which we passed into this Rule from the 1st Rule), and the other checks to see if a value is present in {SETTING:EmployeeName}. You can use either the 2nd or 3rd Rule Constraint in this case, but you do not need to use both. And actually, you don’t need to use either of them if you Constrain the Action instead …
The AS Print Account Statement Action is also constrained to see if a value is present in {SETTING:EmployeeName}. Alternatively, we could have constrained the Action with this as well:
'[:CommandValue]' != ''
… and so long as we passed a (non-blank) Command Value from the first Rule, it should evaluate to True.
So you have options… it all depends what you are trying to achieve.
Sometimes it is more efficient to Constrain the Rule, while other times it is better to leave the Rule with fewer constraints and then constrain the Actions within the Rule. Of course you can do a combination of both (Rule and Action Constraints), which is very often then case.
1 Like
And now you want to know this about Rule Constraints …
First, these are fairly intuitive:
- Matches All : all constraints must evaluate to True before the Rule will fire. This is like AND.
- Matches Any : any constraint evaluated as True will allow the Rule to fire. This is like OR.
- Not Matches All : all constraints must evaluate to False before the Rule will fire. This is like NOT AND.
- Not Matches Any : any constraint evaluated as False will allow the Rule to fire. This is like NOT OR.
Matches Any:
(constraint1 is True) OR (constraint2 is True) OR (constraint3 is True)
Matches All:
(constraint1 is True) AND (constraint2 is True) AND (constraint3 is True)
Not Matches Any:
NOT( (constraint1 is True) OR (constraint2 is True) OR (constraint3 is True) )
Not Matches All:
NOT( (constraint1 is True) AND (constraint2 is True) AND (constraint3 is True) )
Matches does a magic match
It compares constraint names on the LEFT side of the Constraint and if those names are the same they are compared as an OR, with other constraints compared as AND.
For example.
Customer name == Emre
Customer name == QMcKay
Date == Today
Date == Yesterday
Using Matches, the above resolves to …
(
(Customer Name == Emre) OR (Customer Name == QMcKay)
AND
(Date == Today) OR (Date == Yesterday)
)
If we were to use Matches All with the above Constraints, it would resolve to…
(
(Customer Name == Emre)
AND
(Customer Name == QMcKay)
AND
(Date == Today)
AND
(Date == Yesterday)
)
Obviously that ^ above would never work and the Rule would never fire.
So again…
Matches is a bit special. If any parameters on the left side of the list have the same name, they will be considered as an OR condition, while the other parameters are considered as AND.
{DATE:ddd} Matches Mon|Tue
{TIME} After 1430
{TIME} Before 1445
Menu Item Group Code Equals Classics
With “Execute Rule if: Matches”, the above means:
(Date is Monday or Tuesday)
AND (Time is After 1430 OR Before 1445)
AND (Group Code is Classics)
The issue is the {TIME} parameter … you don’t want it to be an OR condition; instead you want it to be an AND condition in this case, because the current Time is (almost) always after 1430 and the current Time is (almost) always before 1445.
Using Matches All, the logic is different:
(Date is Monday or Tuesday)
AND (Time is After 1430)
AND (Time is Before 1445)
AND (Group Code is Classics)
P.S. There are many legitimate cases for the use of Matches, but in this scenario you do not want to use it; you want to use Matches All.
5 Likes
@QMcKay - lately you have taken the time to write some very valuable bits of documentation, which we all appreciate very much. 
I believe such pieces of wisdom should be placed in the wiki or documentation. Going through your topics posted should provide a great short list. In my opinion some of these posts have been the biggest learning curve (for normal people kendash haha).
2 Likes
@JTRTech did you make the final refinement to this, and have you already made a tutorial for it?
"
JTRTech
Apr '16
I have a nice way to hybrid switch user and hold ticket although need to refine it.
My systems all user users rather than user entities but the core would be similar.
Rather than the origional method I used from a tutorial on here where the ticket id was saved against the user via a switch user button which offered the possibility of an open ticket not accessible from the POS to be left open and prevent work period close as it was left open tagged with a user on switch user function for a staff member which had finnished work. - Yes it could be found via ticket list but was a loophole I wanted to close.
The hotel setup uses a hybrid of hold ticket and switch user.
The switch user flow puts the ticket on hold and tags the ticket with the employees name.
Currently it adds one to a user_hold setting value so when they log back in it prompts them saying they have x number of tickets on hold and offers options for start new or go to hold list.
I liked this bit as if say someone started ordering but needed to go check something with wife you could switch/hold easily - serve someone else, and come back to it rather than forcing the previous ticket back on the user when they closed/logged out.
I liked this route as the hold list could be made accessible to all users and with a report tag in the button header the button shows the number of hold tickets.
When opening the hold ticket it subtracts one from the users hold setting and they continue as normal.
The refinement I want to make with this is to not use the program setting and use a report tag instead as there is a small glitch in the current setup that when a different user opens the hold ticket it doesnt subtract one from the original user meaning they get the prompt even though no hold tickets are open although currently combated this with a cleanup rule which clears the hold ticket count for each user on work period close.
It is on my list to refine this flow and put together a tutorial as think it works nicely in combining hold and switch user in a way which if wanted doesnt confine the held ticket to that specific user.
The other refinement I want to add is to setup so that is a ticket is left on hold for more than say 5 minutes it will prompt all users or maybe trigger a popup message saying that a ticket has been left in hold list for so long."
This might not be 100% what I have setup but think it’s mostly there.
Pretty sure in the end I make it do the count for that user for the prompt so might be the enhanced version after all.
Even better than one on live system which still uses the user ticket hold setting rather than counting…
Hoping to do a full rebuild this year with v2 of PMS intergration and utilising all new and learnt over last year.
1 Like
Thanks, glad you shared this tutorial version as i had only found your older one
Currently using entities as user but think ill switch back to users for simplicity 
Don’t think it would take that much to convert to entity users…
not sure if i prefer just using users though now instead of entities lol
Lol, I have yet to try entity users at all…
But expect will at least want to have paired entity users for storing extra fields in the next version when we impliment staff discount system and user sync with new property.
Think at some point we will see a merge of users into entities at some point anyway.