This is in Grouper v5+. This UI shows rules, allows adding, editing, deleting rules. The rules are edited by "pattern". The underlying storage of the rule definition has not changed and is still assignments in the attribute framework.
Glossary
| Term | Definition |
|---|---|
| Rule | Something that listens for certain actions, checks for conditions, and performs an action |
| Pattern | Type of rule that solves an existing use case with a certain action, condition, and result. e.g. "remove invalid membership due to group" |
| Custom pattern | A grouper sysadmin can configure a custom pattern (can select any action, condition, and result). Non sysadmins can use built-in patterns only. |
| Assigned (on) | Which owner has the attribute assignment |
| Fires when | The action that is being listened for (e.g. flattened membership add in a certain group) |
| "Fires when" owner | The group / folder / etc that is checked for the "fires when" action. e.g. if the "fires when" is "Membership add (flattened) in group", then the owner is the group being checked. If the "fires when" owner is "this group / folder" then the "fires when" owner is the group / folder where the rule is assigned. |
| Condition | This is optional, if something should be checked for the rule to proceed after the "fires when" action happens |
| Condition owner | The group / folder / etc that is checked for the condition. e.g. if the condition is "entity is a direct member of the group", then the owner is the group being checked |
| Condition JEXL script | If the condition requires using JEXL expression language, this is the JEXL expression that should return a boolean for if the rule should continue firing. The variables available in JEXL depend on the condition type, and the source code should be consulted. Only Grouper sysadmins can configure JEXL scripts. |
| Result | The action that occurs when the rule "fires when" happens and the optional condition is true |
| Result JEXL script | If the result requires using JEXL expression language, this is the JEXL expression that should perform the action of the result. The variables available in JEXL depend on the result type, and the source code should be consulted. Only Grouper sysadmins can configure JEXL scripts. |
| Fires immediately | If the rule happens in the context of the existing transaction. For "fires when" flattened, it is a change log consumer and not immediately (i.e. will happen in the next minute generally) |
| Rule is valid | This is true if the "fires when", condition, and result are configured in a way that makes sense. If not valid there will be an attribute assigned to indicate that, and the rule will be disabled |
| Daemon | If the rule is daemonable (e.g. not an email rule), then a nightly daemon can run (unless configured not to) so make sure the data is consistent |
| Folder scope | When a "fires when" or condition references a folder, this is the determination of if it applies to all objects including subfolders (most common), or if it is only object directly in the folder (and not subfolders). |
| Flattened | A flattened membership add is when the member was not in the group by any path and is now in the group by some path. "Fires when" events should generally be flattened. |
| Direct | A membership is added to a group directly (i.e. can be removed directly from group). This is not due to a membership in a group which is a member of another group. Conditions about memberships might be direct if checking to see if a membership should be removed as a result (since only direct memberships can be removed) |
| Assignment owner |
Patterns
This is the list of rules patterns that are available in the UI
Privileges
| Action | Entity |
|---|---|
| All actions | Sysadmin user |
| See all rules | Readonly sysadmin |
| Perform add / edit / delete actions on rules in general | If there is a grouper.properties rules.restrictRulesUiToMembersOfThisGroupName = etc:rulesEditors If the user using the UI is in the etc:rulesEditors group. This does not apply to sysadmin or readonly sysadmin. If this is not configured then there is no global rules group. Whether this configuration is set or not, the following object privileges apply. |
| Use email in the result clause | If there is a grouper.properties rules.restrictRulesEmailSendersToMembersOfThisGroupName = etc:rulesEmailResultAllowed If the user using the UI is in the etc:rulesEmailResultAllowed group. This does not apply to sysadmin or readonly sysadmin. If this is not configured then there is no global rules group. Whether this configuration is set or not, the following object privileges apply. |
| Edit rules on a group | Group ADMIN privilege on the assignment owner |
| View rules on a group | Group READ privilege on the group |
| Edit rules on a folder | Folder ADMIN privilege on the assignment owner |
| View rules on a folder | Folder CREATE privilege on the folder, or you have inherited (group) READ on the folder |
| Use a group in a "fires when", condition, or result in edit mode | This is context specific based on the "fires when", condition, result.
If editing a rule, and a group is used in the rule that the user cannot see the group (see below), then the input will be blank. |
| Use a folder in a "fires when", condition, or result in edit mode | This is context specific based on the "fires when", condition, result.
If editing a rule, and a folder is used in the rule that the user cannot see the folder (see below), then the input will be blank |
| See a group/folders in the list of rules for a group (fires, condition, result, assigned on) | If the group (where clicking rules button) is a REF or BASIS type or in config list and the user is not an ADMIN of the group, then the user needs VIEW on the group being used (fires, condition, result, assigned on) If the group is not REF or BASIS or the user is an ADMIN of the group (where clicking rules button), all are viewable rules.groupNamesRestrictRules = a:b:c, d:e:f |
| See a group/folder in the list of rules for a folder (fires, condition, result, assigned on) | If the folder (where clicking rules button) is a REF or BASIS type or in config list and the user is not an ADMIN of the folder, then the user needs VIEW (or UI-type view) on the folder being used (fires, condition, result, assigned on) If the folder is not REF or BASIS or the user is an ADMIN of the folder (where clicking rules button), all are viewable rules.stemNamesRestrictRules = a:b:c, d:e:f |
Screen - folder rules - custom pattern
