How OrGroup Logic works with Rules in RecTrac 3.1
Learn how OrGroup Logic is used to setup and apply rules in RecTrac 3.1.
Problem
If an OrGroup is used on the Rules tab of an Activity, is it a grouping of 'OR' logic?
If you have 5 individual Rules without OrGroups set, do all 5 Rules need to be met in order to register for that Activity? Otherwise you can specify OrGroups to say (Rule 1) If Resident OrGroup5 (Rule 2) If Non-Resident, and whatever other rules are set?
Is an OrGroup needed if there is only 1 Rule?
Is there a difference between OrGroup1 and OrGroup4? Or is it just a label to use if you've got multiple groups of rules that you want to manipulate with?
Solution
Yes. The logic behind an OrGroup is OR logic. You can think of rules in terms of 1's and 0's or Yes/No or Pass/Fail if it makes it easier.
Each individual rule must be passed in order to continue. A Resident-Only rule, for example. If you're a Resident, that's a 1 and you pass. If you're a Non-Resident, that's a 0 and you fail.
When linked individually to a transaction, each individual rule is looked at separately and each must be passed on its own merit. It is not a cumulative sum game. It's 1(you pass) or 0 (you fail) for each separate rule and any 0 on any rule means you fail the entire process and invoke the Rule Override Logic, if any.
So if you had an Activity set up with a single Rule for Residents (they can register up to 30 days prior to the begin date) and a single Rule for Non-Residents (they can register up to 14 days prior to the begin date) linked to the same Activity, no one would ever be able to register becasue no one would pass both Rules. There would always be a failure.
A Resident registering 8 days before the start of the program would pass the Residency rule (Resident within 30 days of start) but fail the Non-Residency rule (Not a Non-Resident). That failure is a 0 and the Resident can't register.
A Non-Residents registering 8 days prior to the start would fail the Residency Rule (Not a Resident). That failure is a 0 and they can't register. They would pass the Non-Resident rule (Non-Resident within 14 days of start), but it wouldn't matter because of the Residency rule failure. Any 0 in the process is a total failure of the whole process.
Anyone without a Residency Code is neither a Resident (fail) nor a Non-Resident (fail) and therefore wouldn't get in, either.
Groups of rules allow for the OR logic. When you make a Group of Rules, you need only ONE success to pass the entire Group, regardless of how many 0's you get within the Group. So in the same scenario above, if the Resident/Non-Resident Rules were Grouped together (as opposed to being listed separately), everyone could register provided they were within the proper dates for their residency option.
A Resident registering 8 days prior to the begin date would pass the Residency Rule (Resident within 30 days of start) but fail the Non-Residency Rule (Not a Non-Resident). However, because the Rules are Grouped, one pass only is needed, so the Resident gets in.
A Non-Resident registering 8 days prior to the begin date would pass the Non-Residency Rule (Non-Resident within 14 days of start) but fail the Residency Rule (Not a Resident). However, because the Rules are Grouped, one pass only is needed, so the Non-Resident gets in.
A Non-Resident registering 28 days prior to the begin date would fail the Non-Residency Rule (Non-Resident but further out than 14 days of start) and fail the Residency Rule (Not a Resident). The Rules are Grouped and one pass only is needed. This Non-Resident failed both, so he doesn't get in.
Anyone without a Residency Code is neither a Resident (fail) nor a Non-Resident (fail) and therefore wouldn't get in.
Using your example of 5 Rules: If they were NOT grouped, a patron would have to pass all 5 rules (100% success is required) to get in. IF all 5 Rules were in the same Group, any one success on any of the five rules (20% success rate) would be enough to pass. The person could pass all 5, or 4, or 3, or 2 Rules as well. Once you get one success you're in.
If you combine some single Rules along with a Group, the same logic applies. Single Rules have to be passed on their own merit. Rule Groups require one success within the Group. To get in, you need to pass all individual rules and then pass the Rule Group as well. So for example, you might have a Driver's Ed Activity with an age requirement of 15-18.99. You would link that Rule individually and then link your Residency Rules (the example above) as a Group. In this scenario, Age 15-18 is a MUST, so any failure of that single rule would prohibit registration regardless of your Residency Group success. IF the Age Rule were Grouped together with the Residency rules, then you could have a 99 year-old Residents in your Driver's Ed class because one success only (Resident in this example) is needed to pass the entire Group.
Lastly, multiple Rule Groups in the same single transaction work like individual rules. If you have an OrGroup1 and OrGroup4 linked to a single Activity Registration, the patron would have to pass both OrGroups to get in.
The number 'OrGroup1, OrGroup2' for example is just a label. When making the Rule Group, the OrGroup you pick (1 - 5) doesn't really matter and you can have an unlimited number of OrGroups sharing the same label (you might have16 different OrGroup1's, for example). The system simply needs a place holder for the Group so it knows where to look when the Rule Group is invoked. OrGroups 1-5 are hardcoded. It seems unlikely anyone would need more than 5 separate Rule Groups needed for one single transaction, such as a single pass membership or activity registration.
The only thing you cannot do is stack OrGroups of the same number within the same single transaction. So you could not have an OrGroup2 linked at the Section level and an OrGroup2 linked at the Activity Level, for example. Linking an OrGroup2 at the Section Level an OrGroup4 (or 1, 3, or 5) at the Activity Level would be OK.
See Also: RecTrac Rules Overview.