Status: Resolved (View Workflow)
Affects Version/s: None
Fix Version/s: None
Docs QE Status:NEW
This is same as Hit Policy None
GUVNOR-2650, but we block the use of salience. Since it can change the priorities. We want to be able to have multi hit in the order that the items are in the table.
|If score is above||Set client status to|
|Application is active||Activate activation-group|
|Savings between||Yearly income||Max. credit allowed|
|> 50 000||10 000|
|10 000 - 5 000||5000|
|25 000 - 50 000||2500|
|5 000 - 1000||2500|
|0 - 1000||500|
|< 25 000||250|
All the rules might fire, but since we force the order the client gets to keep the best possible status.
Rule order makes the dtable code generation set salience for the dtable rows. Lowest line has 0 as salience and for each above that we up it by 1.
The actual row number is ignored, since the dtable might be generated. What matters is the order of the lines.
We do not protect the salience "chain" in anyway. All the rules might not fire. Any that are able to fire, we try to fire in the given order. The user can write logic that reverses or blocks the order. Either in the dtable or out side of it, for example in a separate DRL.
- For sure the rules are not redundant since the salience is not the same, but does it make sense to report redundancy when two lines are redundant (if salience is ignored)
- At this point can't think of a situation where looking for this would make sense. It rather makes sense that the table with Rule Order has defiency
The answer: At this point it looks like these make no sense, the salience is the key and makes the checks pointless.
|Counter||Set counter to|
Kind of like the keyword "goto" bad practice, but can happen.