Continuing the discussion from Button to change entity state:
I had this working in my V4 setup - but since moving to V5 I cant get this to work. Any help would be great.
Everything else is working from my V4 backup that I restored into V5 - I have also tried re-importing the setting file form the zip (quoted)
Please help 
Did you run the fix old rules option in program settings - maintenance.
Thanks for the reply, yes I tried that but no change.
Ok so show us your setup maybe we can help.
Here is the screen from the rule debugger if that helps ?
Rule debugger says Update Available Entity Color rule -that works on ticket close- updates status back as Available. Was it working for V4 with no additional constraints?
Hi @emre
I have just checked on the v4 setup and it appears that there are a couple of actions missing on the rule to set the entity as occupied. I have added these in but still this isn’t working . I’ve looked for other constraints but can’t see anything. Added pics below … can’t do screenshot as v4 .System no longer on the network.
I have been having a play around and if I add the constraint ‘{ORDER COUNT} Greater than 0’ to the 'update available entity’ rule it then works. But then it doesn’t change settled/closed tickets back to available and changes them to ‘new orders’
Maybe there is a better way of doing this with V5 - all that is needed is an automated command button to change the state of a Table entity - without an order being placed.
Any help with this would be great.
Maybe you should use a different state than default one. Default states have a specific sequence of flow in the rule system and what is happening is your state is getting reverted back due to that flow. You should create a new state and use that.
I agree with @Jesse. Best to create a different State Name (Group), such as OStatus.
The problem that you might be running into is common with State flows. You need to understand that in some State flows, the Previous/Current State is used as a constraint. So in that case, the State will not change unless the previous State constraint is satisfied.
As it happens, by default anyway, the Entity Status State Name is not constrained at all. So the State is arbitrary. That said, when you add an Order to a Table, the default flow is to set Status to New Orders. So this will override your Occupied Status State for that Table.
This is in contrast to the Order Status State, for example. The State Flow for Order Status is constrained to only change when the previous/current State condition is met.
Thanks for your help guys! OK Ive tried that but still looks like the ‘update available entity rule’ changes it to available when I click close…
its just odd how my current config works in V4
Can you show your v4 config?
I haven’t got access today - however I think most screenshots are near the top of this post if that helps
This is baffling…
I am storing the Entity Name and the Status in a Program Setting, globally (in the DB).
Then I can read them, with a series of Show Message Actions that are fired in different Rules…
Here is one of the Rules contains the Show Message …
Now the baffling part …
If I change it to display just the Entity in 1 Rule …
And just the “Status” in another Rule …
And finally both in the last Rule …
Then it cannot read the “Status” when it is all alone …
@emre, WTH is going on here ???
That is, how can I trust this constraint is working? I can not !
EDIT: This seems to work when using CSETTING for the inner value … :still_baffled:
EDIT2: Unfortunately, this is not going to work properly either, in the end, since I have no way to tell what the cached setting (CSETTING) actually contains at any given time.
I can send you a backup, give me a few minutes…
But, on the bright side, I managed to find a way around all of it. I have a working solution.
Thanks as always for your help @QMcKay I will put this to the test today and let you know how it goes
I wondered if {ENTITY STATE BY NAME:Tables.{ENTITY NAME:Tables}:Status} working why you wanted to store table name inside OStatus setting instead of just using {ENTITY NAME:Tables}? Is there any point you can’t access table name?
btw your backup seems to slightly different from the state that setting issue occurred. How can I reproduce that issue?
