lol we can’t determine that. The reason of that issue is action parameter name matches to a rule constraint (parameter) name. If that action used in a rule that does not have “Automation Command Name” parameter there will be no issue.
1 Like
Would it not be better to constrain against all the [:] rule tags as if using variable content you would typically do it in the rule not hard set in the action…
Well we’re reading rule parameter values first (for a reason I don’t remember now)… There might be tons of rules benefiting from that and changing it might break setups. I think giving a warning will be enough.
To be more clear I highlighted the issue. Spaces added to constraint name while preparing it for the screen but it is actually stored without spaces.
2 Likes
Might suggest that ‘Action Field Name’ might make more clear than parameter…
1 Like
I updated it as :
Action field name [blah] shouldn’t match to a rule parameter name.
2 Likes
In fact that wouldn’t cause an issue for actions other than Ask Question and Execute Automation Command actions. These actions inserts rule constraints and action parameters to the flow so you can access them from called automation command handling rule… Anyways checking that will be a benefit for user as such name conflicts may cause other issues.
I believe this to also be an issue with the Update X State Actions.
In particular, if you use a parameter in the Action called [:State] then it breaks in Rules that handle State Updates.
I know for certain I have chased this issue down before in regards to State Automation, like this one @emre …
1 Like
As Q points out while those two actions might be the ones that could cause a loop there are other potential issue actions/field names.
One of my other thoughts would be to somehow force a space or something into the field but dont think that would be justifiable/doable.
I would have personally said a message on the action warning that using a field [:] with same name as a possible rule value might cause issues.
If it was just a warning it wouldn’t mess up existing systems and would allow use but the message would highlight the potential to anyone not planning to do that.
Simple solution (going forward):
When you type a parameter name into an Action parameter, have SambaPOS forcibly LOWERCASE the first letter of the parameter name upon saving the Action …
So this:
[:AutomationCommandName]
Becomes this:
[:automationCommandName]
And this:
[:State]
Becomes this:
[:state]
Or even this:
[:MYreallyCOOLparmName]
Becomes this:
[:mYreallyCOOLparmName]
This was where I wasnt sure if it was a good thing to force something as although cant think of it is there a legitimate reason to use a rule [:] expression in the action field rather than generic action [:] it and set it in the rule?
Um, no. 
In the Action, the syntax [:sumthinSumthin] “variablizes” the Action Parameter for use in a Rule.
In the Rule, [:PaymentTypeName] is a “short-hand” Parameter that comes from the a list of accessible Parameters based on the Rule Event.
In short, you should NEVER use Rule [:variables] nor Printer {TAGS} in an Action directly. They should always be passed from the Rule to the Action.
1 Like
In which case you would be best just to prevent them being used as action field names surely?
1 Like
Yes, exactly.
Unfortunately, for legacy reasons I’m sure, there is nothing preventing this.
My vote would be for something a little more drastic: change the syntax for [:parameter variables] in Actions, to maybe something like this:
[_AutomationCommandName]
^ the underscore indicates the parameter is a variable
^ the colon (:) is no longer VALID syntax for a variable
In fact, the colon should not be allowed AT ALL ANYWHERE in the parameter Name!
1 Like
I would second that, it would better differentiate the process of setting a variable field name in the action for use in a rule and rule [:] parameters.
1 Like
Yes, it would be nice.
But it will break existing setups unless there is a maintenance utility to parse and update all affected fields in all affected records in the DB 
Wow. The warning will improve that a lot without creating additional issues. Otherwise we need to:
- Teach people to remember if they are referencing an action varible or rule parameter.
- Well… update tutorials. lol
2 Likes
Thanks everyone for the input on this, especially Joe. I would never have found this problem without your help.
I am currently rebuilding the database from the ground up as this process has made me change so many things I am concerned at some of the settings. When this is done I will update you on the results.
1 Like
Well I have finally got my database back to where I need it but surprise, surprise I still have some strange behavior when executing the Booking Admin - Entity Grid Ask Questions - Create Booking Command Actions
The Rule executes and prompts to ask for Guest Name which gets inserted into the Custom Field on the Rooms and also inserts the Random Booking Number see below in Particular the Data for Room 6.
There are two problems that occur with the process at this point as follows
-
{DATE} does not return actual date. It always gives a Value of 01/01/01 which then is equated to 01/01/2001. Nothing I do with the DATE Field gives me any different result.
-
The Functions in the Rules detailed below do not get ENTITY DATA value. This is demonstrated by my test message which runs and displays {}. The Reading of the ENTITY DATA is pretty fundamental to the operation of the Rule and is preventing creation of Fields in the Rooms Entity leading to Failure to create the Booking Entity
@JTRTech You will see that I have changed the Rooms Custom Field Name from Guest Name to Guests Name As this was the only way the Rule would write the value to the Custom Field. Not sure if that means there is some conflict with Guest Name. Very strange again. More worrying is why {ENTITY DATA:Rooms:Guests Name} does not give me a Value
Will have a look later when I get home.
1 Like
Have you got the load/update entity action at the beginning?
You need to have the entity loaded to call the info?