...
The daemon will also run rule logic to sync up data inconsistencies (if it slipped by the rule somehow, or existed before the rule did). The rule must be eligibile for daemon logic, meaning it must have an enum for the CHECK part, or either a blank or enum IF condition. Also, the CHECK and IF enum must support daemon logic (basically it needs to be implemented), and the "ruleRunDaemon" attribute must be blank or T, and not F.
Extended EL API
There is a special group which has access to more objects in EL:
Code Block |
---|
# any actAs subject in this group has access to more objects when the EL fires on
# the IF or THEN EL clause
rules.accessToApiInEl.group =
|
This is because the RuleUtils class might be too limiting in some cases, but if everyone had access to the API, it might not be secure. So if you need this, configure a group here, put in trusted admins/users, then act as those users in your rule. e.g.in this case the attributeAssignType object is in scope
Code Block |
---|
attributeAssign.getAttributeValueDelegate().assignValue(
RuleUtils.ruleIfConditionElName(),
"${ruleUtils.hasMembershipByGroupId(attributeAssignType.getOwnerGroupId(), memberId, null, 'true')}");
|
Note, to see which objects are in EL scope, turn debug logging on for rules and check the logs
Code Block |
---|
log4j.logger.edu.internet2.middleware.grouper.rules = DEBUG
|
Custom EL classes
You can configure custom EL classes to help with logic you need if not in the Grouper API. Here is an example:
...