Pretty low priority bug introduced with predicates. I imagine this is also pretty straight forward to fix.
See the auto-filled app name in the screenshot below.
Similar issues have been reported here recently (though the behavior isn't new), and this is the expected behavior--that literally is the name of the rule at time of cloning as far as the hub database is concerned; RM “tricks” the UI into displaying it this way and making it look different by way of HTML.
As you have probably figured out, the box at the top of your screenshot is intended to let you edit the name of the cloned rule, which you probably need to do anyway--so there's an easy way to change it before you even create it. That's what I'd do.
1 Like
Thanks @bertabcd1234. First time I noticed running into it. It seems odd that the database name of the rule would actually change rather than a parameter attached to the tool being concatenated with the rule name in HTML, but I am far from a software guy 
There does not exist another mechanism in the App UI for the Apps name list or display at the top of an app page to introduce something like (Predicate False) in red text -- other than the app actually changing its name to accomplish it. It's a hack. That's what developers do to get around shortcomings in what they have to work with. I always thought it better to let you know something like that, or "(Paused)", than to leave it hidden why a rule wasn't running when you might otherwise expect it to.
At any rate, the App UI framework and Apps page does need a better way to accomplish this than the hack currently employed. Point taken. Until that wondrous day, the hack shall continue to serve to inform users the state of their rule, with the resulting cost of annoyance when cloning a (Paused) or (Predicate False) or even (Repeating) rule. There is actually a companion anti-hack in use elsewhere to remove the dangling red text from an app name, so for example you won't see it in lists of rules you might do something to in an action. But, as of now, that particular anti-hack has not been put to work in the case of cloning a rule.
Please note the word (beta) in the Export/Import/Clone section of the Rule Machine UI. That was put there to indicate the likelihood that this functionality was not in final form. Indeed, this functionality is actually going to be changed in the near future, and not be a part of the parent app at all. No doubt, the anti-hack can be put to use as this change is implemented, to prevent the annoyance so fittingly described above as a bug. I always say that one man's bug is another man's feature, and in this case, I'm sticking to that.
2 Likes
Having watched you in action since the last update I have no doubt you are keeping very busy. I do live and die by cloning rules since I'm cleaning up and converting everything to RM5 (got tired of running into errors adding waits to existing rules).
Is there a better way to report bugs like this? Searching the forums isn't great for finding existing bug reports.
No, and obviously this way works.
Release 2.2.8.153 is out and fixes this issue when cloning a rule with Predicate False.
2 Likes
You are a machine!
I was thrown at first: When you clone a rule that has Predicate Condition False, the cloned rule will also have Predicate Condition False (duh). For a bit I couldn't figure out why the red text was still there after the rule was cloned.
2 Likes
