In my previous post on this subject, I wrote at the end The only
problem with this is that the above uses one of the business rule's
three conditions, and there may not be a condition to spare. A simple solution to this problem occurred to me today.
Let's say that a rule has all three possible conditions defined, and that one of them is "branchname = 400" (I have several rules like this). All I need do is leave the "branchname = ', part and define the expression
(SQL.USER IN (1, 205) ? 'A' : '400')
This condition kills two birds with one stone: if the user number is 205 (me), then the expression will return 'A' which means that the condition and thus the rule will fail. For a regular user, the value 400 will be returned; if this value matches that of 'branchname', then the rule will execute (preventing the user from doing something), but if the branchname is not 400, then the rule will fail. Which is exactly what happens now.
At the moment, I can't see how I can use this technique if the condition is something like 'order type <= 007', but I'm sure that at least one condition out of the three per rule will be testing equality. One only has to choose the most suitable condition for this technique.
[Edit from 07/01/18]
One rule which I needed to change had a condition 'and order.branchname not equal to 200'. I was stumped at first how to change this condition so that it doesn't affect me, but after a few minutes cogitation, I found this solution:
Or in English, if the current user is either 1 or 205, return the value of 'order.branchname', else return 200. For me, the condition then becomes 'and order.branchname not equal to order.branchname', so of course the condition fails and the rule does not apply to me.(SQL.USER IN (1, 205) ? :$$.BRANCHNAME : '200')
[SO: 4632; 5, 22, 44
MPP: 1065; 1, 6, 7]
No comments:
Post a Comment