Friday, January 05, 2018

Business rules in Priority which do not apply to specific users/2

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:
(SQL.USER IN (1, 205) ? :$$.BRANCHNAME : '200')
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.

[SO: 4632; 5, 22, 44
MPP: 1065; 1, 6, 7]

Thursday, January 04, 2018

Business rules in Priority which do not apply to specific users

I've written a few times about business rules in Priority, and it seems that thinking about these rules has opened up a few possibilities. A business rule is inclusive: one defines for which users (or groups) the rule is effective. This sometimes means that the same rule has to be defined several times, once for each group of users. There is no way of defining a business rule to be exclusive, i.e. it applies to everyone except a few users.

... Or is there? After a little creative thinking, I realised that I could define an exclusive rule. The way to do this is to define one of the three conditions that business rules allow in the following manner: the document's date is equal to the following function:
(SQL.USER IN (1, 205) ? 'A' : :$.CURDATE)
This piece of gibberish, when translated in English, means that if the current user's number is 1 or 205 (1 is the system manager, 205 is my user number), then return the value 'A', else return the document's date. If the current user's number is 6, then the condition will be true (document date = document date) and so the business rule applies to this user. If the current user's number is 205 (i.e. me) then the condition will be false, and so the business rule will not apply to me.

Convoluted logic, but it works. 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. It might be possible to chain the above logic, but I suspect that it won't work.